{"slug": "trusted-ai-agent-transactions-part-3-spire-workload-identity", "title": "Trusted AI Agent Transactions, Part 3: SPIRE Workload Identity", "summary": "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.", "body_md": "[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.\n\nA logical agent describes an approved application role. A SPIFFE ID identifies an attested running workload. They are related, but they are not interchangeable.\n\n```\nAgentID:  urn:agent:customer-support\nSPIFFEID: spiffe://example.org/agent/customer-support\n```\n\nThe first is a policy identity. The second is a cryptographically attested runtime identity.\n\nThe implementation uses both SPIRE credential formats:\n\nThe 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.\n\nThe transaction token remains unchanged through the request path, but the immediate caller changes:\n\n``` php\nAgent -> Gateway:     caller is the agent SPIFFE ID\nGateway -> MCP:       caller is the gateway SPIFFE ID\nMCP -> Protected API: caller is the MCP server SPIFFE ID\n```\n\nThis 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.\n\nThe Docker lab runs a SPIRE Server and Agent and uses Docker workload attestation. Each workload has a distinct label and registration entry:\n\n```\nwai.workload=demo-agent\nwai.workload=mcp-gateway\nwai.workload=demo-mcp-server\nwai.workload=demo-api\n```\n\nThose 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.\n\nThe 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.\n\nSPIRE 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.\n\nUnknown 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.\n\nThe binding rule remains the same throughout: a workload cannot become another logical agent by changing request data.\n\nPrevious: [Using PingFederate token exchange as the delegation boundary](//02-pingfederate-token-exchange.md)\n\nNext: [Making policy decisions with PingAuthorize](//04-pingauthorize-policy.md)\n\nGitHub Repository: [https://github.com/darkedges/pf-tts](https://github.com/darkedges/pf-tts)", "url": "https://wpnews.pro/news/trusted-ai-agent-transactions-part-3-spire-workload-identity", "canonical_source": "https://dev.to/darkedges/trusted-ai-agent-transactions-part-3-spire-workload-identity-1gfb", "published_at": "2026-08-23 23:02:55+00:00", "updated_at": "2026-08-23 23:14:17.295910+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "ai-infrastructure"], "entities": ["SPIRE", "SPIFFE", "PingFederate", "Docker", "GitHub"], "alternates": {"html": "https://wpnews.pro/news/trusted-ai-agent-transactions-part-3-spire-workload-identity", "markdown": "https://wpnews.pro/news/trusted-ai-agent-transactions-part-3-spire-workload-identity.md", "text": "https://wpnews.pro/news/trusted-ai-agent-transactions-part-3-spire-workload-identity.txt", "jsonld": "https://wpnews.pro/news/trusted-ai-agent-transactions-part-3-spire-workload-identity.jsonld"}}