The OAuth Scope Your Agent Acquired Across Chained Tool Calls

A user clicks "Authorize" on your agent's consent screen once. By the time the session ends, that agent has chained through eleven tool calls, negotiated three step-up authorizations, and now holds the union of scopes across every tool it touched. The user remembers granting one thing. Your audit log shows read-write access to half their account. The OAuth standard says everything is working as designed, and that is exactly the problem.

The classical OAuth consent model was built for a world where one app talks to one API. Agents shattered that assumption two years ago and the standard has not caught up in practice, even where the spec has. The result is a category of silent privilege escalation that no one decides to ship — it accretes, one tool registration at a time, while your security review keeps inspecting the front door.

Consent is a one-shot event, scope is a stateful property

OAuth's consent screen is designed as a moment: the user reads a list of scopes, clicks approve, and the app receives a token. The mental model the screen plants is "I authorized this app to do these things." That model holds for a static integration where the requested scopes correspond to a fixed set of API calls the app will make.

It does not hold for agents. The agent at session start does not know which tools it will invoke. The orchestration framework lets the model choose tools dynamically. Each tool may need a scope the agent did not previously hold. The pragmatic patch most frameworks ship is to compute the union of scopes the agent might need across its registered tool catalog, present that union once at the start, and hand the agent a token wide enough to cover the worst case it could plausibly hit.

The user, presented with a long scope list, either skims it or trusts the brand and clicks through. The agent now has a session-long token with the maximum scope envelope across its entire tool graph, regardless of which tools the user actually wanted invoked. The OWASP Top 10 for Agentic Applications in 2026 places overprivileged identities and excessive agency in its top three concerns for a reason: a 2026 survey of 900+ practitioners found that 74% of respondents said their agents end up with more access than they actually need, and only 8% of organizations said their AI agents never exceed their intended permissions.

The architectural mistake is not that the framework asked for too much. It is that the framework collapsed a chain of decisions into a single decision. Each tool call is its own scope decision; the consent UI rendered the union of all of them as one screen.

The blast radius accretes across the tool graph

Imagine a research agent the user installed to "summarize tickets and email me a digest." That description maps cleanly to two scopes: read on the ticket system, send on the mail service. The user authorizes.

In practice the agent's tool catalog includes a calendar tool ("for scheduling follow-ups"), a CRM tool ("for context on the customer"), a Slack tool ("for searching team discussion"), and a file storage tool ("for attaching the digest"). Each tool registers its required scopes at install time. The framework computes the union, the user signs it once, and the running session now holds tokens that span six surface areas.

The agent's session log shows it actually used only two scopes for any given run. The security team's after-the-fact question — "what could this agent have done at the moment when it processed ticket #4912?" — has an answer the security team does not want to hear. The answer is "anything its session token permitted," and the session token permitted the whole catalog union, not the working subset.

This is the agent equivalent of the long-running container with root capabilities it never uses. The capability exists at every instant, the workload only exercises a slice of it, and the audit answer is the worst case rather than the realized case. In the container world we eventually wrote tools to scope capabilities to the minimal set the workload actually exercises. The agent world has not yet built the equivalent muscle.

The user's mental model is several scopes behind reality

The deepest problem is not technical, it is consent integrity. The user agreed to a set of capabilities at session start. The agent invoked tools whose scopes were inside the original union but outside the user's mental model of what they approved. The legal question of whether the user actually consented is not settled by the OAuth flow — it depends on whether the consent screen communicated the realized authorization or the worst-case authorization.

A user who clicks "approve" on "your agent can read tickets and send mail" expects the agent to read tickets and send mail. That same user, if asked explicitly, "do you authorize this agent to search your private Slack channels for keywords related to the ticket subject," might say no. The Slack scope was on the original consent screen, buried in a list of twelve scopes. Legally, it is consented. Practically, the user did not consent to the realized action; they consented to a worst-case bundle.

Loading…