OAuth and Token Delegation Patterns for AI Agents

OAuth 2.0 was built for a human sitting at a keyboard, clicking "allow," and doing something else with their day. AI agents don't do something else with their day; they don't have a day. They act continuously, at machine speed, without pausing for a prompt, and that single fact breaks the assumptions baked into every identity and access management pattern designed for people. The response is a set of concrete adaptations layered on top of the old protocol: scoped delegation tokens, RFC 8693 token exchange, and short-lived credentials with an audit trail that gets built in at issuance instead of reconstructed after something goes wrong. Per Oasis Security's 2025 research, the ratio of non-human to human identities in enterprise environments hit 144:1, up from 92:1 in just the first half of 2024. That growth curve is exactly why the gaps matter now and not later.

Four failure modes show up when human-shaped auth patterns get handed to agents. Long-lived sessions need token refresh across time, but there's no user around to re-authenticate when the token expires mid-task. Over-scoped tokens used to risk one bad click; now they can drive hundreds of API calls before anyone notices a thing is wrong. Agents are prompt-injectable in a way humans simply aren't: an attacker doesn't need to steal a private key, just needs to slip in an instruction that convinces the model to hand over a token it's already holding. And when an agent acts indistinguishably from the user it represents, nobody can say afterward who actually decided what. That last failure mode isn't hypothetical, and it's already showing up in the numbers. Only 28% of organizations, according to the Cloud Security Alliance, can trace an AI agent's actions back to a human sponsor across all of their environments. The other 72% are running on faith.

OAuth's defaults assume a human in the loop, and the rest of this piece is about what has to change once that assumption gets removed.

What OAuth 2.1 provides as a baseline for agent authorization

OAuth 2.1 cleaned house. It drops the implicit grant and resource owner password credentials, and it makes PKCE and HTTPS mandatory across the board. That matters more for agents than it ever did for humans, because the old flows leaned on error states a person could actually notice and react to, like a browser warning or a suspicious redirect. Agents don't notice; they execute.

Three flows cover almost every agent scenario worth building for. Client Credentials Grant fits the fully autonomous agent: no user in sight, the agent authenticates with its own registered credentials, and it gets back a scoped access token directly. Authorization Code plus PKCE fits the case where an agent acts on behalf of a specific person, reading their calendar or sending mail from their inbox; the user logs in, approves a scoped consent screen, and the agent gets a delegation token tied to that specific authorization. Token Exchange, defined in RFC 8693, handles the harder case: multi-hop delegation, where an existing token gets swapped for a narrower, shorter-lived one as authority crosses a service boundary. That third pattern deserves its own section, and it gets one.

The design principle underneath all three: treat every agent as its own OAuth client, with its own identity, its own scope set, its own token lifecycle, rather than a proxy account wearing a user's name.

Here's where 2.1 still comes up short: it gives builders the flows, not the delegation semantics. Knowing who's calling an API is not the same as knowing on whose authority they're calling it, and that gap gets wider with every hop an agent chain adds.

How RFC 8693 token exchange enforces least privilege across service boundaries

Hand an agent a human's token and it inherits far more privilege than any single task calls for. Token exchange is the mechanism that fixes this: swap the broad token for a narrow one, purpose-built for the task in front of the agent, nothing more.

RFC 8693 Section 4.1 defines two claims that do the actual work. sub is the original principal, the user who kicked off the chain, and it never changes no matter how far downstream the request travels. act is the current actor making the call, and it changes at every hop. When Agent B calls on behalf of Agent A, which is acting on behalf of the user, act nests: each layer stacks on the last instead of overwriting it. That nesting is the only honest way to represent a multi-hop chain, because collapsing it loses the very lineage the whole system exists to preserve.

This isn't theoretical anymore. Uber's agent identity architecture, published in May 2026, is conceptually built on RFC 8693 and customized for internal audit needs; an Oncall Agent calling an Investigation Agent calling an MCP Gateway is, at every hop, a token exchange that narrows scope and logs the actor. AWS shipped its own RFC 8693-based on-behalf-of token exchange inside AgentCore Identity in April 2026. Chain depth gets bounded by policy in these systems, typically 3 to 5 hops, and anything deeper gets rejected outright at the Token Exchange endpoint.

What RFC 8693 doesn't do is worth stating plainly. The act claim captures who called at each hop, not what they were allowed to do once they got there; you know the identity, not the constraint. The chain itself gets built unilaterally by the Authorization Server, with no cryptographic confirmation from the delegating agent that it actually agreed to the handoff. And the spec never says how a service is supposed to acquire the subject token in the first place, which pushes real implementation complexity onto whoever builds the system. An IETF Internet Draft, draft-liu-oauth-chain-delegation, proposes a delegation_chain JWT claim to close the verifiability gap. It hasn't been standardized, but it's a clear signal of where the working group's attention is headed.

The on-behalf-of pattern and where standard flows leave user consent unresolved

The on-behalf-of pattern draws one distinction that matters more than it sounds like it should: who the data belongs to is not the same question as who decided to act on it. Making that split explicit, instead of collapsing both roles into a single user identity, is the whole point.

Authorization Code Grant and Client Credentials both fall short here. Neither one has a built-in mechanism for getting explicit user consent for a specific agent action through the front channel, meaning the browser redirect the user actually sees. They were built for app-level delegation, granting an application broad access once, not task-level delegation, granting a specific agent narrow access for a specific job. RFC 8693 closes the inter-service exchange gap, but it was designed around server-side impersonation flows and has nothing to say about front-channel consent for agents either.

An IETF draft filed in 2025, draft-oauth-ai-agents-on-behalf-of-user, tried to close exactly this gap by extending the Authorization Code Grant for user-directed agentic delegation. It expired as an individual submission and isn't a ratified standard. So teams building user-facing agents today are stuck choosing between two imperfect paths: approximate on-behalf-of using Authorization Code plus PKCE and lose the agent's distinct identity in the process, or build a custom extension and own the maintenance burden. There's no off-the-shelf, standards-compliant answer yet.

That consent gap isn't just an unfinished standards problem sitting quietly in a draft repository. It becomes an attack surface the moment agents start chaining into other agents without a visible authorization checkpoint at each hop.

What breaks when agents call other agents without proper delegation chains

Two documented attacks from 2025 share the same root cause. Johann Rehberger's September 2025 write-up on Cross-Agent Privilege Escalation showed a compromised GitHub Copilot agent writing malicious instructions into Claude Code's configuration files; on startup, Claude Code loads the poisoned config and executes attacker-controlled code. Trust between agents was never built for agents that reason on their own and spawn subagents mid-task. Then, in November 2025, Palo Alto Networks' Unit 42 published research on Agent Session Smuggling, which exploits stateful Agent2Agent sessions by injecting covert instructions between legitimate client and server requests. The session layer assumed well-behaved clients on both ends, but agents aren't always well-behaved, and they don't need to be malicious themselves to get hijacked into acting that way.

Both attacks exploit the same structural gap: the protocols governing trust between agents were built for static service-to-service calls, not for agents that delegate dynamically while they're running. Two anti-patterns make this worse. Reusing the user's bearer token at every single hop means no chain gets recorded anywhere, full user scope propagates to every downstream agent regardless of what that agent actually needs, and a prompt injection at any single hop compromises the entire session. The alternative, giving each hop its own service-account credential with no chain linking them, loses attribution entirely, and per-service-account scope tends to run broader than any individual task requires anyway.

Prompt injection functions, in effect, as credential exfiltration wearing a disguise. The OWASP LLM Top 10 for 2025 names prompt injection as the leading risk facing LLM applications, and in an agentic auth context that risk takes a specific shape: an injected instruction can direct an agent to log its own access token to an external endpoint, or hand it off to an attacker-controlled sub-agent, all while looking like normal tool use from the outside.

One countermeasure worth watching: the draft-mw-oauth-tls-session-bound-tokens IETF draft binds each token to the specific mTLS connection it was issued on. Steal the token, and it can't be replayed on a different connection, which guts the value of exfiltrating it in the first place. The draft names multi-hop agent delegation as a primary motivation for existing at all.

How MCP's OAuth 2.1 mandate changes the implementation surface for agent builders

MCP has become the default way agents connect to tools and outside resources, and the June 2025 specification update wired OAuth 2.1 directly into it, adopting RFC 9728 for protected resource metadata along the way.

Here's how the flow works when an unauthenticated agent hits a protected MCP server: the server returns a 401 along with Protected Resource Metadata pointing to the correct authorization server, the agent registers through Dynamic Client Registration if it hasn't already, and then it runs whichever OAuth flow fits, client credentials for autonomous operation or authorization code plus PKCE when it's acting for a user.

The sharpest line in the spec sits in the July 2026 revision: "The MCP server MUST NOT pass through the token it received from the MCP client." Token exchange is what makes that rule survivable without losing user attribution; every hop mints a fresh token with a new audience while the underlying subject chain stays intact underneath it.

Three gaps remain even after that mandate. There's no mandatory credential revocation when a session closes, no consent gates exist for sensitive tool calls, and there's no mandatory audit trail requirement anywhere in the spec. MCP's OAuth mandate is a real floor that stops the worst anti-patterns cold, though the pass-through prohibition alone doesn't make a deployment secure. Builders still need to implement token exchange explicitly and bolt on audit infrastructure from outside the protocol.

The concrete adaptations that make OAuth work for agents in production

Scoped delegation tokens are the starting point: issue access at task granularity, not account granularity. A token grants one resource, for one operation, and it expires the moment that operation finishes, with nothing lingering around waiting to be misused.

Short-lived credentials should be the default, not the exception. Long-lived tokens are the single biggest amplifier of blast radius when an agent gets compromised or manipulated into acting against its own instructions. Short expiry paired with refresh token rotation shrinks the window a stolen token is worth anything, and the rotation record doubles as a built-in log of exactly when each credential got used.

RFC 8693 token exchange belongs at every trust boundary in the system, not just the convenient ones. Each agent in a chain requests a token scoped to its own role rather than passing through whatever it received from upstream. Depth limits, 3 to 5 hops enforced by policy, stop delegation chains from growing past the point anyone can actually audit them. Nested act claims preserve full lineage across the chain, and pairing that with a delegation_chain claim, once the Liu draft matures into something ratified, adds a layer of verifiability the current spec doesn't offer on its own.

Audit trails need to be a design constraint from the start, not a forensic exercise after an incident. With only 28% of organizations currently able to trace agent actions back to a human sponsor, closing that gap means baking structured metadata, sub, act, scope, issued-at timestamp, audience, into every log entry the moment a token gets issued, rather than trying to piece it together later from scattered service logs. A Cloud Security Alliance and Strata survey found 55% of respondents cite sensitive data exposure as their top concern with AI agents; the audit trail serves as evidence that exposure didn't happen when someone asks, alongside its role as a compliance artifact.

Distinct agent identities close out the list. Register each agent as its own OAuth client, separate from any shared service account riding on a generic credential. That way revocation, scope changes, and anomaly detection can target one misbehaving agent without taking down everything connected to it.

The standards are still catching up on three fronts: front-channel consent for agentic on-behalf-of flows, cryptographically verifiable delegation chains, and mandatory audit trails inside MCP itself. Drafts exist for all three, but none are ratified. Production systems built today have to bridge those gaps with custom middleware and platform-level controls, and that's not a temporary inconvenience so much as the current state of the field.