OAuth Token Exchange and Identity Chaining
OAuth 2.0 Token Exchange (RFC 8693) and the identity chaining specifications built on it carry a user's identity and authorization context across service boundaries, so that each hop in a call chain can decide access based on who originally made the request rather than on the privileges of whichever service forwarded it. Token exchange provides the base primitive — trade one token for another — and the specifications profiled below define what belongs in the resulting token and how far it should travel. The problem predates AI agents and arises in any architecture where a service calls another service on a user's behalf, but agent workflows make it acute: a single request may traverse an orchestrator, several sub-agents, and multiple external APIs, and every hop is an opportunity to lose the original principal or silently amplify privilege.
Propagation Within a Trust Domain
Transaction Tokens (TraTs) address propagation inside a single trust domain. At the domain boundary, the incoming external access token is exchanged once for a short-lived signed JWT that carries immutable per-request context, and that token — not the original bearer token — is passed between internal services. Because the context is fixed at the boundary and signed, a compromised or buggy downstream service cannot widen the request's scope, and the audit trail for the entire internal call chain shares one correlatable identifier.
The agent extension adds the two claims that agentic workloads need: actor, identifying the agent performing the action, and principal, identifying the human who initiated it. This distinction is what makes dual-attribution audit logging mechanically possible rather than a convention each service implements differently.
Delegation Across Trust Boundaries
Transaction Tokens deliberately stop at the domain edge. Two specifications handle what happens beyond it.
Identity Chaining combines RFC 8693 token exchange with RFC 7523 JWT authorization grants so that an identity assertion issued in one organization's trust domain can be presented to an authorization server in another. It is the general cross-domain pattern and does not assume anything about agents.
ID-JAG (Identity Assertion Authorization Grant) is the narrower, more deployed case: an enterprise identity provider issues a JWT authorization grant that a downstream resource server honours without further user interaction. This is the mechanism that bridges enterprise SSO into agent authorization without distributing long-lived credentials or static API keys, and it is the basis of the enterprise authorization extension in Model Context Protocol.
Reducing Authority at Each Hop
Chaining a token forward preserves context but does not by itself reduce privilege. Attenuating Agent Tokens propose monotonically attenuating JWTs: any holder can derive a strictly more restrictive token offline, without a round trip to the authorization server. An orchestrating agent can therefore hand each sub-agent only the subset of its own authority that the sub-task requires, and the reduction is cryptographically verifiable rather than merely intended. For recursive delegation this is the difference between least privilege as a design goal and least privilege as an enforced property.
Delegation Chain Integrity
The chain itself becomes security-relevant data. The IETF WIMSE architecture carries a security context recording the original principal and every intermediate hop, and draft-liu-ai-agent-authorization-integration (July 2026) proposes an explicit delegation_chain claim for end-to-end auditability.
Recording the chain creates a new attack surface. A March 2026 IETF OAuth Working Group discussion identified delegation chain splicing, in which an attacker manipulates the actor claim chain to make a request appear to originate from a more privileged or differently scoped path than it did. Implementations must therefore verify the chain's integrity — not merely read it — which means each hop's assertion needs to be independently verifiable rather than assembled from claims a previous hop could rewrite. The Delegation Receipt Protocol approaches the adjacent question of user-to-operator trust, producing evidence that a user authorized an operator to act, which complements rather than replaces chain verification.
Choosing Between the Mechanisms
The specifications are complementary and the selection follows the topology of the call, not the technology in it. Transaction Tokens apply within one trust domain and are the right default for internal service-to-service and orchestrator-to-sub-agent calls. Identity Chaining applies when the call crosses organizational boundaries, with ID-JAG as the specific enterprise-IdP-to-resource-server case. Attenuation is orthogonal to both and applies wherever authority should narrow as it is passed on. All of them carry an authorization that already exists; none of them creates a new one, so where an action needs a fresh human decision rather than propagated context, the mechanism is CIBA — a separate authorization request the user approves out-of-band, whose result then enters the chain as its own grant. In all cases the resulting context is only useful if something evaluates it, which is where PBAC policy evaluation and the AuthZEN decision interface come in — the token carries the facts, the policy engine decides what they permit.
Summary
Token chaining is the layer that makes multi-hop authorization auditable, and it is meaningfully ahead of the agent-specific standards that depend on it: ID-JAG and Identity Chaining are Working Group adopted and appearing in products, while the agent-oriented drafts remain individual submissions. Organizations building either microservice architectures or AI agent deployments can adopt Transaction Tokens and ID-JAG now and treat the agent-specific claim extensions as additive. The design decision worth making early is architectural rather than protocol-level: fix the request context at the trust domain boundary, and require that authority narrow rather than persist as it is delegated.