Vercel NewsSource publication:
Loading content…
When Vercel Agent works on a production problem, it investigates automatically under read-only access, then proposes a plan listing the tasks it would do and the permissions they need, and only after the user approves that plan does it receive access beyond the read-only baseline. Access is defined by scopes, the named capabilities recognized by Vercel's authorization system; a plan requesting more than the baseline, or including supported external actions, waits for approval as a whole, and the runtime checks the plan is active before selecting its approved credential while Vercel APIs check each request against that credential's permissions.
Vercel Agent splits work on production into two permission stages: investigation runs automatically under read-only access, while changes require a plan the user reviews and approves in one decision. Granting an agent broad access lets a mistake affect unrelated resources, while asking for approval at every step makes the user approve individual actions before knowing how the agent intends to solve the problem, and repeated prompts can turn review into a habit of clicking approve. For a broken production deployment, Vercel Agent inspects recent deployments and build logs and compares the failed deployment with the last known-good one, all under read-only access; if that points to a redeploy, it requests the additional access in a plan the user can review.
Permissions are expressed as scopes, the named capabilities recognized by the Vercel authorization system, and a plan connects the requested outcome, the proposed tasks, the scopes those tasks require, and the credentials and API checks that enforce the limits. The read-only baseline currently includes every registered scope beginning with read:, and plans need approval when they request access beyond that baseline or include supported external actions such as opening a GitHub pull request, with the whole plan waiting, including any read-only tasks it contains. Each stored plan records its tasks and progress with requested scopes attached to each task, task descriptions explain why access is needed, and scopes are combined across the plan; a short read-only lookup can run without a plan, while longer investigations get a read-only plan so the user can follow progress.
After approval, a token is prepared containing the read-only baseline plus the approved permissions, and the runtime checks the plan is active before selecting that credential, which remains subject to its scopes, team, the user's permissions and expiry. Vercel Agent runs as a Vercel App that the user authorizes to act on their behalf within a team, and that authorization is limited by the user's existing permissions, so approving a plan cannot grant access the user does not have. The Vercel OAuth service exchanges that authorization for shorter-lived tokens with specific scopes, and Vercel APIs check the token on each request; if the agent attempts an operation outside the token's permissions, the APIs reject the request even if the model considers the action necessary.
The mechanism targets Vercel Agent acting on production resources on a user's behalf within a Vercel team, covering plan validation, approval, token preparation and resuming work; the read-only baseline currently includes every registered scope beginning with read:, and other systems may need a narrower baseline.
Read-only operations can still expose sensitive information, so automatic approval does not mean the work is harmless; scopes are chosen with incomplete information, so the agent can request too little and leave a task blocked or too much and grant more authority than needed; a denied operation could mean a missing scope, an incorrect resource or an operation that should remain blocked. Sharing scope definitions adds latency and a service dependency, so the catalog is cached and that copy is used to check stored plans until it is refreshed from the registry.
