OAuth on-behalf-of for AI agents clarifies delegated identity

At a glance

What this is: This is an analysis of an IETF OAuth extension that names AI agents in delegated authorization and preserves auditability across consent and token issuance.

Why it matters: It matters because IAM teams need delegation models that distinguish user intent from agent action while keeping consent, scope, and audit evidence usable across NHI and emerging agentic workflows.

👉 Read WorkOS's analysis of OAuth on-behalf-of for AI agents

Context

OAuth delegation breaks down when an AI agent acts inside a flow that still looks like a normal user session. The core IAM problem is not authentication, but attribution: without an explicit agent identity, a resource server cannot tell whether the action came from the human, the client app, or the agent runtime.

This draft addresses delegated identity for AI agents by carrying the agent through the consent screen and into the access token. That makes it an agentic AI governance issue first, and an OAuth plumbing issue second. It is most relevant where builders are trying to preserve user consent without collapsing audit trails into generic user activity.

Key questions

Q: How should security teams govern AI agents that act on behalf of users?

A: Treat the agent as a distinct actor in the authorization model, not as a hidden extension of the user. Consent should name the agent, tokens should preserve actor lineage, and logs should separate user, client, and agent. That is the difference between traceable delegation and anonymous automation.

Q: Why do delegated OAuth flows become risky when AI agents are involved?

A: They become risky when the flow proves the user approved access but does not preserve which agent executed the action. In that case, the audit trail collapses into generic user activity, and incident responders cannot distinguish agent behaviour from human behaviour. Attribution is the control at stake.

Q: What breaks when a resource server cannot see the agent behind a token?

A: The server loses the ability to enforce actor-specific policy, investigate misuse, or produce meaningful audit records. A valid user token may still be too blunt for delegated AI work if it hides the runtime actor. That is why actor claims matter in agentic identity.

Q: How do AI agent delegation flows differ from standard token exchange?

A: Standard token exchange propagates an existing delegation context, while agent-focused on-behalf-of flows are trying to create that context with explicit user consent for a named actor. Use consent-centric flows when the grant is being created, and use token exchange when the grant is already established and must travel downstream.

Technical breakdown

Why authorization code flow is not enough for AI agent delegation

The standard authorization code grant was built for a user and a client, not a user, client, and separate actor. In the normal model, the access token identifies the user, while the client remains mostly invisible. That is acceptable when the client is only a conduit for user intent. It fails when the agent makes runtime decisions about which actions to take. The draft extends the flow so the actor can be named during consent and bound during token exchange, which preserves delegation context without turning the agent into an impersonation layer.

Practical implication: review where your current OAuth flows erase the agent from the authorization story and treat those paths as attribution gaps.

The act claim and actor binding in delegated tokens

The draft’s key mechanism is the act claim, which records the agent as the acting party while sub still identifies the user. The requested_actor parameter surfaces the agent in the consent step, and actor_token proves that the agent requesting the token is the same one the user approved. That binding matters because it prevents a generic token from becoming a reusable delegation artifact. It also creates a cleaner audit trail for downstream APIs, which can log the user, client, and actor separately instead of flattening them into one session identity.

Practical implication: require token designs that preserve principal, client, and actor as separate identity facts in logs and policy decisions.

How this differs from token exchange and Microsoft OBO

RFC 8693 token exchange and Microsoft’s On-Behalf-Of pattern handle downstream delegation, especially when one service calls another with a user context. They work best when intent is already established and simply needs to be propagated. The draft is trying to solve the earlier step, where the user explicitly approves a named AI agent before the agent starts acting. That makes it a front-channel consent problem, not just a back-channel propagation problem. In practice, the two patterns can complement each other: the draft can establish the original delegation, and token exchange can carry that delegation deeper into service chains.

Practical implication: decide which hop needs explicit consent and which hop only needs token propagation, then apply the right OAuth pattern to each.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Delegated identity for AI agents is now an access governance problem, not just an OAuth variant. Once the agent is a separate runtime decision-maker, the issue is no longer whether a user logged in. The issue is whether the system can preserve who delegated, who acted, and under what scope when the actor is not the same entity as the human principal. That shifts the control question from session management to actor-bound authorization.

The act claim creates the missing audit primitive for agentic workflows. Most IAM logs were never designed to answer which agent took which action on behalf of which user. By separating sub, azp, and act.sub, the draft gives downstream systems a way to preserve delegation lineage. That is especially relevant for compliance, incident response, and abuse detection in MCP-style integrations. Practitioners should treat auditability as a first-class design requirement, not a logging afterthought.

Classic OAuth consent assumed user-paced decisions, but agents create their own intent at runtime. That assumption was designed for a person approving a client request in a browser. It fails when the actor independently decides what tool to call, when to call it, and how to chain actions. The implication is not merely stronger consent wording. It is a redesign of delegation controls around actor identity, not just user approval.

Front-channel consent and back-channel propagation should be treated as different governance layers. The draft addresses explicit user consent to a named agent, while token exchange remains useful for downstream service calls. These are not interchangeable patterns. IAM teams that blur them risk either over-trusting service propagation or under-supporting explicit delegation. The practical conclusion is to govern the initial delegation and the downstream chain separately.

Named actor delegation will become a baseline expectation for agentic access models. As AI agents start operating across enterprise APIs, the market will move toward identity systems that can distinguish the agent from the human and the client from the actor. That direction aligns with OWASP Agentic AI Top 10 and NIST AI Risk Management Framework concerns around provenance, accountability, and scope control. Practitioners should assume generic bearer tokens will age poorly in agent-heavy architectures.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That visibility gap makes OWASP Agentic AI Top 10 and other agent governance controls a forward-looking priority for security teams.

What this signals

Delegation-lineage controls will become a practical requirement as AI agents move into production workflows. The issue is no longer whether an agent can call an API. The issue is whether the programme can prove who approved the delegation, which actor executed it, and whether that lineage survives downstream hops. That is the governance pattern teams should build into IAM, PAM, and MCP-adjacent architectures now.

Actor-bound consent is the new baseline for keeping audit trails usable. With 80% of organisations already seeing agents exceed intended scope, according to AI Agents: The New Attack Surface, generic bearer-token thinking is not keeping pace with runtime behaviour. Teams that still treat agent access like ordinary service access will struggle to answer compliance questions later.

Delegation lineage debt: this is the gap that appears when a programme can issue access but cannot prove which runtime actor exercised it. That gap will affect investigation quality, access reviews, and policy enforcement across agentic and non-agentic systems alike.

For practitioners

• Separate user, client, and actor identity in your authorization model Map every delegated flow so the user who consented, the client that ran the flow, and the agent that performed the action remain distinct in policy, token claims, and logs. Treat any path that collapses those roles into one session as an audit gap.
• Require actor-bound consent for agent-driven permissions If an AI agent is being granted access, make the consent screen name the agent explicitly and bind the authorization code to that actor before token issuance. That prevents generic delegation from becoming reusable by an unapproved runtime.
• Preserve delegation lineage across downstream hops When an agent calls other services after the initial grant, carry the original delegation context forward instead of minting opaque tokens that hide the actor chain. This is especially important for MCP servers and service meshes that need per-hop accountability.
• Review where token exchange is still doing consent work Use RFC 8693 or OBO only where the user’s approval already exists and the next hop only needs propagation. If the first grant is meant for a named agent, do not rely on back-channel exchange alone.

Key takeaways

• OAuth delegation for AI agents fails when user identity is preserved but actor identity disappears.
• The practical scale of the problem is already visible, with 80% of organisations reporting agents acting beyond intended scope.
• Security teams should move toward actor-bound consent and delegation lineage if they want audit trails that investigators can actually use.

Key terms

• Actor-bound consent: A delegation model in which the approved actor is named explicitly during authorization, not implied by the client or user session. In agentic systems, this preserves who was allowed to act and prevents delegated access from collapsing into anonymous application behaviour.
• Delegation lineage: The traceable chain that shows which user approved access, which client initiated the request, and which agent or service executed the action. It is essential for auditability because it lets investigators reconstruct authority across hops instead of inferring intent from logs.
• Act claim: A token claim used to identify the actor performing an action on behalf of a principal. In delegated AI and service flows, it separates the human principal from the runtime actor so downstream systems can enforce policy and generate accurate audit records.
• Front-channel consent: An authorization pattern where the user sees and approves delegation in the interactive authorization flow before tokens are issued. For AI agents, this matters because the consent step must name the actor being empowered, not just the app or client.

Deepen your knowledge

OAuth delegation for AI agents is covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are designing consent and audit flows for agentic access, it is a strong fit for your programme.

This post draws on content published by WorkOS: OAuth's On-Behalf-Of flow for AI agents. Read the original.