RFC 8693 token exchange is becoming the agent identity baseline

At a glance

What this is: This analysis says RFC 8693 token exchange is becoming the baseline for AI agent identity because it turns broad, durable access into scoped, auditable, on-behalf-of authorization.

Why it matters: IAM and security teams need this shift because agent estates cannot be governed with session-long tokens that obscure who acted, on whose behalf, and with what privilege.

Context

AI agent identity is the problem of proving who the agent is acting for, what it may do, and how much authority applies to a specific call. The article argues that durable session tokens break those questions because they reuse privilege across many actions.

In Oleria Security's framing, token exchange is not just a protocol choice. It is the control point that makes agent identity auditable, constrains privilege to the moment of use, and gives downstream systems a record that can be governed, investigated, and revoked.

Key questions

Q: What breaks when an AI agent stores its own access token?

A: What breaks is the trust boundary. The agent becomes both the authorised actor and the credential vault, so any compromise of the process can expose the token and the permissions attached to it. That collapses the separation between use and custody, which is exactly what identity governance is supposed to preserve.

Q: Why do AI agent identity controls need RFC 8693 token exchange?

A: Because agents need delegated authority that is narrow, auditable, and tied to a specific resource. RFC 8693 lets the system exchange a session credential for a task-scoped token with explicit subject and actor semantics, which is the difference between implied access and governable delegation.

Q: How can security teams tell if agent privilege is actually constrained?

A: Look for per-call token exchange, audience binding, and an audit record that includes both the human subject and the acting agent. If the same bearer token survives across multiple calls or services, privilege is still standing rather than task-scoped, and the control is not doing its job.

Q: What should IAM teams evaluate when an agent gateway claims token exchange support?

A: Check whether the gateway enforces subject_token and actor_token validation, supports act and may_act claims, narrows audience on issuance, and exposes the exchange event to audit tooling. Without those elements, the platform may exchange tokens in name only while leaving the governance problem unchanged.

Technical breakdown

Why durable agent tokens break accountability

A durable token treats an AI agent session like a stable identity event, but agent workloads often issue many different actions within one session. If the same credential is reused across calls, downstream APIs cannot tell whether the agent was acting within the intended scope for that specific request. That collapses attribution, because the audit record only shows that the agent authenticated, not what authority was valid at the moment of use. RFC 8693 changes the unit of authorization from session to call by exchanging a session credential for a fresh token at the point of use.

Practical implication: Treat session-long agent tokens as an accountability gap and move authorization to the call boundary.

How RFC 8693 expresses on-behalf-of semantics

RFC 8693 token exchange makes delegation explicit through subject_token and actor_token inputs, then encodes the result in claims such as act and may_act. The downstream token can show both the human subject and the acting agent, which turns delegation from an inference into a protocol property. Audience binding also matters because the token is narrowed to a specific resource, reducing the chance that a token minted for one purpose can be replayed against another. For agent identity, that combination is what makes least privilege operational rather than aspirational.

Practical implication: Require explicit actor and subject semantics in any agent identity design, not implied delegation.

Where the standard ends and the governance layer begins

RFC 8693 defines exchange, not enterprise policy. It does not decide which agents may act, when revocation should propagate, or how exchanges are logged for investigators and auditors. That means the protocol is necessary but incomplete: the organisation still has to govern approval, revocation, and evidence around each exchange. For IAM teams, this is the dividing line between interoperability and control. The protocol can carry the semantics, but the governance layer determines whether those semantics are enforceable across the agent estate.

Practical implication: Place policy, revocation, and audit around the exchange flow instead of treating the protocol as the full control.

NHI Mgmt Group analysis

RFC 8693 is becoming the control plane for agent identity because session reuse is the wrong abstraction. AI agents do not map cleanly to durable credentials that outlive individual actions. When the same token is reused across calls, accountability becomes retrospective reconstruction instead of live authorisation. The practitioner conclusion is that agent identity must be judged at exchange time, not session start.

On-behalf-of semantics are the missing governance primitive for AI agents. The act and may_act model gives organisations a way to express delegation explicitly, which is essential when an agent is not the end beneficiary of access. That matters across human IAM, NHI, and agentic AI because delegation chains are only governable when the acting party and the originating intent are both visible. The practitioner conclusion is that delegation must be encoded, not inferred.

Token exchange shifts privilege from standing access to task-scoped authority. That is a material improvement over broad session tokens because it reduces the blast radius of a compromised or misused agent credential. It also aligns the identity model with the runtime reality of agents, which can act many times within a single workflow. The practitioner conclusion is that least privilege for agents starts with exchange, not with longer-lived tokens.

Open standards will shape the agent identity market more than proprietary gateways will. The article shows that Microsoft, Okta, Keycloak, Ping, AWS, Uber, and Red Hat are all converging on the same protocol idea, which makes interoperability and auditability the category signal to watch. That does not remove the need for policy or logging, but it does mean vendor differentiation is moving up the stack. The practitioner conclusion is to evaluate whether a platform strengthens standards-based governance or hides it.

Agent identity governance now depends on whether the audit trail is native to the token exchange flow. If every call cannot be tied back to who approved it, on whose behalf it ran, and what audience it was scoped for, the estate remains operationally ambiguous. That ambiguity is not just a logging problem; it is a governance failure. The practitioner conclusion is to require evidence at the point where privilege is issued.

What this signals

Agent identity becomes governable when privilege is minted at the moment of use. Session-start authorisation assumes the agent's intent stays stable, but real workflows drift across tools and resources. That is why RFC 8693-style exchange is more than a protocol preference: it is a governance boundary that moves control from provisioning to runtime.

On-behalf-of semantics should become the default expectation for AI agents, not an optional enhancement. If a platform cannot show who the agent is acting for, its audit trail will remain ambiguous even when the actions are technically authenticated. IAM teams should treat explicit delegation as a baseline requirement for agentic systems, not a feature checkbox.

For practitioners

• Adopt call-bound token exchange Use RFC 8693 to exchange a session credential for a fresh, audience-bound token on each agent call instead of reusing a durable bearer token.
• Enforce explicit delegation claims Require act and may_act semantics so every agent token records the human subject and the permitted acting agent.
• Bind privileges to the downstream audience Scope each exchanged token to the specific API or resource it is meant for so one agent token cannot be replayed broadly across services.
• Move revocation to the exchange point Revoke the session credential or policy at the gateway so the next exchange fails instead of chasing long-lived access across downstream systems.
• Require exchange-level audit evidence Log who requested the exchange, on whose behalf it occurred, what privilege was issued, and which audience received it, then feed that record into SIEM and investigation workflows.

Key takeaways

• AI agent identity fails when one durable token is reused across many calls, because the audit trail no longer shows what authority applied at the moment of action.
• RFC 8693 matters because it turns delegation into a protocol property with subject, actor, audience, and act semantics that downstream systems can verify.
• IAM teams should judge agent platforms by whether they exchange privilege at runtime and expose a usable audit record, not by whether they merely support tokens.

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.
• Act claim: A token claim used to identify the actor performing an action on behalf of a principal. In delegated AI and service flows, it separates the human principal from the runtime actor so downstream systems can enforce policy and generate accurate audit records.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.