Transaction Tokens
Stops access tokens being passed between an agent’s internal tools and services while keeping the user’s intent attached.
Flows / Delegation chains
Transaction tokens
Inside your own infrastructure, replace the access token with a short-lived token that pins down one transaction and travels the whole call chain.
A request arrives at your edge with an access token. Behind the edge are an agent, the tools it calls, and the services those tools call. If the access token is passed along, every one of those services holds a credential that works at the front door. If each hop calls the others with only its own service identity, the downstream services have no idea who the request is for.
A transaction token sits between those two failures. At the edge, the external token is exchanged for a signed, short-lived token that records who the request is for, which workload asked, and the fixed details of what was requested. That token is passed unchanged from service to service inside one trust domain. Services can read it and make decisions on it, but they cannot alter the context, and the token is useless outside.
For agent systems this is a way to keep the user’s intent attached to a request as an LLM fans it out across tools, without handing the model’s surroundings a reusable credential.
Step by step
9 steps between 4 parties. Each step shows the message and who holds which credential afterward. Use ←→ or select any arrow.
Sequence diagram4 participants, 9 steps
- Direct call
- Response
- Local action
Drag to see every party and step. Tap a step to jump to its explanation.
An external request reaches the edge
The gateway validates the caller’s access token in the normal way. This is the last place that token should be seen.
Who holds what after this step
- Gateway
- newexternal access token
Parties not listed hold none of this flow’s credentials at this point.
The gateway asks for a transaction token
A profile of token exchange. The gateway authenticates as a workload, presents the access token as the subject, and supplies details of the request.
POST /txn-token-service/token_endpoint HTTP/1.1 Host: txn-token-service.trust-domain.example Content-Type: application/x-www-form-urlencoded grant_type=urn:ietf:params:oauth:grant-type:token-exchange &requested_token_type=urn:ietf:params:oauth:token-type:txn_token &audience=trust-domain.example &scope=trade.stocks &subject_token=<external access token> &subject_token_type=urn:ietf:params:oauth:token-type:access_token &request_context={"req_ip":"69.151.72.123","authn":"face"} &request_details={"action":"BUY","ticker":"MSFT","quantity":"100"}Who holds what after this step
- Gateway
- external access token
Parties not listed hold none of this flow’s credentials at this point.
The service validates and freezes the transaction context
It checks the subject token and the requester, then writes the context into the token it signs. From here on those details cannot be changed by anything downstream.
Who holds what after this step
- Gateway
- external access token
Parties not listed hold none of this flow’s credentials at this point.
A transaction token is issued
The header type is
txntoken+jwt.txnidentifies the transaction,subthe user,req_wlthe workload that asked for the token,rctxthe circumstances of the request, andtctxits fixed parameters. The audience is the trust domain itself.{ "iat": 1686536226, "exp": 1686536586, "aud": "trust-domain.example", "txn": "97053963-771d-49cc-a4e3-20aad399c312", "sub": "d084sdrt234fsaw34tr23t", "req_wl": "apigateway.trust-domain.example", "rctx": { "req_ip": "69.151.72.123", "authn": "face" }, "scope": "trade.stocks", "tctx": { "action": "BUY", "ticker": "MSFT", "quantity": "100" } }Who holds what after this step
- Gateway
- external access tokennewTxn-Token
Parties not listed hold none of this flow’s credentials at this point.
The request continues without the access token
The gateway forwards the request with the transaction token in the
Txn-Tokenheader. The external access token is dropped here.Who holds what after this step
- Gateway
- Txn-Tokenused up
external access token - Agent service
- newTxn-Token
Parties not listed hold none of this flow’s credentials at this point.
The agent service verifies the token
Signature, audience, expiry. The agent now knows the user and the approved action without holding anything it could use to start a different transaction.
Who holds what after this step
- Gateway
- Txn-Token
- Agent service
- Txn-Token
Parties not listed hold none of this flow’s credentials at this point.
The same token travels to the next hop
The agent authenticates to the tool as itself with its workload identity, and attaches the unmodified transaction token. Two questions, two credentials: which service is calling, and what transaction this is part of.
Who holds what after this step
- Gateway
- Txn-Token
- Agent service
- Txn-Token
- Tool service
- newTxn-Token
Parties not listed hold none of this flow’s credentials at this point.
The tool enforces the original intent
The tool can refuse anything that does not match
tctx. If a prompt injection has convinced the agent to sell instead of buy, the tool sees a request that contradicts the signed transaction and rejects it.Who holds what after this step
- Gateway
- Txn-Token
- Agent service
- Txn-Token
- Tool service
- Txn-Token
Parties not listed hold none of this flow’s credentials at this point.
Results flow back
The token expires within minutes. A copy found in a log is of little use: wrong time, and no value outside the trust domain.
Who holds what after this step
- Gateway
- Txn-Token
- Agent service
- Txn-Token
- Tool service
- Txn-Token
Parties not listed hold none of this flow’s credentials at this point.
Watch out for
- Transaction tokens do not authenticate the hop. Pair them with workload identity (mutual TLS or workload tokens) so each service knows which peer is calling.
- They are for use inside a trust domain. Crossing to another domain is a job for identity chaining.
- The transaction token service becomes critical infrastructure: every request depends on it, and it must be told the truth about request context.
- How agent-specific context should be represented is still being worked out in individual drafts.
Where this stands
The transaction tokens draft has been through repeated working group last calls and is waiting for its write-up before going to the IESG. A separate individual draft proposes agent-specific context for the token, so that each agent in a chain is recorded as the request moves. Its claim design changed during 2026, which is a fair signal of how settled it is.
Standards in play
See the full tracker for status and links.
Token Exchange
The primitive under on-behalf-of flows, ID-JAG, identity chaining and transaction tokens.
Transaction Tokens for Agents
One of several attempts to record which agents handled a request.
WIMSE Architecture
Includes a section on agents: each hop in an agent chain must explicitly scope and re-bind the security context.
AI Identity Management System (AIMS)
The closest thing to an IETF reference architecture for agent authentication and authorization. Its opening position: agents are workloads.
Related flows
Token exchange
Trade the token you were given for a new one that names both the user and the service now acting for them.
With or without a humanStable standards
Identity chaining
Carry who-is-this-for across an organizational boundary, with each side keeping control of its own tokens.
With or without a humanEmerging
Workload tokens (WIMSE)
A workload identity that is bound to a key and proven on every request, so it survives the gateways and proxies that agent traffic passes through.
No humanEmerging
SPIFFE + mTLS
Every agent process gets a cryptographic identity from the infrastructure it runs on, and uses it to authenticate both ends of every connection.
No humanStable standards