Securing AI Agents with SPIFFE and SPIRE: Workload Identity for Autonomous Agents

Why a stored secret is the wrong foundation for an agent

An autonomous agent that holds a static API key or OAuth client secret has the same problem every service account has, only worse: the credential outlives the need for it, it gets copied into images and config files, and anyone — or any prompt-injected tool call — that reads it can impersonate the agent. The more agents and the more instances, the more copies of long-lived secrets you are tracking.

SPIFFE flips the model. Instead of presenting a secret to prove identity, a workload is attested by its environment and handed a fresh, short-lived credential bound to a stable identity. There is no static token to steal, and every running instance gets its own attested credential. This is the same shift from secrets to identity we describe for agents in general in what AI agent identity is.

How SPIFFE and SPIRE issue identity

SPIRE issues an SVID only after two attestation checks pass:

• Node attestation proves which machine runs the workload — a Kubernetes projected service account token, an AWS instance identity document, or GCP instance metadata.
• Workload attestation proves which process is calling — selectors such as the Kubernetes service account, namespace, and container image digest.

Only a workload that matches a registered entry on an attested node receives an SVID. The SVID comes in three shapes, and the practical fit for gateway calls today is the JWT-SVID:

The acme.com portion of the SPIFFE ID is the trust domain. On Kubernetes, SPIRE trusts projected service account tokens and the agent reads its JWT-SVID from the SPIFFE Workload API at runtime — so no secret is ever written to a config file or baked into an image.

How the gateway resolves an SVID

To TrueFoundry, a JWT-SVID is just another identity-provider token. The agent is registered as identity-provider-backed — the same registration step every externally-issued agent identity uses:

Each request then carries two tokens, exactly as in standard agent identity and on-behalf-of delegation:

Authorization: Bearer <USER_TOKEN>
x-tfy-agent-authorization: Bearer <JWT-SVID>

The gateway validates the SVID against SPIRE's JWKS, resolves the SPIFFE ID to the registered agent, checks whether that agent may reach the target and may act for the user, and forwards the call with the target's own outbound auth. The user's identity travels alongside the agent's the whole way.

Wiring it up

Three steps connect SPIRE to the gateway:

1. Register SPIRE as an identity provider. Expose SPIRE's OIDC-compliant discovery endpoint and add it under Platform → Identity Providers with the issuer, audiences, and JWKS URI.
2. Register the agent as identity-provider-backed, mapping the SPIFFE ID claim to the agent.
3. Present the JWT-SVID to the gateway on each call, as above. The SPIRE agent rotates it before expiry, so the agent never faces credential expiry mid-task.

Access itself is still governed by collaborator grants — who may invoke the agent, whom it may act for, and which MCP servers it may reach — the model covered in fine-grained authorization and what MCP authorization is.

Where teams get this wrong

Treating the SVID as a replacement for authorization. Attestation proves who the workload is; it does not decide what it may do. You still need collaborator grants and policy at the gateway — identity and authorization are separate layers.

Over-broad attestation selectors. If workload attestation keys only on a namespace, every pod in that namespace can obtain the same SVID. Pin selectors to the service account and image digest so the identity means one workload.

Forgetting the user. An SVID identifies the agent, not the person it acts for. The user's token must still travel in Authorization so the downstream system can answer whose data was touched.

Assuming mTLS alone is governance. X.509-SVIDs secure the transport, but a governed call still needs the gateway to resolve identity, authorize the pair, and audit it.

Want agent identity with no secret to leak?

TrueFoundry Gateway

A worked example

A platform team runs agents on Kubernetes and refuses to ship another long-lived token. They stand up SPIRE, register an entry for research-agent keyed on its service account and image digest, and expose SPIRE's OIDC endpoint. In TrueFoundry they add SPIRE as an identity provider and register research-agent as identity-provider-backed, mapping its SPIFFE ID. At runtime each pod pulls a JWT-SVID from the Workload API and sends it with the user's token to the gateway, which validates it against SPIRE's JWKS, resolves it to the registered agent, and authorizes the call. When a workload is decommissioned, they deregister its entry and the SVIDs simply stop at the next rotation — no secret to revoke, no config to clean up.

Gotchas worth knowing

• JWT-SVIDs are the practical fit today; WIT-SVIDs add proof-of-possession but require client changes. Start with JWT-SVID for gateway calls.
• First-class SPIFFE binding on the agent spec is marked coming soon in the docs — today you bind via the identity-provider mapping. Check the current docs before a wide rollout.
• Per-hop token exchange is rolling out; for multi-agent chains, confirm how delegation is stitched in your version.
• The trust domain is a security boundary. Keep one trust domain per environment and do not share SPIRE signing material across them.
• Node attestation depends on the platform. On managed Kubernetes, projected service account tokens are the usual evidence; confirm your cluster exposes them.

SPIFFE versus the alternatives

To see why attested identity matters, put it next to the two things teams reach for first. The difference is not cosmetic — it changes who can impersonate the agent and how fast you can shut a compromised one down.

The static key and the shared account share one flaw: the credential is a bearer secret, so possession is identity. SPIFFE breaks that equation — possession of an SVID is worthless without passing attestation on an attested node, and the SVID expires on its own within minutes. There is nothing durable to steal.

The portable-trust sandwich

The docs describe the end-to-end model as a stack of four layers, each solving one problem, which is worth making explicit because it shows where SPIFFE stops and the gateway starts:

1. Workload identity (the SVID) from runtime attestation — SPIRE proves the node and the process, then issues a short-lived credential bound to a stable SPIFFE ID.
2. Resolution to the registered agent — the gateway validates the SVID against SPIRE's JWKS and maps the SPIFFE ID to the agent in its registry.
3. Per-hop delegation via token exchange — the user travels as sub, the acting agent as act, and scope is narrowed to the next callee.
4. A target-native credential where needed — an on-behalf-of token, or a gateway-held OAuth credential, so the downstream tool gets a format it already trusts.

It is called portable because the stable agent identity is derived from attestation, not from a cloud-specific secret — so the same identity holds whether the workload runs on one cluster today and another tomorrow. Layer one is pure SPIFFE/SPIRE; layers two to four are where the TrueFoundry Gateway does its work.

On Kubernetes, concretely

Kubernetes is the common case, and it is where the "no secret on disk" claim becomes real. SPIRE trusts the cluster's projected service account tokens as node-and-workload evidence, and the agent reads its JWT-SVID from the SPIFFE Workload API — a local socket — at runtime. Nothing is written to a file, baked into an image, or passed as an environment variable, so there is no artifact for a leaked image or a prompt-injected cat to expose. When the SVID nears expiry, the SPIRE agent fetches a fresh one transparently, so a long-running agent never stalls on an expired credential. Pin workload attestation selectors to the service account and the container image digest, not just the namespace, so one SVID means exactly one workload rather than every pod in the namespace.

Related reading

• What Is AI Agent Identity? — the concept SPIFFE makes concrete
• Agent Identity and On-Behalf-Of Delegation — the two-header model the SVID plugs into
• AI Agent Governance — where identity sits in the stack
• What Is an MCP Gateway? — governing the tool calls themselves
• Agent Gateway vs LLM Gateway — why the multi-hop path needs its own control point

Conclusion

A stored secret is a liability that grows with every agent and every instance. SPIFFE and SPIRE replace it with identity that comes from attestation — short-lived, auto-rotated, and impossible to copy out of a config file. The TrueFoundry Gateway takes the SVID the agent earns at runtime, resolves it to a governed identity, and authorizes the call for the user it acts for.

The result is the thing security teams actually want from autonomous agents: an identity you can attest, authorize, audit, and revoke — without a single long-lived credential in sight.

Give every agent an attested identity and a clean audit trail.

Book a demo