Vercel explains how its AI agent gets approved, scoped access to production

Vercel has published a detailed account of how its AI agent, Vercel Agent, is allowed to act on production systems without being handed unrestricted access. According to the Vercel blog post, the agent first investigates a problem under read-only permissions, then presents a plan describing the work it intends to do and the additional access that work requires. Approving that plan is what grants the extra permissions.

Two bad extremes

The post frames the core problem as a choice between two failure modes. Give an agent broad standing access and a single mistake can affect resources unrelated to the task. Ask for sign-off on every individual action and the user ends up approving steps before understanding how the agent intends to solve the problem — and repeated prompts train people to click approve reflexively. Vercel's answer is to move the approval decision away from individual actions and onto a reviewable plan.

Plans define the permissions

Per the post, a plan links four things: the intent the user asked for, the tasks proposed to achieve it, the named capabilities (scopes) those tasks need, and the enforcement layer of credentials and API checks. Each stored plan records its tasks and progress, with requested scopes attached to individual tasks and task descriptions explaining why the access is needed.

Investigation runs without approval because the baseline permission set currently covers every registered scope whose name starts with read:. Any plan requesting something beyond that baseline — or including supported external actions such as opening a GitHub pull request — waits for approval as a whole, read-only tasks included. Vercel flags the caveat itself: read-only operations can still expose sensitive information, so automatic execution does not mean the work is harmless.

The user's permissions are the ceiling

Vercel Agent runs as a Vercel App that the user authorizes to act within a team, and that authorization is capped by the user's own permissions — approving a plan cannot manufacture access the user does not already have. The OAuth service exchanges the authorization for short-lived tokens carrying specific scopes, and Vercel APIs verify the token on every request, so an out-of-scope operation is rejected even if the model considers it necessary to finish the task.

The post is candid about granularity limits. Deployment write access is wider than a single redeploy, and naming a particular deployment in a plan does not, by itself, narrow the token to that deployment. A runtime component — the software coordinating the agent's execution — checks that a plan is still active before selecting its approved credential, and each request is then checked against that credential's scopes, team, and expiry.

For multi-provider work, a single plan can bundle Vercel changes together with a GitHub pull request, but permissions and credentials remain separate per provider. GitHub pull-request approval is tied to a specific owner and repository, so being cleared to open a pull request in one repo does not extend to another the user can access.

One source of truth for scopes

Vercel says it initially kept a separate permission list for the agent, which could drift out of sync with the OAuth service that issues its tokens. It now loads scope definitions from a shared Vercel scope registry into an in-memory catalog at session setup, and that catalog is consulted at three stages: plan validation, where unknown or malformed scope names are rejected before a plan is stored or shown for approval; the approval decision, where requested scopes determine whether the plan fits the read-only baseline; and token preparation for approved work.

If a task requests an outdated scope — updating firewall rules is the post's example — the proposed plan is rejected and the valid scopes are returned so the agent can correct it. That forces an explicit fix rather than silently widening access. Because fetching the registry adds latency and a service dependency, the catalog is cached, and stored plans are checked against the cached definitions until the catalog is refreshed.

Resuming work safely

Approvals can outlive the chat session that requested them. Stored plans carry their state, who approved them and when, which ties the authorized access back to the proposed work. Before resuming, the runtime reloads the plan and re-checks that it is active before selecting a credential; a stopped plan fails that check even if its token has not expired. Where an approval and a request to stop arrive together, the plan can only become active if the stop has not already changed its status. If investigation shows the current plan is inadequate, the agent can propose a replacement — and one requesting elevated access needs its own approval.

Why it matters

Letting agents operate on production is moving from demo to reality, and the hard part is authorization, not intelligence. Vercel's write-up offers a concrete, reusable pattern: batch approval into a reviewable plan, issue narrowly scoped short-lived tokens, enforce limits at the API layer rather than trusting model instructions, cap everything at the human's own permissions, and treat resumption and race conditions as first-class concerns. Its honesty about the gaps — read-only is not automatically harmless, and write scopes remain broader than the named resource — makes it a more useful reference for other teams than a perfect-sounding design would be.