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

At a glance

What this is: NHI Mgmt Group's analysis, drawing on WorkOS's blog post: Draft OAuth extension lets users delegate explicitly to named AI agents while preserving an auditable record of which agent acted on which user's behalf.

Why it matters: It matters because IAM teams now have to distinguish agent consent, agent authentication, and downstream auditability instead of treating agent activity as if it were ordinary user delegation.

Context

OAuth delegation breaks down when an AI agent acts on behalf of a user but looks identical to that user in logs and tokens. Existing flows can preserve user identity or service identity, but they do not natively express a named agent as the actor that performed the work.

For identity governance, the problem is not just authorization. It is attribution, consent, and traceability across the delegation chain. That makes this an agentic AI identity issue, even though the mechanism sits inside familiar OAuth flows.

Key questions

Q: How should teams handle failed delegation when an AI agent is not named in OAuth consent?

A: If a delegation flow cannot name the agent at consent time, treat it as incomplete for AI agent use. The user may still be authorised, but the governance model is missing the actor that will actually execute the work. That weakens auditability, revocation, and accountability. The safer pattern is to require a flow that binds the agent identity before access is issued.

Q: Why does agent identity need to be separated from user identity in OAuth flows?

A: Because user identity answers who approved access, while agent identity answers who performed the action. When those signals collapse, audit logs become ambiguous and incident response loses a reliable chain of custody. For AI agents, that ambiguity is not a cosmetic problem. It changes how teams prove consent, enforce scope, and investigate misuse.

Q: What are the signs that delegated AI access is too ambiguous to govern safely?

A: Look for logs that only show the human user, tokens that never record the agent, and downstream services that cannot distinguish a delegated action from direct user activity. Those are signs the delegation model is hiding the actor. If investigators cannot answer which agent acted, the governance model is under-specified.

Q: How should security teams govern AI agents that call APIs instead of using a UI?

A: Security teams should govern AI agents by treating each callable action as a scoped entitlement, not as a general application login. The key control is to limit which APIs, data sources, and write actions the agent can chain together in one session. That keeps machine-paced behaviour inside a reviewable boundary instead of relying on human-style session assumptions.

Technical breakdown

Why existing OAuth delegation patterns blur agent identity

Authorization Code makes the user look like the caller, while Client Credentials removes the user entirely. RFC 8693 token exchange improves downstream delegation by preserving user context and adding act claims, but it is still a back-channel pattern that assumes the user already approved a service path. That assumption works for ordinary services and breaks when an AI agent creates its own action sequence at runtime. Microsoft’s OBO pattern adds agent-specific claims, but it remains platform-specific and still inherits the same delegation model limits. The core technical gap is not token format alone. It is whether the protocol can represent a named agent as the actual actor in a user-approved delegation chain.

Practical implication: treat standard OAuth delegation as insufficient for agent attribution unless the token flow can name the actor and carry that identity into audit logs.

How requested_actor and actor_token bind consent to a specific agent

The draft’s two new parameters solve the identity binding problem in different places. requested_actor is sent on the authorization request so the consent screen can name the agent the user is approving. actor_token is sent on the token request so the authorization server can verify that the calling agent matches the one the user saw and approved. That creates a three-way binding across user, client, and actor. The resource server can then see the user who consented, the client that ran the flow, and the agent that executed the action. This is what closes the audit gap without collapsing the agent into the user or pretending the client and actor are the same thing.

Practical implication: design consent and token validation together so the approved agent identity cannot be swapped after the user grants access.

Why the act claim matters more than a new token shape

The act claim is the useful part of the resulting JWT because it gives the resource server a machine-readable record of delegation. sub identifies the user, azp identifies the client, and act.sub identifies the agent. That separation turns ambiguous activity into queryable evidence, especially in compliance and incident response workflows. It also supports chained delegation when paired with existing token exchange patterns, although multi-hop enforcement is still an open area. In practice, the value is not just stronger tokens. It is that downstream systems can distinguish direct user action from delegated agent action without resorting to heuristics or log inference.

Practical implication: require downstream services to log and evaluate sub, azp, and act together rather than relying on a single principal field.

Threat narrative

Attacker objective: The practical objective is to make delegated agent actions indistinguishable from user actions, or to exploit that ambiguity when tokens and logs do not name the agent.

1. Entry occurs through ordinary OAuth delegation, where a user-approved agent receives a token that looks like a user token unless the flow carries agent identity explicitly.
2. Escalation appears when the resource server cannot distinguish delegated agent action from direct user action, allowing the same token shape to hide who actually initiated the call.
3. Impact is audit ambiguity and consent ambiguity, which weakens incident investigation, least-privilege enforcement, and accountability for AI agent activity.

Breaches seen in the wild

• Microsoft verified publisher OAuth phishing 2022: Malicious OAuth apps with a fraudulently obtained Microsoft verified publisher badge tricked UK users into granting mailbox access in 2022.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

OAuth delegation for agents is no longer just an authorization problem, it is an attribution problem. Existing OAuth patterns can prove that a user or service obtained a token, but they do not reliably prove that a specific agent performed the action. That gap matters because agent activity changes accountability, incident response, and policy enforcement. The implication is that identity governance for agents must treat actor naming as a first-class control, not metadata.

Front-channel consent is the missing governance checkpoint for agentic delegation. Back-channel token exchange preserves context after the fact, but it does not force the user to approve a named agent at the moment of delegation. That assumption was designed for services forwarding intent, not agents creating intent. The implication is that delegated AI access needs a consent model that is explicit about the actor, not just the scope.

Named actor binding is a distinct control gap, not a token format preference. The draft’s value is not that JWTs are fashionable, but that the token can carry a durable link between user, client, and agent. Without that link, audit logs remain ambiguous and revocation decisions become guesswork. Practitioners should treat actor binding as part of the identity lifecycle for agents, not as an optional claim.

Delegation chains will force identity teams to rethink the boundary between client and actor. In agent systems, the app that interacts with the user is not always the entity that decides or executes. That distinction was easy to ignore in human-centric OAuth deployments and becomes unavoidable in AI agent systems. The implication is that authorization architecture must be designed around who decided, who consented, and who executed.

Actor identity is the control plane for agent governance. Once agents can act across multiple APIs and downstream services, the ability to name the actor becomes the foundation for scope review, detection, and offboarding. That is especially important for organisations already struggling to separate human and non-human access in audit trails. The implication is that identity programmes need one model for all three: user, service, and agent.

From our research library:

• Gartner predicts that by the end of 2026, 40% of enterprise apps will feature task-specific AI agents.
• Read next: AI Agent Authorisation Guide

What this signals

Named actor binding will become a baseline expectation for agentic IAM. As AI agents move from experimental workflows into routine delegated access, the industry will need a consistent way to answer who acted, not just who authenticated. That shifts governance from session-centric thinking to actor-centric thinking across consent, tokens, and audit trails.

Consent screens that only name the application will age poorly. Agent systems need a clearer delegation model because the host app is not always the decision-maker. The practical result is that identity teams should expect pressure to expose actor identity in consent, logging, and review workflows rather than treating it as an implementation detail.

For practitioners

• Separate user, client, and agent identity in your OAuth design Model the human, the hosting application, and the AI agent as different principals so logs and tokens do not collapse them into one identity.
• Require named-agent consent for delegated access Make the consent screen show the agent the user is authorising, not just the app or resource being accessed, so delegation is explicit.
• Validate actor binding at token issuance Check that the actor token matches the requested_actor value before minting an access token, otherwise one agent can reuse another agent’s delegation grant.
• Log delegation claims in downstream services Store sub, azp, and act together in your audit trail so investigators can reconstruct which user, client, and agent produced each action.
• Plan revocation around agent delegation, not just user sessions Treat delegated agent access as a separate lifecycle that can be withdrawn without disabling the user’s own access.

Key takeaways

• OAuth delegation for AI agents fails when the token flow cannot distinguish the user, the client, and the actual agent that performed the action.
• The article’s main contribution is a draft pattern that makes delegated agent identity visible in consent, token issuance, and audit logs.
• For practitioners, the control question is no longer whether access was authorised, but whether the approved actor can be proven end to end.

Key terms

• Delegated Agent Identity: An identity used by one actor to act on behalf of another under explicit scope and policy. In agentic environments, this can describe both human-authorised assistants and machine-to-machine handoffs, so the delegation path must remain auditable at every step.
• Actor Binding: The process of tying a specific agent, service, or workload to a consent grant or access token. For AI agents, actor binding prevents one principal from replaying another principal’s delegation and gives downstream systems a stable reference for logging and enforcement.
• 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.
• 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.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.