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.
Editorial analysis by NHI Mgmt Group, based on content published by WorkOS: “OAuth's On-Behalf-Of flow for AI agents”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: OAuth delegation for AI agents fails when the token flow cannot distinguish the user, the client, and the actual agent that performed the action.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/06/2026 3:44 am
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.
A few things that frame the scale:
- Gartner predicts that by the end of 2026, 40% of enterprise apps will feature task-specific AI agents.
A question worth separating out:
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.
👉 Read our full editorial: OAuth on-behalf-of for AI agents clarifies delegated identity