Skip to main content
Use this scenario when your agents run on infrastructure you control — Kubernetes, VMs, containers — and you want their identity derived from where they run instead of a secret you mint and distribute. The agent never holds a long-lived credential at all: the platform attests the running workload and issues it a short-lived, automatically rotated identity document. SPIFFE is the open standard for this; SPIRE is its reference implementation. This is not an alternative to the other scenarios so much as a stronger bottom layer: SPIFFE answers “how does the agent prove who it is” with attestation instead of a stored secret, and everything above — registration, grants, delegation, token exchange — works exactly as in the blueprint.

​
Why workload identity fits agents

​
How an agent gets its identity

1

SPIRE attests the workload

Node attestation proves which machine or node the workload runs on (evidence: a Kubernetes projected service account token, an AWS instance identity document, GCP instance metadata). Workload attestation proves which process is calling (selectors: Kubernetes service account, namespace, container image digest). Only a workload matching a registered policy gets an identity.
2

SPIRE issues an SVID

The attested workload receives a SPIFFE Verifiable Identity Document carrying its SPIFFE ID, for example spiffe://acme.com/ns/agents/sa/research-agent:SVIDs are rotated by the SPIRE agent before expiry, so the agent never experiences a credential-expiry event.
3

TrueFoundry validates it as an identity provider

SPIRE exposes an OIDC-compliant discovery endpoint. Register it under Platform → Identity Providers (issuer, audiences, JWKS URI), then register the agent with an identity provider-backed identity mapping the SPIFFE ID claim to the agent. The agent presents its JWT-SVID to the gateway exactly like any other identity provider token.
A common Kubernetes pattern: SPIRE trusts the cluster’s projected service account tokens, and the agent reads its JWT-SVID from the SPIFFE Workload API at runtime. No secret is ever written to a config file or image.

​
Combining SPIFFE with the other scenarios

SPIFFE identifies the agent workload; it says nothing about the user the agent acts for, and third-party resources don’t accept SVIDs. The layering that works — sometimes called the portable-trust sandwich:
  • Inbound: the agent authenticates with its SVID; the user’s identity travels alongside it, as in every scenario.
  • Outbound: the gateway performs the same token exchange it would for any agent — OBO within a domain, ID-JAG across domains, or per-user OAuth — minting whatever the target trusts. (Per-hop exchange is rolling out — see coming soon.)
  • Cross-cloud: because SPIFFE is vendor-neutral, the same agent identity survives a move between clouds — the gateway keeps the policy and audit schema constant while the runtime underneath changes.
Coming soon: first-class SPIFFE binding on the agent registration — attaching the SPIFFE ID directly to the agent spec so per-instance SVIDs are bound to the stable per-agent identity, giving fleet-level policy with instance-level revocation.