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.
Why RFC 8693 matters for agent identity controls
RFC 8693 gives an agent a way to swap an existing session credential for a new token that is narrower in scope, explicit about who the original subject was, and explicit about which actor is now acting. That is important because agent identity control is not just about proving access once, it is about making delegated access measurable, revocable, and limited to the task at hand.
Without token exchange, teams often end up reusing the same credential for login, delegation, and downstream API calls. That collapses identity boundaries and makes it difficult to tell whether an action came from the user, the agent, or another component in the chain.
RFC 8693 is therefore a delegation mechanism as much as an authentication mechanism. It lets you keep the original session intact while issuing a separate token for the work being performed, which makes the resulting access path easier to govern than a single bearer credential used everywhere.
What token exchange adds to agentic delegation
For AI agents, the practical value is that the token can carry task scope, audience, and actor semantics that fit the specific action rather than the whole user session. That is what enables a policy engine, API gateway, or resource server to distinguish general user presence from a permitted on-behalf-of operation.
This is also where delegation becomes auditable. If the exchanged token encodes the actor chain, logs and authorization decisions can show which principal initiated the task and which agent actually executed it. The result is better attribution, cleaner incident review, and a more defensible approval boundary.
RFC 8693 also fits naturally with short-lived access patterns. An agent can receive a token for one task, one audience, and one time window, then lose that authority when the exchange expires. That aligns with least privilege far better than granting the agent persistent access to the same credential it used to sign in.
Where the control boundary breaks down
Agent identity controls become weak when the system treats token exchange as a convenience feature rather than the place where delegation is constrained. In AI Agent Authorisation Guide, task-scoped access and per-action policy are the point, and RFC 8693 is the protocol shape that makes those decisions portable across services.
That boundary matters even more when agents touch external services or multiple resources. Agentic AI Identity Guide shows the same pattern across registration, delegation, authentication, and retirement: the identity must change with the role the agent is playing, not stay frozen as a reusable login token.
The risk is highest when organisations allow humans, agents, and backend services to share the same long-lived secret path. NHI Authentication Guide explains why machine and agent authentication needs more than a static credential, because the stronger the bearer token, the more attractive it becomes as a replayable control bypass.
Risk and Threat Considerations
Token exchange reduces blast radius, but it also becomes a high-value trust boundary. If an attacker steals the upstream session, or if the exchange policy is too permissive, they may mint downstream tokens that look legitimate enough to reach the exact resource the agent was supposed to touch.
Failure mechanism: A shared bearer token or loosely constrained exchange path lets an attacker or misconfigured agent turn general access into specific resource access without a meaningful delegation check. That breaks attribution, weakens revocation, and can allow lateral use of the same authority across multiple APIs.
Impact: Compromise can present as ordinary delegated activity, which makes detection harder and increases the chance of unauthorized writes, data exposure, or destructive agent actions being logged as if they were approved work.
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 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent delegation and actor semantics directly address privilege misuse in agent flows. |
| Recommendation — Enforce per-action delegation controls so agent identity cannot exceed approved authority. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Service and Device Authentication) | Token exchange supports service-to-service or agent-to-service authentication with bounded authority. |
| AC-6 — Least Privilege | RFC 8693 creates task-scoped access, which is a direct least-privilege control pattern. | |
| AU-2 — Event Logging | Subject and actor semantics improve auditability of delegated agent actions. | |
| Recommendation — Use IA-9 to authenticate agents and services with scoped, verifiable credentials. Limit exchanged tokens to the minimum permissions needed for the specific task. Log subject, actor, audience, and exchange events for delegated agent actions. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Token exchange is part of securing how agents authenticate without reusing broad credentials. |
| Recommendation — Replace reusable bearer credentials with short-lived exchanged tokens. | ||
Practitioner Guidance
What to verify: Check that the exchanged token has a narrower audience, shorter lifetime, and explicit subject and actor claims that your resource server actually enforces. If the downstream service only validates signature and expiry, the exchange is not giving you real delegation control.
Decision rule: If the agent can perform a material action, require token exchange for that action and keep the original user session out of direct API use. If the agent only relays a human click to one backend and never assumes independent authority, a simpler pattern may be acceptable, but it should still be auditable.
Practitioner takeaway: RFC 8693 is valuable because it turns agent access from a reusable credential problem into a bounded delegation problem, and that is the difference between access that merely works and access that can be governed.