The token your agent is holding is the token an attacker wants
An agentic workflow rarely terminates with a single API call. A user asks the agent a question; the agent calls an orchestration service; the orchestration service invokes three tools, each of which calls one or more backend APIs; some of those backends fan out to additional internal services. By the time the user’s original request has been satisfied, the initial OAuth access token has propagated through five, ten, sometimes dozens of workloads.
Every workload that touches that token is a place it can leak.
The traditional bearer-token model — possession of the token is proof of authorization — handles this badly. If any workload in the chain is compromised, an attacker who exfiltrates the token can replay it from anywhere, against any audience the token is valid for, for the entire lifetime of the token. The token doesn’t know it’s being misused; the API receiving the token has no way to distinguish a legitimate continuation of the original call chain from an attacker replaying the stolen token from a completely different network location.
There are three IETF-track mechanisms that change this picture: delegation versus impersonation patterns in OAuth Token Exchange (RFC 8693), Transaction Tokens (draft-ietf-oauth-transaction-tokens-07), and Identity Chaining for cross-domain authorization.
This article goes deep on all three.
Delegation versus impersonation: the choice you didn’t know you were making
When an agent acts on behalf of a user, there are two fundamentally different ways to express that in the token model. The choice has substantial security and audit consequences, and most agentic deployments today make it implicitly, badly.
Impersonation means the downstream API sees a token that looks indistinguishable from one the user would have presented directly. The token’s sub is the user. The agent’s identity does not appear. From the API’s perspective, “the user did this.” The agent is invisible.
Delegation means the downstream API sees a token that names both the user and the agent acting on their behalf. The token preserves the chain: user U authorized agent A to act for them in this specific context. The agent is part of the audit trail, and the API can apply policy specifically to “the user themselves” versus “an agent acting for the user.”
OAuth Token Exchange (RFC 8693) supports both modes via the act (actor) claim. An exchange that produces a delegation token includes both sub (the user) and act (the agent), nested if there are multiple actors in the chain. An exchange that produces an impersonation token includes only sub (the user) and discards information about the agent.
For agentic systems, delegation is almost always the right answer. Reasons:
- Policy precision. Some operations should be allowed for the user but not when an agent is the actor (e.g., “transfer funds over $10,000 requires direct user action, not an agent”). Impersonation tokens cannot express this; the downstream API cannot tell the difference.
- Audit completeness. An audit log that records “user U deleted record X” when in fact “agent A deleted record X while acting for user U” is misleading. Investigations into compromised agents become much harder when the agent has erased itself from the trail.
- Compromise containment. If an agent is compromised and starts making malicious calls, a delegation token’s act claim lets the downstream system block “anything where act=compromised-agent” without blocking the user. An impersonation token forces a choice between disabling the user entirely or leaving the compromise in place.
The IAM industry has been slow to move from impersonation to delegation because impersonation is operationally simpler — fewer claims to manage, no nested actor chains, every API just sees a “normal” user token. The cost of that simplification is exactly the lack of policy precision and audit completeness that agentic systems make untenable.
For DoD and other high-assurance environments, delegation is effectively mandatory. NIST 800-53 AC-2(11) (account management — usage conditions) and AU-2 (audit events) presume that audit trails accurately attribute actions. Impersonation breaks that attribution at the moment an agent is involved.
Transaction Tokens: binding identity and context to a specific transaction
Even with delegation, a stolen access token is dangerous because it can be replayed for any operation within the token’s scope, for the remaining lifetime of the token, from anywhere. The token says who the user is and who the agent is, but it doesn’t say which specific transaction the token was issued for.
Transaction Tokens — draft-ietf-oauth-transaction-tokens-07, co-authored by Pieter Kasselman with Atul Tulshibagwale and George Fletcher — fix this by binding identity, authorization context, and transaction-specific context together into a token whose validity is scoped to one specific invocation flowing through a trust domain.
The model: when an external request enters a trust domain (say, an authenticated API call from a user-facing agent into the backend), a Transaction Token Service mints a Transaction Token (Txn-Token). This token carries:
- The user identity (as it would in a delegation token)
- The agent/workload identity that originated the request
- Authorization context (scopes, decisions, attributes) that were established at the trust domain boundary
- Transaction-specific context (a request ID, the originating endpoint, any externally relevant parameters)
- A short lifetime (typically seconds to minutes — long enough for the transaction to complete, short enough to be useless if stolen and replayed)
The Txn-Token then propagates through every workload involved in processing the transaction. Each workload validates it, may use it to authenticate to the next workload, and — critically — can optionally assert its own presence in the call chain by attaching its workload identity to the token’s chain of custody.
The draft’s abstract puts the design intent concisely: Transaction Tokens “are designed to maintain and propagate user identity and authorization context across workloads within a trusted domain during the processing of external requests, such as API calls. They ensure that this context is preserved throughout the call chain, even when new transactions are initiated internally, thereby enhancing security and consistency in complex, multi-service architectures.”
How Txn-Tokens are issued and used
The flow has four phases.
Phase 1: Trust domain ingress. A request arrives at the trust domain boundary — typically an API gateway or an ingress proxy. The gateway authenticates the request (via OAuth access token, OIDC ID token, mTLS, etc.), establishes the authorization decision, and presents the resulting context to the Transaction Token Service.
Phase 2: Txn-Token issuance. The Transaction Token Service validates the gateway’s request (typically via mTLS or SPIFFE client authentication — RFC 7523 style with the workload presenting its SVID), applies its own policy to confirm the requested Txn-Token is appropriate, and issues a token bound to the specific transaction. The token is signed by the trust domain’s Txn-Token issuer key.
Phase 3: Propagation through the call chain. The first workload to receive the Txn-Token uses it to authenticate to downstream workloads. As the call fans out, each workload validates the Txn-Token’s signature against the issuer’s public keys, validates the transaction context (e.g., that the transaction ID matches an active transaction it’s expected to participate in), and uses the user/agent identity claims for authorization decisions.
Phase 4: Call chain assertion (optional). A workload that wants to immutably assert its presence in the call chain to downstream workloads can attach a signed assertion to the Txn-Token, building up a verifiable record of which workloads participated. This is useful when the downstream workload’s policy depends on the chain — e.g., “this sensitive operation is allowed only if the call came through the input validation service.”
The draft references SPIFFE explicitly: workloads authenticating to the Transaction Token Server “SHOULD authenticate to a Transaction Token Server using asymmetric (public-key based) methods or signed client authentication JWTs in accordance with {{RFC7523}}, which MAY be provisioned using mechanisms such as {{SPIFFE}} or other provisioning protocols.” The natural deployment pattern composes SPIFFE for workload identity, the OAuth SPIFFE Client Authentication profile for the workload-to-Txn-Token-Service authentication step, and Txn-Tokens for the in-domain context propagation.
Why this stops token theft
A traditional OAuth access token, if stolen, retains its value until expiry. The thief can use it from any network location, against any audience the token names, for any operation within its scope.
A Transaction Token, if stolen, is essentially worthless to a thief in another transaction. Reasons:
- Transaction-bound. The Txn-Token names a specific transaction. A downstream workload validating the token will reject it if the transaction context doesn’t match what it expects (e.g., the transaction has already completed, the request parameters don’t match, the workload isn’t expected to participate).
- Short-lived by design. Txn-Token lifetimes are tied to expected transaction durations — seconds for typical API operations, minutes for longer-running workflows. By the time an attacker has exfiltrated and replayed a stolen token, the transaction window has typically closed.
- Chain-aware. A workload receiving a Txn-Token can validate that the previous workload in the chain (asserted via call-chain attestation) is the one it expects. An attacker injecting a stolen token from outside the chain fails this check.
- Audience-scoped per workload. Txn-Tokens can be re-minted or scoped at each hop, so a token observed at one workload is not necessarily valid at the next. This limits horizontal propagation of stolen tokens.
The combination is what makes the model qualitatively different from pure OAuth access tokens. A stolen access token is a key to the kingdom for its lifetime. A stolen Txn-Token is a key to a specific door that closes within seconds.
Identity Chaining: when the call leaves the trust domain
Transaction Tokens work inside a single trust domain. Many agentic workflows cross trust boundaries — an agent provisioned by Anthropic calls an API hosted by your organization, which calls a SaaS vendor, which calls a partner’s backend. Each boundary is a place where the authorization context needs to be re-established.
OAuth Identity Chaining (the term used in the OAuth working group for cross-domain delegation patterns; technically realized via OAuth Token Exchange, the OAuth Identity Chaining Across Trust Domains draft, and adjacent specs) addresses this. The pattern: at each trust domain boundary, the outgoing token is exchanged for a new token issued by the receiving trust domain’s authorization server. The exchange preserves the user identity and the chain of actors (each domain’s authorization server adds its own audit information to the token) while issuing fresh credentials scoped to the receiving domain’s requirements.
For agentic systems, the practical workflow:
- User authenticates to their identity provider, gets an ID token / access token for the agent platform.
- Agent platform uses Token Exchange (RFC 8693) to exchange that token for an access token scoped to your enterprise’s authorization server.
- Your authorization server’s token-exchange flow issues a Txn-Token (or a domain-internal access token) preserving user identity and adding your domain’s actor information.
- The call propagates through your trust domain on the Txn-Token.
- When the call leaves your trust domain for a partner’s domain, another token exchange re-establishes the chain.
- The partner’s domain mints its own internal tokens, preserving the cross-domain audit trail.
At each boundary, the receiving domain has the option to apply its own policy: “we trust this incoming actor chain for these operations but not those,” “this user has been federated to us via this specific path; here are the rights they receive in our domain,” “this agent is recognized in this domain only because the chain includes a recognized intermediary.”
This is the cross-domain piece of the agentic identity puzzle. SPIFFE solves identity inside a trust domain (and federates across them via Bundle Endpoint exchange). Identity Chaining solves authorization across them. Both are needed for agents that cross organizational boundaries.
Deployment realities
Putting Transaction Tokens into production requires some architectural commitments.
You need a Transaction Token Service. This is a new component — distinct from your existing authorization server, though sometimes deployed alongside it. Its job is to issue and (optionally) validate Txn-Tokens. The service must hold a signing key for the trust domain’s Txn-Token issuer and publish the corresponding public key for validators.
Your ingress points need to mint Txn-Tokens. API gateways, ingress proxies, and any other point where external requests enter the trust domain need to be wired into the Transaction Token Service. The gateway authenticates the external request, gets its authorization context, and asks the TTS for a Txn-Token before allowing the request to enter the internal call chain.
Your workloads need to validate Txn-Tokens. Each workload that participates in a transaction must validate the Txn-Token’s signature, claims, and (where relevant) call-chain assertion. For most deployments this is library work — a service mesh sidecar or an SDK middleware can handle the validation transparently.
Your authorization decisions need to consume Txn-Token claims. The whole point of preserving user/agent identity and authorization context through the call chain is that downstream services can make precise authorization decisions. If your services just rely on “I was called, so the request must be authorized,” you’ve gained nothing. The policy layer needs to actually inspect the user, the actor chain, and the transaction context.
You need monitoring on the Txn-Token issuance rate and chain depth. A misbehaving agent that triggers excessive Txn-Token issuance, or a runaway chain that fans out deeper than expected, is a signal worth alerting on.
Where Txn-Tokens compose with SPIFFE and CAEP
The three IETF work streams covered in this series — SPIFFE/WIMSE workload identity, OAuth SPIFFE Client Authentication, and Transaction Tokens — are mutually reinforcing rather than overlapping:
- SPIFFE answers: what is this workload’s identity, cryptographically, attested by the platform?
- OAuth SPIFFE Client Auth answers: how does this workload authenticate to OAuth infrastructure without distributed secrets?
- Transaction Tokens answer: how do we preserve user/agent identity and authorization context across all the workloads participating in a single externally-originated transaction?
A complete agentic identity deployment uses all three. The agent workload has a SPIFFE SVID issued by SPIRE. It uses that SVID — via the OAuth SPIFFE Client Authentication profile — to authenticate to your authorization server and to the Transaction Token Service. The Transaction Token Service issues Txn-Tokens that propagate the user’s identity, the agent’s identity, and the authorization context through every downstream call.
The next article in this series picks up the runtime side: how do you revoke a Txn-Token mid-flight when something goes wrong? That’s the Continuous Access Evaluation Protocol (CAEP) and Shared Signals Framework story, and it’s the last piece that makes the model operationally complete.
Primary sources: draft-ietf-oauth-transaction-tokens-07 (Tulshibagwale, Fletcher, Kasselman; 2026); draft-ietf-oauth-spiffe-client-auth-01; draft-ietf-wimse-arch-07; draft-ietf-wimse-workload-creds-00; RFC 8693 (OAuth 2.0 Token Exchange); RFC 7523; SPIFFE specifications at spiffe.io.