Vercel Agent: An agent you can let near production

Today we're expanding . It started by triaging alerts and reviewing your pull requests. Now it has a home in your dashboard, where it can investigate production, answer questions about your projects, and take action once you approve it.Vercel Agent Because Vercel Agent is built into the platform that deploys and runs your app, when something changes in production, it's your first responder. It autonomously investigates your logs, metrics, and deployments, finds the root cause, and proposes a fix, before you've opened your laptop. Vercel Agent works under its own identity and is read-only by default. You can reach it through the Vercel Dashboard, GitHub, and the CLI. We've been running Vercel Agent on our production deployments for months. This is what a typical investigation looks like. A bad deploy ships at 11pm and the checkout endpoint starts throwing 500s. By the time the on-call engineer logs in, Vercel Agent has already traced the errors to the deploy that shipped four minutes earlier, and recommends an instant rollback. The engineer approves the plan. With permission, Vercel Agent rolls back to the previous production deployment and begins working on a PR to fix the endpoint. The time from alert to mitigated: less than three minutes. You can also direct Vercel Agent yourself. Hand it a task and it does the legwork, then either answers your question or hands you a fix to approve. It never changes production on its own. For example: An agent that can fix your app can also break it. So for any agent you let near production, the first question is: how is it safe to let it deploy, change your config, or touch your data? The answer, for most agents today, is that it isn't. That's because they inherit your full permissions. One bad prompt from you or a confused sub-agent has the same blast radius as you. The choice has been read-only or standing access, careful-but-limited or capable-but-dangerous. Vercel Agent implements a new permissions model, built on three things: who the agent is, what it's allowed to do, and where its code can run. Most agents act as you. Connect one, and it acts with your identity and your access for the whole session. There's no line between what the agent can do and what you can do. Vercel Agent runs as its own principal, . This matters for two reasons:vercel-agent Integrating agents into your SDLC usually starts the same way, by granting them broad access up front, more than they need and for longer than they need it. But anyone who can prompt the agent can reach whatever that access touches. The permissions you grant are the exposure you accept. Vercel Agent is read-only by default. To do something more, like rolling back a deploy, changing a config, or clearing a cache, it proposes a plan and requests access scoped specifically to that plan. You approve it, the agent does the work, then drops back to read-only as soon as the plan is completed. When you approve a plan, the agent gets a short-lived capability for exactly the tasks it named, and nothing else. Every call it makes has to pass three checks: that capability, the token's scope, and your team's existing permissions. It runs only where all three allow it, and those checks live in the platform, so they hold no matter what the model does. We call this the plan-to-permission prompt model. It's least privilege, by design. Even if something goes wrong, Vercel Agent can only act inside the plan you approved. It's an agent capable enough to fix production, and contained enough to actually let it. The plan-to-permission prompt model controls what the agent is allowed to do. But any agent that writes code faces a second problem: there’s no way to know the code works until you run it. The code Vercel Agent generates runs in , an ephemeral Firecracker microVM. Inside the sandbox, that code is isolated from your live systems and the host environment.Vercel Sandbox The sandbox is a real copy of your project, so the agent runs generated code against your actual build, tests, and linters, and only surfaces what passes. Say the agent needs to fix a failing config. It writes the change, runs it in the sandbox to confirm it passes, and surfaces it in a PR. The agent can write and run code freely, and still can't put anything broken in front of you or into production. The agent era will be defined by two ceilings. One is what the model do; the other is how much of that you'll it do. As models improve, the first matters less and the second is what counts. It all comes down to trust.canlet A better model is wrong less frequently, but it is still non-deterministic, and non-deterministic systems fail non-deterministically. A safety story can’t rest on an agent getting it right every time. The trust has to live in the system, and the system is judged by what a mistake costs. We have spent years driving that number down. mean every deploy is preserved and a bad one is a rollback away. We didn’t build that for agents initially, but it’s exactly the guardrail an autonomous system needs.Immutable deployments When safety is built into the infrastructure itself, agent mistakes are contained and human mistakes are less costly. This is what we mean by anti-fragile infrastructure. You can give an autonomous system real power without betting on it being right, because the foundation holds when it's wrong. Power stops requiring trust. The agent does the work, you stay in control of what reaches production, and when something goes wrong, by the agent or by you, you can take it back. That's the ground the agent era needs, and with Vercel, you're already standing on it. Today, Vercel Agent can investigate anomalies, open PRs, and answer questions about your apps and agents in production. Soon, it will delegate to specialists on demand, like deep security review across your codebase, or design and UX review of your frontend. Vercel Agent is rolling out gradually to teams on Pro and Enterprise. , or enable it in the "Agent" section of your dashboard sidebar once it's available to your team.Request access Read more What Vercel Agent does for you A new security model for agents in production Anti-fragile infrastructure What’s next Get started What you can do with Vercel Agent Tell it to look at a PR and it flags performance regressions and risky changes that a passing CI run won’t show.Review a pull request. Ask why your bill jumped and it finds the culprit, like a code change that server-renders a page on every request instead of caching. With approval, it writes the fix and opens a PR. Trace a cost increase. Point Vercel Agent at a failed deployment and it reads the logs, finds the failing config, asks permission to update it, and tests the build in a sandbox. Fix a broken build. Ask about a feature flag and it reads the code and live metrics, then tells you whether it's safe to roll out.Check if you're clear to ship. Vercel Agent has its own identity The plan is the permission Generated code runs in a sandbox The agent's actions are always distinguishable from yours. Every change records who asked for it, who approved it, and that Vercel Agent carried it out. Nothing it does is untraceable.Attribution: A separate identity doesn't mean separate power. The agent doesn't inherit your access; it gets only what plan approval explicitly grants, and never more than the person directing it already has. Authority: