What is SPIFFE?
By Identra · Updated
SPIFFE is an open standard for securely identifying software workloads in dynamic environments. Each workload gets a SPIFFE ID and a short-lived cryptographic credential called an SVID, delivered through a local Workload API instead of static secrets. SPIRE, the reference implementation, attests each workload before issuing credentials, replacing shared secrets with provable, automatically rotated identity.
Key numbers
- SPIFFE and SPIRE graduated from the CNCF on September 20, 2022, after entering the sandbox in 2018 (CNCF graduation announcement, 2022)
- SPIRE issues X.509-SVIDs with a default lifetime of 1 hour and JWT-SVIDs with a default of 5 minutes (SPIRE server configuration reference)
- Production adopters include Bloomberg, GitHub, Netflix, Pinterest, and Uber, with ByteDance securing hundreds of thousands of workloads (CNCF graduation announcement, 2022)
How does SPIFFE identify a workload?
SPIFFE, the Secure Production Identity Framework For Everyone, gives every piece of software a name it can prove. That name is a SPIFFE ID, a URI like spiffe://prod.example.com/billing/api that uniquely identifies a workload within a trust domain, the logical boundary an organization controls. Because the ID is tied to what the workload is rather than where it runs, the same service keeps a stable identity across Kubernetes, VMs, and bare metal.
The proof comes as an SVID, a SPIFFE Verifiable Identity Document. SVIDs exist in two formats: an X.509 certificate for mutual TLS between services, and a JWT for calls that cross HTTP boundaries. Workloads fetch their SVIDs from a local Workload API, which rotates them automatically, so no developer ever handles or ships the credential. This is what separates SPIFFE from the ad hoc machine identity practices it replaces: identity is issued to running software at runtime, not pasted into a config file.
What does SPIRE add on top of the standard?
SPIFFE is a set of specifications; SPIRE is the CNCF-graduated runtime that implements them. SPIRE's core job is attestation: before a workload receives an SVID, SPIRE verifies claims about it through multiple factors, such as which Kubernetes namespace and service account it runs under, which cloud instance hosts it, or the hash of its binary. Only workloads that match a registered set of selectors get credentials.
This attestation step is what makes the identity trustworthy. A stolen API key works from anywhere, but an SVID is only issued to a process that proves, at runtime, that it is the workload it claims to be. SPIRE then keeps credentials short-lived, issuing X.509-SVIDs with a default lifetime of one hour and JWT-SVIDs with a default of five minutes, so a leaked credential is only useful within a short window.
Why does SPIFFE matter for non-human identity?
Most non-human identities today authenticate with long-lived static secrets: API keys, service account passwords, and tokens that accumulate in code, CI variables, and wikis. That is the root cause of secret sprawl, and it is why credential theft against workloads is so productive for attackers. SPIFFE attacks the problem at the source by removing the pre-provisioned shared secret from workload authentication.
SPIFFE removes pre-provisioned shared secrets and shortens the usable exposure window rather than making theft impossible: SVID private keys still live in workload memory, and the issuing infrastructure's signing and bootstrap keys remain sensitive material that must be protected and rotated. Credentials are minted on demand, expire in minutes to hours, and are bound to attested software, which moves workload authentication toward zero standing privileges. It also shrinks the operational load that secrets management tools carry, since the highest-volume category of secrets, service-to-service credentials, no longer needs to exist as stored material.
How does SPIFFE federation work across clouds?
Modern estates span multiple clouds and clusters, and identity sprawl follows. SPIFFE addresses this with trust domain federation: two SPIFFE deployments exchange trust bundles so a workload in one domain can verify SVIDs from another without sharing keys. A payments service in one company's trust domain can authenticate a partner's workload directly over mutual TLS.
SPIFFE also interoperates with the identity systems clouds already run. SPIRE can act as an OIDC provider, letting an SVID-holding workload exchange its identity for AWS, Google Cloud, or Azure access without any stored cloud credential. That pattern, workload identity federation, is how organizations connect SPIFFE-issued identity to cloud IAM and keep least privilege enforceable at the cloud boundary.
Where does SPIFFE stop short for AI agents?
SPIFFE answers one question with cryptographic certainty: which workload is this? For AI agents, that is necessary but not sufficient. An SVID can prove that an agent process is the deployed agent binary, but it says nothing about which user the agent is acting for, what task it was given, or whether its current action matches its instructions. Agent security lives in those questions, especially in delegation chains where one agent invokes another on a human's behalf.
SPIFFE is also an authentication standard, not an authorization or monitoring one. A perfectly attested agent holding a valid SVID can still be manipulated through prompt injection into misusing the access its identity grants, a textbook confused deputy scenario. Closing that gap requires layers SPIFFE deliberately leaves to others: per-action authorization, delegation context, and runtime enforcement that watches what a credentialed identity actually does.
- SPIFFE provides: attested workload identity, short-lived SVIDs, automatic rotation, cross-domain federation
- SPIFFE does not provide: on-behalf-of user context, task-level authorization, delegation chain tracking, behavioral monitoring
- For agents, SVIDs are the identity substrate; governance and runtime controls must be layered on top
How Identra thinks about it
Identra views SPIFFE as the right substrate for workload authentication and encourages customers to adopt it wherever their platforms allow: attested, short-lived SVIDs are strictly better than static secrets. But for agentic AI, authentication is the floor, not the ceiling. An agent with a valid SVID still needs an owner, a delegation trail, scoped permissions, and runtime oversight. Identra treats SPIFFE identities as first-class citizens in the identity inventory and layers the agent-specific context on top: who deployed the workload, which humans it acts for, what it is entitled to touch, and whether its live behavior matches that intent.
Go deeper: The Non-Human Majority
Frequently asked questions
What is the difference between SPIFFE and SPIRE?
SPIFFE is the specification: it defines SPIFFE IDs, SVID formats, and the Workload API. SPIRE is the open-source reference implementation that issues those credentials in production, handling node and workload attestation, registration, rotation, and federation across Kubernetes, VMs, and bare metal.
What is an SVID?
An SVID, or SPIFFE Verifiable Identity Document, is the short-lived credential that proves a workload's SPIFFE ID. It comes in two formats: an X.509 certificate used for mutual TLS between services, and a JWT used when identity must cross HTTP or layer 7 boundaries.
Does SPIFFE replace secrets management?
Partly. SPIFFE eliminates the largest category of stored secrets, service-to-service credentials, by issuing identity at runtime. Organizations still need secrets management for third-party API keys, database passwords on legacy systems, and other credentials that external parties require as static material.
Can SPIFFE secure AI agents?
SPIFFE can authenticate the workload an agent runs as, which is a strong foundation. It does not capture the user an agent acts for, the task it was assigned, or whether its behavior matches intent. Agent security requires delegation context, scoped authorization, and runtime monitoring layered on top of SPIFFE.