RFC 8693 token exchange is becoming the agent identity baseline

At a glance

What this is: This is an analysis of how RFC 8693 can underpin AI agent identity by replacing durable agent tokens with delegated, scoped token exchange.

Why it matters: It matters because IAM, PAM, and identity governance teams need runtime controls that preserve accountability when agents act on behalf of humans without inheriting broad standing privilege.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.

👉 Read Oleria Security's analysis of RFC 8693 for AI agent identity

Context

RFC 8693, the OAuth 2.0 token exchange standard, gives identity teams a way to issue scoped credentials on behalf of a subject rather than allowing an intermediary to reuse a durable token. In AI agent environments, that distinction matters because the control problem is no longer only authentication, but delegated authority, session scoping, and downstream auditability.

The governance gap appears when a platform records only that an agent made the call, not who authorized it, what scope was intended, or whether the action stayed within policy. That is an IAM and NHI problem at the same time, because the agent is a non-human identity acting inside a human-authorized chain of delegation.

The article argues that the protocol is already mature and the harder work sits above it: policy, revocation, audience binding, and evidence generation. That is a typical enterprise problem, not a niche edge case, which is why standards-based agent identity is becoming a practical governance question rather than a design preference.

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 break traditional token and session models?

A: Traditional models assume the same credential can safely persist across many calls, but agents often chain actions, tools, and audiences within one session. That creates ambiguous authority and makes post-incident reconstruction unreliable. Delegated token exchange fixes that by making privilege explicit at the moment of use instead of at session start.

Q: When should organisations replace durable agent credentials with token exchange?

A: Replace durable agent credentials when the agent can reach multiple tools, touch regulated data, or trigger actions that require attribution. Those are the conditions where one reusable token creates too much standing privilege. If the agent can do harm with the same credential across tasks, exchange-based scoping is warranted.

Q: What frameworks help teams control AI agent access and delegated identity?

A: OWASP NHI and NIST Zero Trust Architecture are the most relevant starting points because they both assume access must be continuously governed and tightly scoped. For agentic workflows, teams should extend those controls to per-call authorization, short-lived delegation, and clear audit trails across every upstream system the agent can reach.

Technical breakdown

RFC 8693 token exchange for agent identity

RFC 8693 lets an authorizer exchange one credential for another with narrower scope, a different audience, and explicit on-behalf-of semantics. For AI agents, that means the agent can hold a session credential without inheriting a long-lived permission slip. The downstream token can carry subject and actor context, which preserves attribution across service hops. In practice, this is the difference between a call that is merely authenticated and a call that is both authenticated and governed by delegation state.

Practical implication: design agent runtimes so every sensitive call receives a freshly exchanged token instead of reusing a durable bearer credential.

On-behalf-of authorization and the act claim

The act claim records the agent as the actor while preserving the human as the accountable subject. Combined with subject_token and actor_token checks, it lets the authorizer verify both sides of the delegation relationship before issuing access. That matters because downstream systems cannot reconstruct intent from logs alone if the token never carried delegation context. Token exchange is not just a permission mechanism here, it is the audit structure that makes the permission defensible.

Practical implication: require delegation-aware claims in every token issued for agent activity, or the audit trail will remain ambiguous.

Audience binding and token scope as runtime controls

Audience binding limits where an exchanged token can be used, and per-request scope narrowing keeps privilege aligned to the specific action. This prevents a token issued for one tool, one resource, or one task from being replayed elsewhere with broader effect. For agent ecosystems that mix OAuth, MCP, and bespoke APIs, this control becomes the difference between governable delegation and ambient access. The architecture only works if the authorization step happens at runtime, before each outbound action.

Practical implication: enforce audience-specific, task-scoped exchange policies at the gateway rather than trusting pre-granted agent scope.

NHI Mgmt Group analysis

RFC 8693 is becoming the control plane for agent delegation, not just an OAuth extension. The article is right to treat token exchange as the architectural answer to agent accountability because durable bearer tokens collapse under delegated runtime action. For security leaders, the practical consequence is that agent identity should be governed as an exchange problem, not a static credential problem.

Standing privilege is the wrong mental model for AI agents. Agents do not need broad reusable tokens if each call can be exchanged for a narrowly scoped credential tied to a specific audience and subject. That shifts the design centre from possession to authorization time, which is where identity governance can still apply meaningful control.

On-behalf-of semantics are the only defensible way to preserve accountability across agent actions. If the audit record only says the agent acted, the organisation loses the human delegation chain that regulators, investigators, and IAM teams need. This makes token-level provenance a governance requirement, not an implementation detail.

Agent identity is now an NHI governance issue with human impact. The same delegation logic that secures service accounts and API keys must now extend to AI agents that can invoke tools and APIs. That means lifecycle, revocation, and evidentiary controls need to operate across the full human to non-human delegation chain.

Named concept: on-behalf-of runtime authority. This article shows that the useful unit of control is not the agent itself, but the specific runtime authority granted for one action at one moment. Practitioners should treat that as the governance boundary for policy, logging, and revocation.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 92% of organisations expose NHIs to third parties, according to Ultimate Guide to NHIs, which shows how quickly delegated access expands beyond direct ownership.
• For a broader control baseline, see Top 10 NHI Issues for the access, visibility, and lifecycle problems that token exchange alone does not solve.

What this signals

On-behalf-of runtime authority: AI agent programmes should now be designed around runtime delegation boundaries rather than persistent identity grants. That means the operational question is no longer whether an agent can authenticate, but whether every call can be tied to a narrowly scoped, reviewable exchange record.

The governance gap will widen wherever teams treat agents as just another automation layer. Agentic workloads can move faster than access review cycles, so IAM leaders need controls that narrow privilege at the moment of use and evidence that survives incident review, audit, and offboarding.

With NHIs outnumbering human identities by 25x to 50x in modern enterprises, the agent problem scales into an existing machine-identity estate rather than appearing as a separate category. That means agent governance should be absorbed into the same lifecycle, revocation, and privilege controls already used for other non-human identities.

For practitioners

• Map agent flows to delegation boundaries Inventory where agents currently reuse session tokens, where OAuth exchange is available, and where a downstream API still accepts broad bearer credentials. Replace durable agent credentials with delegated exchanges at the point of outbound action.
• Require actor and subject context in every token Make subject_token, actor_token, and auditable act-style claims mandatory for sensitive agent calls so investigators can reconstruct who authorized what. Store the resulting exchange record in the SIEM and access review workflow.
• Bind each token to one audience and one task Reject agent tokens that can be replayed across tools or business functions. Use audience binding and narrow scopes so compromise affects a single call path rather than an entire agent session.
• Test revocation at the next call boundary Validate that revoking the human subject, the agent identity, or the policy entry removes access before the next exchange completes. If revocation depends on token expiry alone, the control is too weak for production use.

Key takeaways

• RFC 8693 turns AI agent access from a static credential problem into a runtime delegation problem.
• The governance risk is not that agents can authenticate, but that organisations may not be able to prove who they acted for or within what scope.
• IAM teams should treat delegated token exchange, audience binding, and revocation evidence as core controls for agent identity.

Key terms

• 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.
• On-Behalf-Of Authorization: On-behalf-of authorization is a decision pattern that evaluates both the calling service and the original user whose action triggered the request. It prevents delegated workflows from exceeding user intent by enforcing policy on the combined identity context instead of trusting the service alone.
• Audience Binding: A control that limits a token to a specific downstream resource or service. It prevents credential replay across tools and keeps delegated access aligned to the exact action the system was allowed to perform.

What's in the full article

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

• How the authorizer evaluates subject and actor tokens before issuing scoped access for agent calls.
• Implementation details for policy, revocation, and audit logging around RFC 8693 exchanges.
• How the gateway translates token exchange semantics across MCP servers, OAuth services, and bespoke APIs.
• The specific claims and token fields the vendor uses to preserve on-behalf-of attribution.

👉 The full Oleria Security post covers the authorizer design, token exchange flow, and audit model behind agent delegation.

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 identity security across human and non-human estates, it is worth exploring.