On-behalf-of identity at machine speed: what AI agents change about delegated access

Our last piece laid out the four questions every CISO will be asked about AI agents in 2026. Who authorized this. On whose behalf. With what privilege. Can we prove it. This piece is about the technical pattern underneath all four. Delegated access, the on-behalf-of problem, has been a niche backend concern for two decades. AI agents have moved it to the center of enterprise identity, and the protocol answer already exists.

The short version. The hard problem in AI agent identity is how Service A makes a request to Service C, on behalf of User B, with verifiable authority and an audit trail. The IETF formally specified the answer to that question in January 2020 as RFC 8693, OAuth 2.0 Token Exchange. The agentic platform layer (Anthropic's MCP authorization model) and the enterprise infrastructure layer (AWS AgentCore Identity, Uber's published architecture, the Coalition for Secure AI's guidance) have independently converged on it. The protocol question is settled. The product question is what you put on top of it, and how you extend the same semantics to agents that do not natively speak OAuth.

What changed about delegated access

Delegated access is not new. WS-Trust was solving it in 2005. OAuth 2.0 was solving it in 2012. The IETF formalized the modern answer in 2020. For most of that history, the pattern lived inside backend microservices teams and a small group of API platforms. It was a service-to-service problem most enterprises never had to think about directly.

Three things changed with AI agents.

First, the volume. A single human request to an AI agent can fan out into hundreds of downstream actions across many systems. Every action requires its own answer to who is acting on whose behalf. The decision that used to happen once at login now has to happen at every hop, at machine speed.

Second, the chain length. Agents call other agents. An on-call agent calls an investigation agent, which calls an MCP gateway, which calls a database service. Each hop carries delegation forward. The audit trail is no longer a row, it is a tree, and any single hop that loses on-behalf-of context breaks the whole chain.

Third, the audience. Delegated access used to be invisible to security and compliance teams because it lived inside the application tier. Now it determines whether you can answer an auditor's question about who authorized an action. The pattern has moved from backend plumbing to a board-level identity question.

The pattern itself did not change. The scale, speed, and stakes did.

What is RFC 8693?

RFC 8693, OAuth 2.0 Token Exchange, is an IETF standards-track specification for a security token service. A client presents an existing token and receives a different token in return. One that is scoped, audience-bound, and carries an explicit record of who is acting on whose behalf.

Two parts of the spec carry most of the weight for agent workloads.

The act claim. When a token is issued through token exchange, the sub field carries the original principal (the human whose intent this action represents), and the act claim carries the agent, service, or workload actually performing the action. The audit trail no longer collapses into “the agent did it.” It records this agent did this, on behalf of this human, with this authority, at this moment. When agents chain through multiple hops, the act claims nest. The full chain of delegation becomes a property of the token itself.

The may_act claim. A user's token can carry an explicit list of which agents are allowed to act on their behalf. When an agent shows up at the authorization server requesting a token, the server checks the original user token and refuses the exchange if this specific agent is not pre-authorized. Zero-standing-trust for agents, enforced at the identity layer.

The whole specification fits in 40 pages. It has been a stable IETF standard for six years.

Why agentic platforms and enterprise infrastructure are converging on it

Every serious AI agent identity architecture published in the last year has landed on the same protocol family, even when the teams did not coordinate. The convergence has two sides.

The agentic platform side. Agents need a standard way to request access to enterprise resources.

Anthropic's Model Context Protocol authorization specification anchors agent-to-resource access on OAuth 2.1 with explicit audience binding through Resource Indicators (RFC 8707). The spec defines how MCP clients discover authorization servers, request narrowly-scoped tokens, and prevent token mis-redemption across servers. It is the open standard the agentic ecosystem has settled on, and the foundation other AI platforms are building on top of.

The enterprise infrastructure side. Enterprises need a standard way to delegate identity across hops while preserving auditability.

Uber published its agent identity architecture in May 2026. The token mechanism, in their own words, is conceptually based on OAuth 2.0 Token Exchange (RFC 8693), customized for internal auditing needs. The Oncall Agent calls into the Investigation Agent, which calls into the MCP Gateway, and every hop is a token exchange. Each one narrows scope and records who is acting for whom.

AWS shipped on-behalf-of token exchange in AgentCore Identity and reached general availability in April 2026, with the documentation calling out RFC 8693 by name. The Coalition for Secure AI, in guidance published after RSAC 2026, explicitly recommends RFC 8693 token exchange for MCP enterprise deployments: do not pass through user tokens to downstream services, exchange them for scoped tokens with explicit actor and subject claims, and narrow scope at each hop.

Each team, independently, looked at the agent identity problem, looked at the available protocols, and arrived at the same answer. That is convergence. And it means the protocol question is settled across both sides of where AI agents and enterprise systems meet.

Why on-behalf-of is the whole game

The four questions every CISO will be asked (who authorized this, on whose behalf, with what privilege, can we prove it) are four facets of one problem. Enterprise identity systems were built for one human, one credential, one session, one audit log. Agents change every one of those assumptions.

An agent is not one human. It is a piece of software acting on behalf of one or many humans, depending on the call. An agent does not have one credential. It has a chain of them, each issued for a specific hop, audience, and scope. An agent does not have one session. It runs continuously, across systems, often across customers. An agent's audit log is not one row. It is a tree of actions that has to be reconstructable across many systems, many tokens, and many trust domains.

The only way to make any of that legible is to encode the answer in the identity layer itself. The token carries who the action is for, who the action is by, the scope of authority for this specific call, and a verifiable chain of every hop that came before it. That is what token exchange does, as the shape of the protocol.

What about agents that do not speak OAuth?

This is the question identity teams ask the moment they hear “RFC 8693.” Most agents in real enterprise environments today do not start with an OAuth token. Browser extensions hold session cookies. Vendor copilots use bespoke SDKs. RPA bots use scripted credentials. LangChain pipelines call LLM APIs with bearer keys. MCP servers use their own token formats and may delegate to OAuth only at the boundary. The Vercel breach, the OpenAI Atlas exposure, and the Mexico Claude Code campaign each involved agents that did not share a common protocol.

The protocol RFC 8693 specifies is the answer for OAuth-native agents. The on-behalf-of semantics it formalizes (sub, act, may_act, audience binding, scoped exchange) are the answer for every agent, regardless of wire format. An agent gateway that implements RFC 8693 for OAuth and bridges non-OAuth workloads into the same semantic model is what makes the standard usable across a real enterprise estate.

RFC 8693 is the protocol. The semantics it formalizes are the requirement. The gateway is where the two meet, for every agent your enterprise actually runs.

Why we built our agent gateway on RFC 8693

We have been building Oleria's AI Agent Governance product on this primitive for the last several months. The authorizer at the heart of our gateway is RFC 8693-conformant token exchange. Every agent call passes through it. Every issued token narrows scope to the task. Every token records the original human in sub, the agent in act, and the chain of prior hops in nested act claims. Every audit log entry resolves to who acted, on whose behalf, with what authority, at what moment. Not as a forensic reconstruction after the fact, as a property of the request itself.

The next piece in this series goes one layer deeper. The specific design decisions on top of RFC 8693, where the standard ends and our work begins, and how we extend the same semantics to non-OAuth workloads.

What identity and security leaders should do this week

• Ask the AI agent platforms in your environment one question. How do you propagate user identity across hops, and what claim in the token records the agent as the actor. If the answer is not RFC 8693 token exchange (or an equivalent OBO mechanism) with an act claim, ask what it is and how it produces an audit trail when something goes wrong.
• For any agent that holds long-lived credentials of any kind (OAuth tokens, API keys, session cookies, vendor SDK tokens) with broad scopes, ask whether those scopes narrow at the call boundary. Long-lived plus broad-scoped is the exact failure mode Vercel, Context.ai, and the Mexico campaign exploited.
• Inventory which of your existing identity providers and gateways already support on-behalf-of token exchange. Microsoft Entra ID's On-Behalf-Of flow, AWS AgentCore Identity, Keycloak, and several others implement OBO patterns today. The protocol is available in most enterprise stacks. The configuration usually is not turned on.
• Add “RFC 8693 conformant token exchange with act and may_act claim support” to your evaluation criteria for any AI agent platform, agent gateway, or MCP infrastructure you are buying in the next twelve months. Ask where the on-behalf-of audit trail lives. The answers will sort the field in a single round.

Frequently asked questions

What is on-behalf-of identity?

On-behalf-of identity is the pattern where an intermediate service or AI agent acts on behalf of an upstream user. The action is recorded with both the original user identity and the intermediate actor identity, so downstream systems can enforce authorization based on both at once. It is the foundational pattern for delegated access in multi-hop systems, and the question every audit of an AI agent action eventually resolves to.

What is delegated access in the context of AI agents?

Delegated access is the practice of allowing a service, application, or AI agent to access resources on behalf of a user without holding the user's primary credentials. For AI agents, delegated access has to be scoped to a specific task, audience-bound to a specific downstream system, and traceable back to the human whose intent the action represents. The mechanism that produces those properties is on-behalf-of token exchange.

What is RFC 8693?

RFC 8693 is the IETF standards-track specification for OAuth 2.0 Token Exchange, published in January 2020. It defines a protocol where a client presents an existing token to a security token service and receives a different token, scoped to a specific audience, with explicit on-behalf-of semantics encoded through the sub and act claims.

Does Anthropic's MCP use RFC 8693?

Anthropic's Model Context Protocol authorization specification anchors agent-to-resource access on OAuth 2.1 with audience binding through Resource Indicators (RFC 8707). The core MCP spec does not mandate RFC 8693 directly, because token exchange is not universally supported across third-party APIs. However, the enterprise gateways that deploy MCP at scale (AWS AgentCore Gateway, Red Hat MCP Gateway, and others) layer RFC 8693 token exchange on top of MCP for delegation across hops. The Coalition for Secure AI's enterprise guidance explicitly recommends RFC 8693 as the OBO mechanism for MCP in production.

Why does RFC 8693 matter for AI agents?

AI agents make calls into downstream systems on behalf of humans, often across many hops. RFC 8693 is the standard protocol for encoding that on-behalf-of relationship into the token itself, scoping the token to a specific downstream audience, and preserving the full delegation chain in nested act claims. It is the protocol that both the agentic platform layer and the enterprise infrastructure layer have converged on as the foundation for AI agent identity.

Does AWS AgentCore Identity use RFC 8693?

Yes. AWS Bedrock AgentCore Identity reached general availability in April 2026 with on-behalf-of token exchange built on the RFC 8693 grant type, calling out the standard explicitly in its documentation. Uber's published agent identity architecture is also based on the same protocol.

How do you govern AI agents that do not use OAuth or MCP?

The protocol RFC 8693 specifies is the answer for OAuth-native agents. The on-behalf-of semantics it formalizes (sub, act, may_act, audience binding) are the answer for every agent regardless of wire format. An agent gateway implements the protocol for OAuth and bridges non-OAuth workloads into the same semantic model, so the same audit trail and least-privilege guarantees apply across the full estate.

The bigger pattern

Delegated access was a backend pattern for two decades. AI agents have moved it into the foreground of enterprise identity. The protocol answer has been in the RFC index since January 2020. Anthropic anchored the agentic protocol layer on OAuth. AWS and Uber implemented the on-behalf-of pattern in their agent infrastructure. The Coalition for Secure AI recommended it for enterprise MCP. The OAuth working group is extending it. The broader security industry has been slower to land here, and most agent governance pitches in the market today are still inventing proprietary alternatives to a problem the IETF has already solved.

The next pieces in this series show what we built on top of the standard. More on that soon.