Notifications
Clear all
Topic starter
06/06/2026 2:12 am
TL;DR: A new IETF draft extends OAuth’s authorization code flow so AI agents can be named in consent, bound to token issuance, and traced in audit logs, closing the gap where user and agent actions look identical, according to WorkOS. The real shift is that delegation becomes attributable without resorting to impersonation or vendor-specific extensions.
NHIMG editorial — based on content published by WorkOS: OAuth's On-Behalf-Of flow for AI agents
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step walkthrough of the proposed OAuth parameter flow and token exchange sequence for named agents
- Decoded JWT examples showing how sub, azp, and act claims are expected to appear in practice
- Implementation notes on PKCE, consent-screen naming, and code binding for actor verification
- Comparison details across Microsoft OBO, RFC 8693 token exchange, and the draft's front-channel model
👉 Read WorkOS's analysis of OAuth on-behalf-of for AI agents →
OAuth delegation for AI agents: where existing flows fall short?
Explore further
06/06/2026 3:44 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: OAuth on-behalf-of for AI agents clarifies delegated identity
