Trusted AI Agent Transactions, Part 3: SPIRE Workload Identity

A developer detailed the use of SPIRE workload identity in trusted AI agent transactions, explaining how SPIFFE IDs provide cryptographically attested runtime identities distinct from logical agent policy identities. The implementation uses SPIRE JWT-SVIDs with dedicated audiences and Docker workload attestation, ensuring that workloads cannot impersonate other agents by altering request data. The lab uses a join token for bootstrap, which is noted as a development choice, with production deployments advised to use appropriate node attestors.

Part 2 //02-pingfederate-token-exchange.md used a SPIRE JWT-SVID as the actor token in PingFederate token exchange. That proves more than a caller-supplied agent name, but it helps to understand exactly what it proves. A logical agent describes an approved application role. A SPIFFE ID identifies an attested running workload. They are related, but they are not interchangeable. AgentID: urn:agent:customer-support SPIFFEID: spiffe://example.org/agent/customer-support The first is a policy identity. The second is a cryptographically attested runtime identity. The implementation uses both SPIRE credential formats: The JWT-SVID uses an audience dedicated to the PingFederate Transaction Token Service integration. The Txn-Token audience identifies the trust domain in which the call chain is valid. The protected target and tool belong in transaction context and authorization policy. Reusing the actor-token audience for the Txn-Token would blur two distinct trust boundaries. The transaction token remains unchanged through the request path, but the immediate caller changes: php Agent - Gateway: caller is the agent SPIFFE ID Gateway - MCP: caller is the gateway SPIFFE ID MCP - Protected API: caller is the MCP server SPIFFE ID This lets the protected API reject a direct agent call even if the agent possesses a valid transaction token. The API can require the verified transaction context and the expected MCP server identity on the current mTLS connection. The Docker lab runs a SPIRE Server and Agent and uses Docker workload attestation. Each workload has a distinct label and registration entry: wai.workload=demo-agent wai.workload=mcp-gateway wai.workload=demo-mcp-server wai.workload=demo-api Those selectors produce separate SPIFFE IDs. Mounting the Workload API socket does not let a container choose an identity. SPIRE observes the calling workload and matches its external selectors to a registered entry. The lab uses a join token to bootstrap the SPIRE Agent. That is explicitly a development choice. A production deployment should use a node attestor appropriate to its environment, such as cloud instance identity, Kubernetes PSAT, X.509 proof of possession, or hardware-backed attestation. SPIRE signing keys can overlap during normal rotation. The integration accepts multiple JWT authorities only when every entry is explicitly a JWT-SVID authority, uses a unique non-empty key ID, and satisfies the configured key and algorithm constraints. Unknown key IDs, duplicate IDs, unexpected algorithms, ambiguous identities, missing audiences, and conflicting claims fail closed. The token header is never allowed to choose a newly trusted algorithm dynamically. The binding rule remains the same throughout: a workload cannot become another logical agent by changing request data. Previous: Using PingFederate token exchange as the delegation boundary //02-pingfederate-token-exchange.md Next: Making policy decisions with PingAuthorize //04-pingauthorize-policy.md GitHub Repository: https://github.com/darkedges/pf-tts https://github.com/darkedges/pf-tts