OAuth Scope Design for AI Agent Tool Integrations
Over-scoped tokens turn prompt injection into full-system compromise.
OAuth 2.1 was built for a world where a human clicks "Allow" and an application receives a bounded grant. AI agents break that model before the first tool call completes. The fix isn't a better scope string. It's a layered authorization architecture that starts with what OAuth can express, extends it at the runtime layer, and accepts that some pieces are still research.
Where OAuth's mental model was built and why it fits single-domain human-to-service auth
OAuth 2.1 consolidates the security best practices accumulated across OAuth 2.0 and its extension ecosystem into a single specification. It covers user-delegated authorization, where a resource owner grants an application limited access on their behalf, and machine-to-machine authorization, where a service acts on its own identity. Both cases assume something important: that the thing requesting access, human or machine, is the thing that will use it.
The mental model is a consent screen followed by a token. A user delegates calendar read access to an application, and that application presents the token on subsequent calls. The semantics are operator-level, meaning the token authorizes a type of action. It does not authorize a specific instance of that action with specific values. This distinction worked when applications were predictable and users were present at delegation time. The authorization server could remain a simple mint: issue tokens, validate them, revoke them. The hard questions about what a token should permit were answered once, at login, by a human reading a scope description.
That architecture assumes a single domain of trust. The authorization server knows the user, the client, and the resource server. Federation exists, but it is pre-established and negotiated out of band. Nothing in the model anticipates an agent that wakes up, decides to call a payment API, then delegates a subtask to another agent it discovered five minutes ago. The baseline is worth naming precisely because the critique that follows is structural, not a failure of implementation. OAuth does what it was designed to do, in the context for which it was designed.
Three structural limitations that make OAuth the wrong authorization layer for agents
Three properties of the OAuth model cannot be fixed by tightening scopes. They are built into the architecture itself. The first is that operator-level permissions cannot express operands. OAuth can authorize a TRANSFER operation, but it cannot authorize a transfer of a specific amount to a specific recipient. The amount and the recipient are operands, and no static scope string captures them. The researchers behind PAuth, from the University of Washington, Ohio State, and Microsoft Research, make this precise: operators describe what kind of action is permitted, while operations describe the operator plus its operands. OAuth authorizes the former. Agents need the latter.
Refining scope granularity does not close this gap. The result is that agents running on OAuth operator-scoped authorization are overprivileged by design. The token grants permission for the entire operator class, not the single operation the task requires.
The second limitation is the absence of holder-side scope attenuation. In a multi-step agentic workflow, where a parent agent decides to hand a subtask to a child agent, that round-trip is impractical. The parent must either request a fresh token for every delegation or hand the child the full token and trust it to behave.
The third is opaque delegation chains. Every trust domain also requires its own authorization server, with no mechanism for cross-domain token verification without pre-established federation. An agent that spans five services needs five federated authorization servers and still cannot reconstruct the chain of authority that led to any given tool call.
Why over-scoped tokens turn a localized exploit into an enterprise-wide incident
The structural gap becomes dangerous the moment an agent is compromised. The attacker does not have to escalate. The token has already done that.
The "god mode" anti-pattern is the clearest version of this failure. The constraint lives in the prompt, not in the permission system. The moment a language model is manipulated through indirect injection, the prompt-level guardrail vanishes, and the full admin authority stands exposed. This is not a vulnerability in the model. It is an authorization architecture that placed the enforcement point where an attacker could reach it.
Arcade's 2026 integration guide identifies the two failure modes engineering teams fall into. Verizon's 2024 Data Breach Investigations Report gives the risk concrete form: credential abuse was involved in 77% of web application breaches. Agent tokens are credentials, and over-scoped ones are credentials with a blast radius measured in integrations, not resources.
Static service accounts are the most common shortcut and the most dangerous. The token itself is the entire security boundary, and it never asks a question. Engineering teams that need to prove this risk concretely can work with platforms built for agent security testing, such as Armorer Labs, which applies an attack against an isolated twin of the agent and then verifies that the smallest possible safeguard stops it without breaking approved workflows.
Operation-level scope naming that the authorization server, consent UI, and audit log can all parse
The first constructive move is to make scopes as expressive as the OAuth model allows. A tool:resource:action naming convention is the smallest change that narrows this without abandoning OAuth. The scope becomes tool:calendar:create-event rather than write:calendar, and the authorization server can now reason about the specific operation class, not the entire resource type.
The token's other fields must be set deliberately, not left to defaults. The aud claim binds the token to a specific resource server, so a token minted for one API cannot be replayed against another. Expiry is set to a tight window so a leaked token has a short useful life.
Namespace separation matters as much as granularity. Mixing human-delegated API scope namespaces, such as calendar, with agent-delegated operation scope namespaces, such as tool:calendar:create-event, in the same authorization server makes auditing impossible. The two namespaces must be kept distinct so audit logs can distinguish who authorized what class of action. The runtime layer must handle what scope naming cannot. Teams can validate that a narrower naming convention actually blocks over-privilege by testing it against realistic agent workflows before shipping, confirming that tighter boundaries stop unauthorized operations without breaking legitimate tasks.
The permission intersection model and why it must run at the runtime layer, not at login time
The architectural pivot is the recognition that authorization decisions for agent tool calls cannot be made at login time, in the prompt, or in application code. They must be evaluated at the moment of tool invocation, where user identity, agent identity, and the specific bounded execution context converge. Arcade's 2026 integration guide identifies the runtime as this control point: in an agentic architecture the agent already mediates between user and infrastructure, so a traditional API gateway in front of tool calls is a redundant hop that cannot see into the execution context that matters.
The rule at this layer is the strict intersection. The agent's effective authority is always the intersection of its own baseline permissions and the requesting user's permissions. If a user cannot delete a record, the agent acting on their behalf must fail on the same action, regardless of the agent's theoretical capabilities. It is never the union, never evaluated at login time, and never enforced in application code. The evaluation happens per action, at runtime, at the enforcement point where the tool call is about to execute.
On-Behalf-Of execution implements this model. The agent acts with the user's credentials, scoped to the user's native permissions. The agent runs on a service identity, and the intersection collapses to whatever that identity holds.
Credentials must be handled so the model cannot touch them. OAuth tokens are vaulted at the runtime layer, where the language model cannot observe, alter, or exfiltrate them. The runtime resolves credentials, evaluates the intersection, and executes. The model never sees a token.
Human approval gates for destructive actions, such as deletes, bulk updates, and external communications, are enforced at this same layer, not expressed as system prompt instructions. The prompt cannot be the enforcement point, for the same reason the prompt cannot carry admin credentials. The accountability mechanism is what makes the model verifiable after the fact.
What OAuth cannot fix even with a better runtime: the post-fulfillment activation gap
A better runtime closes the user-agent-context gap, but it does not close the resource-acquisition gap. The problem surfaces when an agent acquires a new resource: an API credential returned by a tool call, a compute instance, a registered sub-agent. The authorization that permitted the acquisition does not determine by itself whether the returned resource may become usable authority.
Zhu and Wang's provenance-bounded runtime authorization architecture names this the post-fulfillment activation gap. Every transaction-side predicate is satisfied, but the activation predicate must be false. Acquisition is not activation.
The six-event model separates propose, reserve, dispatch, quarantine, resolve, and activate. The returned resource is quarantined, recorded without exposing usable authority, until a new authorization decision is made over its actual resolved capability, not its acquisition parameters. In a registered 18-case staged MCP-to-Docker composition, none of 16 unsafe paths added an unauthorized Docker start request.
The practical implication is straightforward: any agent that can call a tool returning credentials needs a separate activation check. The runtime intersection model evaluates whether a tool call is permitted. It does not evaluate whether the thing the tool returned should become usable authority. Those are two different decisions, and the second one has no home in OAuth at all.
Argument-level enforcement: why checking the tool is not enough when parameters carry tainted provenance
Authorizing a tool call at the tool level is insufficient when the security risk lives in the argument values, not in which tool is called. An email tool, a database-update tool, or a code-execution tool may require that its arguments derive from authorized user intent, verified tool outputs, or explicit approval. The permission check must be argument-scoped, not just tool-scoped.
ToolFence, a 2026 research system, demonstrates this approach. It uses a typed authorization blueprint, provenance-aware argument binding, a deterministic monitor that checks every proposed call, and a runtime capability grant for cases where the blueprint is incomplete. Authority-sensitive arguments from untrusted sources are refused before the model is even consulted for a judgment.
PAuth operationalizes the same principle at the server level. Server-produced values are wrapped in signed envelopes that bind concrete values to symbolic provenance, so that even a compromised agent cannot alter operands without detection. Evaluated on AuthBench across five service suites, all 100 benign tasks were authorized, and all 634 of 634 adversarial calls were blocked.
The four layers are each necessary. OAuth handles operators. The runtime intersection model handles user-agent-context. Activation checks handle acquired resources. Argument-level provenance handles tainted parameters. Remove any one layer and the system has an unguarded path.
A working scope design checklist: what to apply now and what is still emerging
Scope design for AI agents requires decisions across these four layers, and only some have production-ready tooling today. Adopt tool:resource:action operation-level scope naming and enforce separate namespaces for human-delegated and agent-delegated permissions. Use RFC 9396 Rich Authorization Requests to bind tokens to specific task contexts with tight expiry windows, typically five to fifteen minutes, and note that the RFC itself does not specify a recommended range. Vault all OAuth tokens at the runtime layer, never in the LLM context. Replace static service accounts with OBO execution evaluated at every tool invocation. Enforce the permission intersection rule at the runtime layer, not at session establishment. Require human approval gates for all destructive actions at the runtime enforcement layer. Export every tool call via OpenTelemetry to a SIEM from day one. Adopt the MCP 2026-07-28 authorization revision for servers classified as OAuth resource servers, including mandatory resource indicators and step-up flows.
Engineering teams deploying agents with real tool access face the hardest version of this problem: verifying that a safeguard stops the actual attack without breaking any approved workflow. Armorer Labs tests attacks against an isolated twin of the agent, applies the smallest possible safeguard, and re-runs every approved workflow to confirm nothing breaks. The result is a Verified Change Record that a release approver can sign and reproduce. The methodology maps onto the layered gaps directly: attack proof at the tool-invocation layer, minimal safeguard at the runtime enforcement layer, workflow re-verification before anything ships to production.
The still-emerging patterns require honest caveats. ToolFence's authors note no adaptive-attacker evaluation and reduced utility when legitimate authority-sensitive values exist only in untrusted sources. The correct posture is to ship what works now and track the research closely, because agent authorization is being rebuilt in real time.
