Vercel Agent gets production access through a scoped plan and a single approval

Vercel has published a breakdown of how Vercel Agent gets access to live systems. The underlying problem is familiar to anyone who has tried giving agents production access: a request like "fix the deploy" does not say in advance which actions will be needed or which permissions they will require. Broad access means a mistake can hit unrelated resources. Confirming every step turns review into reflexive "Approve" clicking. Vercel chose a third path: the agent investigates first, then proposes a plan, and approving that plan grants exactly the additional permissions needed to carry it out.

The plan as the unit of permission

Here is how the scheme works for a broken deployment. The agent looks at recent deployments and build logs and compares the failed deployment with the last working one. Read-only access is enough for this, so the investigation runs automatically. If the investigation leads to a proposal to redeploy, the agent builds a plan and requests the read-write:deployment scope. The user sees both the action and the access it requires in a single decision.

The plan ties together four layers: intent (what the user wants), work (the agent's tasks), access (the scopes for those tasks), and enforcement (tokens and checks on the API side). Each saved plan stores the tasks, the progress, and the requested scopes, which are summed across all steps. The agent can run a short lookup without any plan at all. For long investigations, it creates a read-only plan so the user can follow the progress.

The baseline level currently includes all registered scopes with the read: prefix. Confirmation is required if a plan goes beyond that level or includes supported external actions, such as opening a pull request in GitHub. Vercel states explicitly that reading can also expose sensitive data, so automatic approval does not mean harmlessness.

Tokens the model cannot get around

Vercel Agent runs as a Vercel App that the user authorizes within a team. That authorization is limited to the user's own permissions, so approving a plan cannot give the agent anything the person does not have. The OAuth service exchanges the authorization for short-lived tokens with specific scopes, and the APIs check the token on every request.

An important detail: deployment write is broader than a single redeploy. If a plan names deployment X, that alone does not restrict the token to that deployment. For this reason, protection relies on several layers, and the model's instructions about when to ask for approval are not treated as a security boundary. If the agent tries to perform an operation outside its token, the API rejects it, even if the model decides the action is necessary.

Which credential is used depends on the work:

• investigation: the baseline token with read-only scopes;
• approved changes in Vercel: the baseline scopes plus the approved additional ones;
• external actions: the credentials and permissions of the specific provider.

A single plan can include both changes in Vercel and a pull request. The user reviews everything at once, but the providers use separate permissions. GitHub access is tied to an owner and repository: approval for acme/storefront does not extend to acme/payments, which needs its own.

A single scope registry and resuming work

At first, Vercel Agent had its own list of permissions, and it drifted from the OAuth service that issues the tokens. Now, when a session starts, the agent loads definitions from the shared scope registry into an in-memory catalog. The catalog is used to validate the plan (unknown and malformed names are rejected before the user sees the plan), to decide whether approval is needed, and to prepare the token.

If a task requests a scope that is outdated under the firewall rules, the system rejects the plan and returns a list of valid scopes, so the agent corrects itself instead of receiving broader access by default. The catalog is cached, so checks reflect its state until the next refresh.

Failures get separate treatment. An approval can arrive after the original chat has ended, or the connection can drop in the middle of a redeploy. The plan stores its state, who approved it, and when. Before continuing, the runtime reloads the plan and checks that it is active. A stopped plan fails the check even if the token still has time left. If an approval and a stop arrive at the same time, the plan moves from pending to active only if the stop has not already changed its status. Replacing a plan with one that has elevated permissions requires approval again.

What was left open

Vercel candidly lists the weak spots. The agent picks scopes with incomplete information and may request too little or too much. A valid scope can also be broader than needed. An API rejection can mean missing permissions, the wrong resource, or an operation that must remain forbidden, and the agent has to tell these apart. In addition, malicious instructions can hide in content the agent reads, such as build logs. For that reason, plans work alongside sandbox isolation, network policies, secret handling, limits, audit logs, and service authorization.

What to take into your own agent systems

For teams building agents for infrastructure, the scheme offers several guidelines. Separate investigation from modification. Show the person the action in plain language next to the scopes. Take permission definitions from the same source that issues tokens. Check that the plan is active before every use of a credential, not only when it is issued. And do not expect the model's instructions to constrain it on their own: the restrictions must live in the API.