Splitting AI agent identity five ways: the transaction-token approach to trusted API calls

A post on dev.to, the opening installment of a planned series on trusted AI agent transactions, argues that the identity model behind ordinary API calls breaks down once an AI agent sits between a user and a service — and sketches how a combination of existing standards can hold the pieces apart.

The problem: one question becomes six

When a conventional application calls an API on a user's behalf, the service usually needs to answer a single question: who is the user? According to the post, an agent multiplies this into several distinct questions — which user authorized the work, which logical agent is acting, which running workload issued the call, which execution of that agent is involved, which transaction and purpose the call serves, and which service made the current network hop.

Packing every answer into a single claim, the author warns, creates a false sense of security. An agent's name is not cryptographic evidence about the process actually running; a workload identity is not the person; a transaction identifier is not a caller identity.

The implementation described keeps five values separate:

• UserID — the authenticated human or upstream principal
• AgentID — the approved logical agent definition
• AgentInstanceID — a single execution of that agent
• SPIFFEID — the attested runtime workload
• TransactionID — a fixed identifier for the delegated action

Why the user's token is not enough

Forwarding the original user access token through every downstream service fails in three ways, per the post. Services cannot reliably tell the user apart from the agent acting for them. A broadly scoped token can also travel into systems that had no reason to see it, and it generally says nothing about the purpose of this particular transaction.

The alternative the author adopts is the Transaction Tokens architecture from Tokenetes. An external endpoint exchanges the incoming authorization at a controlled Transaction Token Service boundary; the output is a short-lived, signed Txn-Token holding frozen identity and authorization context scoped to one call chain.

An agent_id field is not proof

Any HTTP request can assert an arbitrary agent name, so a server that authorizes on that value alone lets one workload impersonate another by editing a string. The post's rule is that the logical AgentID must come from trusted policy that maps a cryptographically verified workload identity onto an approved agent. Callers get to request operations — they do not get to assign themselves an identity.

Immutable context, authenticated hops

The Txn-Token carries the delegated context — user, logical agent, originating workload, transaction and purpose — and is never rewritten as it travels downstream. That prevents intermediate services from stripping or forging earlier context, and the shared transaction ID can be correlated across the agent, gateway, MCP server and protected API.

Each network connection is separately authenticated with SPIFFE mTLS, so a service accepts a call only when the verified transaction context, the verified immediate caller and the target policy all line up.

The reference flow

The post lays out a concrete pipeline: a user's OAuth token reaches an AI agent, which presents it at PingFederate for an RFC 8693 token exchange. The result is a short-lived transaction JWT that flows through an MCP gateway and MCP server before hitting the protected API. PingFederate fills the Transaction Token Service role, SPIRE supplies a JWT-SVID as agent workload evidence during the exchange and X.509-SVIDs for mTLS between workloads, and PingAuthorize evaluates the token's context at the gateway.

Tokenetes serves as the reference point for the call-chain model: a Txn-Token is minted once for the external invocation, stays unchanged as it moves downstream, and is accepted only inside its trust domain, while the immediate network caller is authenticated separately.

The author stresses that this is not a new identity system. It is a composition of existing user, workload, delegation, transport and policy controls, each with a clearly separated responsibility. A companion GitHub repository contains the implementation, and a follow-up post will cover PingFederate token exchange as the delegation boundary.

Why it matters

Before AI agents can be allowed to transact against real APIs, services need answers to two orthogonal questions at once: what delegated action is this, and who exactly is on the other end of this connection? Collapsing them into one token or one string field makes impersonation trivial and auditing impossible. The framing in this post — user, logical agent, agent execution, workload and transaction kept distinct, then bound in a short-lived immutable token with per-hop mTLS — offers teams a concrete pattern assembled from standards many already operate: OAuth, RFC 8693 exchange, SPIFFE/SPIRE and centralized policy. For anyone building agent-to-API infrastructure, particularly around MCP gateways, the five-identity decomposition is the durable takeaway.