- Vercel describes an agent that investigates production with read-only access, then asks a person to approve one plan before it changes anything.
- Vercel says the limit sits in short-lived, scoped tokens that its APIs check on each request, not in the model's instructions.
- Vercel states that a valid scope can be broader than the plan's wording, so leaders should ask what a credential really permits.
Approval that people actually read
Asking a person to approve every step of an AI agent's work sounds careful. Vercel argues it is not. In a post on how Vercel Agent reaches production systems, the company says repeated prompts can turn review into "a habit of clicking approve." The opposite choice has its own cost. Broad standing access means one error can spill onto systems the task never touched.
The trouble starts with a loose request. "Fix this deployment" hides the actions and the permissions the job will eventually need. Vercel's answer is to move the approval from the step to the plan.
This shows a broader point. The useful question is not whether a human is in the loop. It is what that human can see at the moment of the decision, and what the system enforces if they approve.
Investigate first, ask once
Vercel Agent starts by investigating. For a broken production deployment, Vercel says it might inspect recent deployments and build logs. From there, it sets the broken release beside the most recent one that worked. Read-only access lets that work run automatically.
If the investigation points to a redeploy, the agent proposes a plan. The plan lists the tasks and the access they need. The user approves it in one decision.
Vercel defines the read-only baseline as every registered scope beginning with "read:". A scope is a named capability in Vercel's authorization system. Any plan that reaches past that baseline is approved or refused whole, so even its look-only steps wait. Steps that leave Vercel, such as a GitHub pull request, also trigger approval where Vercel supports them. Short lookups run without a plan. For longer investigations, the agent writes a read-only plan so the person can watch tasks progress while they run on their own.
How the limits are enforced
The agent is built as a Vercel App. A user lets it act in their name inside one team. That grant is bounded by what the user may already do. Vercel therefore says a plan approval cannot hand the agent more than the user holds.
Vercel's OAuth service turns the user's grant into short-lived tokens. Each token carries named scopes, for example viewing deployments or editing project settings. Vercel's APIs check the token on each request.
The model is not the gatekeeper. Its prompt guides when to seek approval. Should the model try something its token does not allow, Vercel says the APIs refuse the call, however necessary the model thinks it is.
Approval can arrive after the chat has ended, or the connection can drop mid-task. So each stored plan records its state, who approved it and when. When work restarts, the runtime fetches the stored plan again and confirms it is still active before picking a credential. A plan that has been halted is turned away at that check, Vercel says, even when the token it would use has not yet expired.
GitHub access works separately. Pull-request approval is tied to an owner and repository. Approval for acme/storefront does not cover acme/payments, even if the user can reach both.
The gap between the sentence and the scope
Here is the part leaders should read twice. A plan is written as actions, such as "redeploy the last successful build." A token is written as scopes. The two do not map one to one.
The permission a redeploy needs covers more than one redeploy, Vercel says. Writing one deployment's name into the plan does not confine the token to that deployment.
Think of a contractor's work order that says "fix the door on level three" while the keycard opens the whole floor. The paper describes the job. The card sets the limit. An approval is only meaningful when the person signing understands both.
Vercel acknowledges this. It describes the agent as picking scopes without the full picture. Guess too low and the task stalls. Guess too high and the agent holds power the job does not call for. Validation catches scope names that do not exist. A correctly spelled scope may still open more doors than the task requires. Vercel wants each plan to describe the change in plain terms and to show what the token will truly hold back.
One list of permissions, not two
Vercel also describes a quieter failure. It first kept a separate permission list for the agent. That list could drift away from the OAuth service that issues tokens, so a plan might request a renamed or removed permission.
The company now uses the same scope definitions for both. At session setup, the agent loads them from a scope registry into a cached catalog. Unknown or malformed names are rejected before a plan is stored or shown. Vercel notes the trade-off: stored plans are checked against the cached copy until it is refreshed.
What Vercel says is still open
The post is candid about limits. Looking is not always safe, Vercel cautions. Reading can surface sensitive details, so letting reads run unprompted is not a sign the work is harmless. The agent may also decide wrongly, or come across hostile instructions in material it reads, such as build logs. Scopes narrow the list of actions available, yet an action on that list can still do damage.
Around plans, Vercel layers sandboxing, network rules, handling of secrets, rate limits, audit logs and service-level authorization. It also says other systems may need a narrower baseline than its own. This is Vercel's account of its own design. The post offers no independent test or incident data.
Questions to put to your teams and vendors
If agents touch your production systems, ask what they can read before anyone approves, and whether that includes configuration and secrets. Ask whether a plan that names one resource limits the credential to that resource or to a whole class of actions.
Ask what happens to a credential when a plan is stopped. Ask where approvals and denials are logged. Ask whether the permission list the agent plans with is the same one that enforces access.
A plan is a promise written in plain words. The credential is the limit. Review both before you sign.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Vercel.
