TL;DR: AI agents have turned on-behalf-of identity into the central delegated access problem, and RFC 8693 token exchange is emerging as the common protocol for preserving actor, subject, scope, and audit trail across multi-hop requests, according to Oleria Security. The real shift is that legacy identity assumptions about one user, one session, and one audit row no longer hold when actions fan out at machine speed.
At a glance
What this is: This is an analysis of how RFC 8693 token exchange is becoming the standard way to preserve delegated identity, scope, and auditability when AI agents act on behalf of users.
Why it matters: It matters because IAM teams now need to govern machine-speed delegation chains without collapsing actor, subject, and authority into a single opaque credential path.
Context
The security gap here is not authentication in the usual sense. It is delegated authorisation: when an AI agent acts for a human, downstream systems still need to know who authorised the action, who executed it, and what scope was valid at that hop.
AI agents change delegated access by multiplying the number of decisions, hops, and audit records that have to stay linked. The result is an identity problem that lives across OAuth, MCP-style gateways, and enterprise workloads rather than inside a single application boundary.
Key questions
Q: How should security teams govern AI agents that browse and transact on behalf of users?
A: Security teams should govern AI agents as delegated actors with narrow, task-scoped permissions, not as enhanced browsers. The right model is to bind access to the specific action being performed, preserve auditability at the transaction layer, and separate machine identity from the human principal wherever possible.
Q: Why do AI agents make delegated access riskier than traditional service-to-service calls?
A: AI agents increase risk because one human request can fan out into many downstream actions, often across several systems and other agents. Each hop creates another chance to lose scope, actor context, or audit fidelity, which turns a manageable delegation pattern into a governance problem.
Q: What breaks when credentials outlive a short-lived AI task?
A: When credentials outlive a short-lived task, the unused window becomes an exposure window. Attackers do not need to defeat the task itself if they can use the still-valid credential after the job ends. This is why token lifetime, task duration, and revocation timing need to be aligned as one control set.
Q: What is the difference between user identity and actor identity in agent delegation?
A: User identity identifies whose intent the action represents, while actor identity identifies what actually executed the call. In delegated agent workflows, both are needed at once so downstream systems can enforce policy, preserve auditability, and avoid collapsing a human decision into an opaque machine action.
Technical breakdown
How RFC 8693 encodes on-behalf-of identity
RFC 8693, OAuth 2.0 Token Exchange, lets a system swap one token for another with a narrower audience and explicit delegation semantics. The important detail is not the swap itself, but the preserved relationship between the original principal and the actor performing the request. In the token model described in the article, the sub claim identifies the human intent being represented, while the act claim identifies the agent or service carrying out the action. That makes delegation machine-readable instead of inferred from logs after the fact.
Practical implication: treat token exchange as the place where delegated authority is expressed, not as an optional integration detail.
Why chained agent calls break legacy audit models
Traditional identity systems assume one login event, one credential, one session, and one audit row. Agentic workflows break that model because a single request can fan out into many downstream calls, each with its own scope and decision point. When agents call other agents or gateways, the delegation chain becomes a tree, not a row. If any hop loses the on-behalf-of context, the resulting record no longer answers the basic accountability question of who acted for whom.
Practical implication: design audit and authorisation controls around hop-by-hop delegation, not around a single end-user session.
Why non-OAuth agents still need the same semantics
Many agents and automation layers do not speak OAuth natively, including SDK-based copilots, browser-bound sessions, and bespoke workflow tools. The article's key point is that the protocol format can vary, but the semantics cannot: actor, subject, scope, and audience still have to be preserved. That is why gateways matter. They bridge non-OAuth workloads into the same identity model so enterprises do not end up with one set of rules for standards-based agents and another for everything else.
Practical implication: standardise delegation semantics at the gateway layer, even when the upstream tool cannot natively speak RFC 8693.
Threat narrative
Attacker objective: The objective is to turn delegated access into opaque, over-broad machine execution that is difficult to constrain, attribute, or review.
- Entry occurs when an AI agent or downstream service is given a long-lived credential, token, or SDK-based identity with broader scope than the task requires.
- Escalation follows when the agent reuses inherited authority across multiple hops instead of exchanging it for a narrower token at each boundary.
- Impact occurs when the delegation chain can no longer prove who authorised each action, leaving security and compliance teams without a reliable audit trail.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
- Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
RFC 8693 is no longer a niche backend protocol; it is the default delegation primitive for AI agents. The article shows convergence across platform, infrastructure, and enterprise guidance because the same identity problem keeps reappearing at different layers. That convergence matters because it narrows the design space for practitioners and makes token exchange the reference point for delegated access governance.
One user, one session, one audit row is an invalid identity assumption for machine-speed execution. Those assumptions were designed for human-paced interactions and short-lived application calls. They fail when an agent fans out into hundreds of actions, chains through other agents, and needs every hop to remain attributable. The implication is not merely more logging, but a different delegation model.
On-behalf-of identity is the control boundary where least privilege becomes enforceable for agents. The article's sub, act, and may_act framing shows that actor and subject separation has to be expressed in the token itself, not reconstructed later. That makes scoped token exchange a governance requirement, not an implementation preference.
Delegation semantics now matter as much as authentication semantics for enterprise identity programmes. AI agents expose how much IAM still treats authorisation as a single moment rather than a chain of decisions. Security leaders should read this as a sign that identity architecture, auditability, and policy enforcement are converging into one problem space.
Agent gateways will become the practical enforcement layer for heterogeneous estates. Not every workload will speak OAuth natively, but every workload still needs the same trust semantics. The programmes that win will be the ones that govern the semantics once and bridge protocol differences without losing actor provenance.
From our research library:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
- 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
- Read next: AI Agent Authorisation Guide
What this signals
Delegation semantics now have to be designed at issuance time, not reconstructed from logs later. Access reviews assume privilege persists long enough to be certified, but AI agents often acquire and release scope inside a single workflow. Security teams should therefore shift control emphasis toward token issuance, audience binding, and hop-by-hop provenance.
On-behalf-of identity is becoming the trust boundary for agentic architecture. The important programme question is no longer whether an agent can call a tool, but whether the call carries a verifiable chain of authority. That pushes IAM, PAM, and gateway teams toward a shared operating model for scoped delegation across human, service, and agent contexts.
For practitioners
- Inventory delegated access paths Map where AI agents, copilots, workflow tools, and services currently inherit user authority instead of exchanging it for scoped tokens.
- Require actor-preserving token exchange Make RFC 8693-style token exchange the default pattern for hops that cross trust boundaries, with the original subject and acting agent both preserved in the token.
- Separate user intent from execution identity Ensure policy can distinguish the human authorising an action from the agent executing it, especially where the agent calls other services on the user's behalf.
- Audit long-lived credential exposure Identify agent credentials that remain valid across multiple actions, then narrow their scope at the call boundary so one token does not outlive one task.
- Evaluate gateway support for non-OAuth workloads Check whether your agent gateway can bridge SDK tokens, session cookies, and API keys into the same on-behalf-of semantics used for OAuth-native flows.
Key takeaways
- AI agents expose a delegated access problem that legacy one-user, one-session identity models cannot describe cleanly.
- RFC 8693 token exchange gives enterprises a standard way to preserve actor, subject, scope, and audit context across chained requests.
- The practical control shift is from inherited broad access to explicit, hop-by-hop delegation with gateway enforcement and auditability.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centres on delegated authority and actor identity in agentic workflows. |
| Recommendation — Apply ASI03 by preserving actor, subject, and scope separately for every agent hop. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The article warns against inherited user permissions and broad agent credentials. |
| Recommendation — Replace inherited broad access with task-scoped NHI credentials and narrow each token at the call boundary. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The piece stresses short-lived, scoped credentials and controlled token exchange. |
| Recommendation — Use IA-5 to manage credential issuance, narrowing, renewal, and revocation for agent workflows. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about authorisation boundaries across chained requests. |
| Recommendation — Apply PR.AA-05 to validate and limit entitlements at every delegation hop. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Agent-to-service calls depend on correct authentication and token handling across boundaries. |
| Recommendation — Use API2 to prevent token misuse and ensure each downstream service validates the intended actor and audience. | ||
Key terms
- On-behalf-of identity: On-behalf-of identity is the pattern where one actor performs an action for another actor while both identities remain visible to downstream systems. In agent governance, it lets organisations preserve the human principal, the executing agent, and the scope of authority in the same control and audit model.
- Token Exchange: Token exchange is an OAuth pattern that swaps one credential or token for another with narrower scope or different trust context. In NHI governance, it is useful when a workload must cross boundaries without carrying broad, reusable privileges into downstream systems.
- Actor claim: A token field that identifies the software entity carrying out the action on behalf of the original principal. It prevents audit logs from collapsing a human-initiated request into an anonymous machine action and is central to delegated identity governance for agents.
- Delegation Chain: A delegation chain is the sequence of identities, credentials, and tool calls an agent uses to complete a task across systems. It matters because each step may appear acceptable on its own while the combined path produces an outcome no reviewer would have approved directly.
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.
Published by the NHIMG editorial team on August 14, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org