Transaction Tokens: The Missing Authorization Layer for Non-Human Identity and AI Agents

Most enterprises still run their internal networks on an assumption they would never admit to publicly: once a request is past the gateway, it's trusted. Zero Trust architectures, maturity models, and every federal mandate since EO 14028 say otherwise. Walk the call path of a typical microservices deployment, though, and you'll usually find one of two patterns. Either there's no internal security at all, or there's hop-to-hop security, where each service authenticates to the next over mTLS and nothing more.

Hop-to-hop security proves that Service B is talking to Service C. It says nothing about what Service B is asking for, on whose behalf, or whether the request still matches what the user originally authorized. Compromise one intermediate workload and you can rewrite parameters, swap the subject of the request, and call any API that workload can reach. That was a manageable risk when an application was a monolith. It is not manageable when a single user action fans out across dozens of services. And it is getting worse as AI agents start orchestrating those services autonomously.

OAuth Transaction Tokens (Txn-Tokens) are the IETF's answer to this problem. They matter more for the non-human identity ecosystem than almost any other spec in flight right now.

The problem with passing access tokens around

The default pattern in most environments is to take the inbound OAuth access token and forward it through the call chain. George Fletcher, one of the spec's authors, laid out the failures of that approach on a recent episode of Identity at the Center: Decoded. The problems are worth stating plainly.

First, access tokens are over-provisioned by design. An access token represents everything a user has authorized a client to do. If I'm adding a stock to a watch list, the token I'm carrying may also authorize money transfers. Every workload in the chain now holds a credential far more powerful than the transaction requires.

Second, access tokens are replayable. Steal one from a compromised internal workload, present it at the front door, and nobody knows the difference. Sender-constraining mechanisms like DPoP close that gap at the edge. But a DPoP-bound token can't be legitimately forwarded internally without throwing away the very property that made it secure.

Third, external and internal authorization models are different. The scopes you grant to a mobile app are coarse. The permissions your internal services need are fine-grained and change as your backend evolves. Fletcher described a common failure: a new backend workload needs a scope that existing client tokens don't carry. The workaround is quiet privilege escalation at refresh time, because nobody wants to force every user to re-consent. That is an authorization model bending to fit the wrong token.

The result is a system where authorization context degrades, expands, or gets forged as a request moves through the environment.

That is exactly the condition Zero Trust is supposed to eliminate.

What a transaction token actually is

A transaction token is a short-lived, signed JWT that represents a specific transaction, not a general grant of authority. A Transaction Token Service (TTS) issues it when a request enters the trust domain, whether at the gateway or from an internally initiated process. The token then follows that request through every workload it touches.

The core claims tell the story:

{
  "iss": "https://tts.example.internal",
  "aud": "trust-domain.example.internal",
  "iat": 1758542400,
  "exp": 1758542435,
  "txn": "97053963-771d-49cc-a4e3-20aad399c312",
  "sub": "user:jdoe@example.com",
  "scope": "watchlist.add",
  "req_wl": "api-gateway.example.internal",
  "rctx": {
    "req_ip": "198.51.100.23",
    "client": "mobile-app-ios"
  },
  "tctx": {
    "watchlist": "tech",
    "symbol": "ACME"
  }
}

The sub is the principal the transaction is about: a human, or the agent itself if it's acting on its own behalf. The aud is the trust domain where the token is valid, and nowhere else. The txn is a unique transaction identifier every service can log. The scope is the narrow capability this transaction is authorized for; it's expressed in your internal authorization model, not the client's OAuth scopes. The requesting workload identifies the software that asked for the token. The request context (rctx) captures details about the originating call, and the transaction context (tctx) holds the parameters that define the transaction itself.

Because the TTS signs the whole structure, those values are immutable for the life of the transaction. A compromised intermediate service can't change $100 into $1,000. It can't redirect a request about one user to another user's account. It can't widen a watch-list operation into a funds transfer. Each downstream service still makes its own authorization decision, whether inline, in a sidecar PDP, or through an externalized policy engine. It makes that decision against data the attacker can't tamper with.

Why this matters for non-human identity

The NPE conversation has spent the last few years focused on authentication. SPIFFE/SPIRE, IETF WIMSE, and workload attestation have given us strong, cryptographically verifiable workload identity. That work is essential, and it is also incomplete. Knowing with certainty which workload is calling tells you nothing about what authority that workload is exercising right now, or where that authority came from.

Transaction tokens fill that gap. They separate workload authentication from transaction authorization. The SVID or WIMSE credential proves who the caller is. The Txn-Token proves what this specific call is allowed to do and on whose behalf. These are complementary layers, and a mature NPE architecture needs both.

This separation is also what ends impersonation. When an agent or service acts using a user's credentials, downstream audit trails can no longer tell whether the human or the software took the action. With Txn-Tokens, the principal and the requesting workload are distinct, signed claims. The human stays the sub. The agent or gateway that asked for the token stays identifiable. Accountability survives the call chain.

Why AI agents make this urgent

Agentic AI breaks nearly every assumption behind traditional service authorization. Agents decide at runtime which tools and APIs to call. They spawn sub-agents. They build call graphs no architect drew in advance. And the common practitioner shortcut today is to hand the agent the user's access token, or drop it into a context window, and hope for the best.

That is the over-provisioned, replayable, impersonation-prone pattern described above, now running inside a system that makes non-deterministic decisions.

It is the worst possible pairing.

Transaction tokens give agentic architectures several things they badly need.

• Per-action least privilege

  Each transaction an agent initiates can be scoped to the exact capability it requires. An agent authorized to manage your calendar gets a token for "create this event," not a standing grant over your entire workspace. If the token is captured, the attacker gets one narrowly bounded, rapidly expiring operation.

• Preserved delegation context

  When an agent calls through a gateway, the gateway may be the requesting workload. The agent's identity can still travel in the request context, so downstream services know which agent initiated the action. An individual draft now in the OAuth Working Group, a transaction-token profile for agents, adds standardized claims for exactly this. It includes an actor chain that records the delegation path and supports policy limits on delegation depth, plus agent-specific context. Anyone who has watched unbounded nested-group traversal wreck a directory knows why capping delegation depth matters.

• Traceability by design

  The txn claim gives every service in the graph a shared correlation ID. That is a real detection capability, not just a logging nicety. If a transaction type that normally touches five services suddenly touches seven, your SIEM can flag the anomaly. For agents whose call paths are inherently dynamic, that baseline is how you tell legitimate adaptation from hijacked behavior.

• Ephemerality matched to execution

  The spec deliberately doesn't mandate a lifetime. The TTS sets TTL by policy, per transaction type, and the guiding principle is to cover roughly the 99.99th percentile of legitimate execution time and nothing more. For agent-to-sub-agent communication on the same host, with no network latency, lifetimes could be measured in milliseconds.

Crossing the trust boundary

Transaction tokens are bound to a single trust domain. If one ever shows up at your front door, drop it and raise an alarm. But agents don't stay inside your perimeter. They call Salesforce, ServiceNow, and cloud provider APIs.

Fletcher has a separate draft addressing this. The pattern works like this: a workload presents its Txn-Token to its own issuing infrastructure and receives an assertion scoped for the external domain. It then exchanges that assertion at the external authorization server via OAuth Token Exchange, and gets back an access token for the target API. The pattern repeats across each boundary. For vendors, this is a way out of the SaaS service-account sprawl. Instead of provisioning thousands of API accounts and long-lived client secrets, they can trust a customer's transaction context and issue scoped, ephemeral access. That shift would do more to shrink the NPE credential attack surface than another round of secrets-rotation tooling.

Where the spec stands and how to start

The core Transaction Tokens specification is adopted work in the IETF OAuth Working Group. It has cleared working group last call and is in shepherd write-up, so normative changes are unlikely before it becomes an RFC. The agent profile and cross-domain work are active individual drafts in the same working group.

Implementations already exist. Keycloak ships transaction token support, and Tokenetes provides an open-source Transaction Token Service. Commercial identity platforms are only starting to follow.

Adoption doesn't require a big-bang authorization overhaul, and that was an explicit design goal. Start by requiring a Txn-Token on every internal API call, carrying only the principal and the requesting workload. That alone ends subject-swapping by compromised intermediates. Then lock down the critical transaction parameters. Then evolve toward fine-grained internal authorization policy one service at a time. Pick one high-value transaction path, instrument it, and prove the model.

The bottom line

Workload identity told us who is calling. Transaction tokens tell us what this call is allowed to do, for whom, and whether that has changed since the request began.

In an ecosystem where non-human identities already outnumber humans by orders of magnitude, and AI agents are building call graphs on the fly, that second question is where the real risk lives.

Assume the adversary is already on your network, because the breach record says they are. Then ask whether your internal authorization context would survive them. If the honest answer is "we pass the access token along," you know where to start.