On-behalf-of identity at machine speed needs token exchange

At a glance

What this is: This is an analysis of how AI agents turn delegated access into an enterprise identity problem and why RFC 8693 is becoming the common protocol answer.

Why it matters: It matters because IAM, PAM, and NHI programmes now have to govern agent-initiated actions, preserve traceable delegation, and avoid inherited user permissions that destroy auditability.

👉 Read Oleria Security's analysis of on-behalf-of identity at machine speed

Context

AI agent identity changes the control point from human login to delegated execution. The core question is no longer only who authenticated, but who authorised an action, on whose behalf it ran, and how that decision is preserved across multiple systems and hops.

RFC 8693, OAuth 2.0 Token Exchange, is the standards-based way to encode that delegation into the token itself. In practice, that matters because enterprise identity stacks must distinguish between human-initiated and agent-initiated actions without collapsing both into the same credential and audit model.

The article frames a common pattern now showing up across agentic platforms and enterprise infrastructure: scoped, time-bound delegation with explicit actor and subject claims. That is an atypical situation only in the sense that many identity programmes still treat delegation as an application detail rather than a first-class governance problem.

Key questions

Q: How should security teams govern AI agents that can access enterprise systems?

A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring. The control set should include inventory, task-bound credentials, audit trails, and revocation paths. If an agent can call tools or touch production systems, it belongs in the same governance model as service accounts and other machine identities.

Q: Why do AI agents complicate existing IAM and PAM controls?

A: AI agents complicate IAM and PAM because they often inherit delegated credentials, operate across multiple systems, and keep acting after the initial approval moment has passed. Human session assumptions, periodic reviews, and static privilege models do not reflect that behaviour. The result is a governance gap between what was granted and what the agent can actually do.

Q: What breaks when AI agent permissions are inherited from the host application?

A: The boundary between application access and agent access disappears. That makes it difficult to prove least privilege, trace tool usage, or revoke access cleanly when the agent is retired or repurposed, especially if secrets and memory are reused across workflows.

Q: Who is accountable when an AI agent runs a query on behalf of a user?

A: Accountability sits with the identity chain, not with the tool call alone. The human who delegated the action, the issuer that minted the token, and the platform that activated the role all need a traceable record. If any of those links are missing, the organisation cannot prove who authorised the access.

Technical breakdown

RFC 8693 token exchange and the act claim

RFC 8693 defines OAuth 2.0 Token Exchange, where one token is exchanged for another that is scoped to a specific audience and purpose. The act claim identifies the intermediary actor, while sub carries the original principal whose authority is being delegated. That structure matters because it preserves the chain of responsibility instead of flattening every downstream action into the identity of the last system to touch it. For agentic workloads, this turns delegation into a native token property rather than a logging reconstruction after the fact.

Practical implication: IAM teams need token semantics that preserve actor, subject, and audience at each hop, not just an access token that happens to work.

Why multi-hop AI agent delegation breaks inherited permissions

AI agents fan out quickly, often chaining through investigation agents, gateways, APIs, and databases. If each hop reuses inherited user permissions, the result is scope inflation: the agent keeps access that was never meant for the next step. Token exchange narrows authority at each boundary, which is what makes the delegation trail intelligible to auditors and enforceable by downstream services. Without that narrowing, the control plane cannot tell whether a request is still operating within the original intent or has drifted into unrelated access.

Practical implication: treat every agent hop as a new authorisation decision and stop passing broad user credentials downstream.

On-behalf-of identity for non-OAuth agent workloads

Most enterprise agents do not start with a clean OAuth-native interaction. Browser extensions, vendor copilots, SDK tokens, session cookies, and RPA credentials all carry delegated authority in different forms. The architectural challenge is not just token exchange itself, but preserving the same on-behalf-of semantics across heterogeneous identity types. That usually requires a gateway or broker layer that can translate non-OAuth inputs into a consistent delegation model without losing provenance, scope, or audit context.

Practical implication: build a translation layer for non-OAuth agents so every delegated action lands in the same governance model.

Threat narrative

Attacker objective: The objective is to obtain task-level or broader access through an agent path that bypasses meaningful delegation controls and leaves the audit trail ambiguous.

1. Entry occurs when an AI agent is granted delegated access through user credentials or a long-lived token that was never constrained to the actual task. Escalation follows when the agent chains additional calls and reuses that broad authority across downstream systems.
2. Impact occurs when the organisation cannot reconstruct who authorised the action, which actor executed it, and what scope was in force at each hop. The result is broken auditability and excess access propagation across the delegation chain.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• CoPhish OAuth Token Theft via Copilot Studio — CoPhish campaign exploits Microsoft Copilot Studio agents to steal OAuth tokens via AI-assisted phishing.

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 access has become the primary identity boundary for AI agents. The old model assumed a human authenticated once and then the system simply enforced session permissions. AI agents break that assumption because the meaningful decision sits at each hop, not at login. The practical conclusion is that delegated authority now belongs in identity governance, not in application-specific plumbing.

Identity does not stay stable long enough for inherited privileges to remain safe. RFC 8693 exists because token semantics need to narrow authority as work crosses systems. That design was built for constrained delegation, not for agents that can fan out into hundreds of calls in a short window. The implication is that least privilege must be evaluated at execution time, not only at provisioning time.

On-behalf-of auditing is the new accountability test for IAM. If a control cannot tell who authorised an agent action, on whose behalf it ran, and what privilege was in force at the point of use, then it is not suitable for agent governance. This is where human IAM, NHI governance, and PAM converge around the same control question: who may act, under what delegation chain, and with what evidence.

Scope-bound delegation is the named concept practitioners should track. The real governance issue is not whether an agent can access a system, but whether each call carries a scope that is narrow enough to be defensible and auditable. That is what separates a delegated workflow from a standing credential problem. Teams should treat scope-bound delegation as the baseline design pattern for agent identity.

AI agent identity is forcing standards convergence because proprietary delegation does not scale across enterprise estates. The article points to convergence around RFC 8693 across platforms, infrastructure, and coalition guidance. That matters because identity teams need a common semantic layer before they can build consistent policy, logging, and review processes. The implication is that control consistency will come from standards alignment, not from bespoke agent exceptions.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared with nearly 1 in 4 for securing human identities.
• That confidence gap is why our Ultimate Guide to NHIs remains the practical starting point for governance, lifecycle, and rotation decisions.

What this signals

Delegation chains now need to be treated as security objects, not just application internals. As agentic workflows spread, the programme question becomes whether you can prove who authorised each hop and whether scope was narrowed before the next action. That pushes IAM, PAM, and NHI governance toward a common evidence model instead of separate reporting silos.

The next control gap is likely to show up in audit and certification workflows, where access reviews still expect a stable entitlement to review. Teams should start redesigning those processes around delegated authority, not static account ownership, and use standards-based semantics such as NIST AI Risk Management Framework only where autonomous decision-making is genuinely present.

Scope-bound delegation: the useful operational test is whether every agent call can be explained as a narrowly issued, auditable act on behalf of a specific principal. If that answer is no, the organisation is still running user-centric IAM in an agent-centric environment, and the mismatch will surface first in exception handling and incident response.

For practitioners

• Map every agentic workflow to a delegation chain Document the human principal, intermediate agent, gateway, and downstream service for each task path so you can see where authority changes hands. Use that map to find hops where user credentials are simply passed through without re-issuance or scope reduction.
• Require token exchange at each trust boundary Where OAuth is available, require RFC 8693 conformant exchange with explicit actor and subject claims and audience-bound scopes. Do not allow downstream calls to inherit the original user token when the agent is crossing systems or changing purpose.
• Classify long-lived agent credentials as high-risk delegated access Inventory OAuth tokens, API keys, session cookies, and vendor SDK credentials used by agents, then identify where broad scopes persist beyond the immediate call boundary. Prioritise the credentials that can reach multiple systems or remain valid across many actions.
• Add on-behalf-of evidence to access reviews Update certification and audit workflows so reviewers can see the original principal, the actor that executed the call, the scope issued, and the point at which delegation changed. Without those elements, access review is blind to agent behaviour and cannot prove accountability.

Key takeaways

• AI agents turn delegated access into a first-order identity governance problem because each hop can change who is acting and what authority is in force.
• RFC 8693 matters because it preserves actor, subject, scope, and audit trail in a form downstream systems can enforce and reviewers can inspect.
• Practitioners should stop treating agent credentials as inherited user access and move to scope-bound delegation with explicit on-behalf-of evidence.

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.
• 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.
• Audience-bound token: An access token that can only be used against a specific resource server or API. Audience binding limits replay, reduces token portability, and ensures that a credential minted for one task cannot be reused elsewhere.

What's in the full article

Oleria Security's full article covers the protocol detail this post intentionally leaves for the source:

• The RFC 8693 token exchange mechanics, including the act and may_act claims, in the context of AI agent delegation.
• The MCP and enterprise gateway design patterns that translate non-OAuth agent workloads into on-behalf-of semantics.
• The platform-by-platform examples cited by the vendor, including AWS AgentCore Identity and the Coalition for Secure AI guidance.
• The specific implementation questions the article uses to test whether an agent platform can preserve auditability across hops.

👉 Oleria Security's full post covers RFC 8693 semantics, multi-hop delegation, and the audit trail questions behind agent identity.

Deepen your knowledge

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