SSOGEN / Learn / SPIFFE and SPIRE Explained

Learn

SPIFFE and SPIRE Explained

SPIFFE gives each software workload a short-lived, verifiable identity and SPIRE issues it; it says which workload is calling, not which person the call is for.

Updated Oct 11, 2026

Request More Info

Which workload is calling, and the question SPIFFE leaves open.

SPIFFE (Secure Production Identity Framework for Everyone) is a set of open standards for identifying software systems.

Each workload gets a name, the SPIFFE ID, and a short-lived document that proves it, so two services can authenticate each other without a stored password or API key.

SPIRE is the software that issues those documents, and one of several implementations of the standards.

SPIFFE answers “which workload is this?” well. It only partly answers the questions AI agents raise, and this page covers both halves.

The vocabulary, in one table

The SPIFFE concepts page defines the pieces. The Acme Corp values are fictional.

Term	What it is	Acme example
Trust domain	The trust root of one organization, environment or department	`acme.example`
SPIFFE ID	A URI naming one workload: `spiffe://` + trust domain + path	`spiffe://acme.example/billing/payments`
SVID	The verifiable document that proves a SPIFFE ID, as an X.509 certificate or a JWT	A certificate valid for a short time
Workload API	A local API a workload calls to get its SVID and the trust bundles, with no prior credential	A socket on the node
Trust bundle	The public CA roots (X.509) and keys (JWT) used to check SVIDs	Published by the trust domain

What the specifications pin down

These details decide what you can and can’t build:

Names. The SPIFFE ID specification limits trust domain names to lowercase letters, numbers, dots, dashes and underscores. Path segments allow the same characters plus uppercase and are case-sensitive. Percent-encoding, empty segments and a trailing slash are not allowed. Implementations must accept IDs up to 2048 bytes and should not issue longer ones.
X.509-SVID. The X.509-SVID specification requires exactly one URI Subject Alternative Name, the SPIFFE ID, and a validator must reject a certificate with more than one. A leaf certificate has the CA flag false and must not carry keyCertSign or cRLSign.
JWT-SVID. The JWT-SVID specification requires sub (the workload’s SPIFFE ID), aud and exp, and allows nine signing algorithms (RS, ES and PS at 256, 384 and 512). It warns that a JWT-SVID is a bearer token that can be replayed if intercepted, and asks for the shortest reasonable validity period, with no hard maximum.

The trade-off follows from the format:

X.509-SVID. It comes with a private key and sets up mutual TLS, so the key proves possession.
JWT-SVID. It travels in a request as a bearer token, usable by whoever holds it until it expires, as the concepts page states.

SPIRE: the server, the agents and attestation

The SPIRE concepts page describes two parts.

SPIRE Server signs identities for its trust domain, stores the registration entries and signing keys, and authenticates agents.
SPIRE Agent runs on each node. It requests SVIDs from the server, caches them, and exposes the Workload API to workloads on that node.

Identity is issued in two steps:

Node attestation. The agent proves what it is with evidence from where it runs, such as an AWS identity document or a Kubernetes token, and receives its own SPIFFE ID.
Workload attestation. The agent inspects a calling process, collects selectors (properties of the process) and matches them against registration entries. A match returns the SVID for that entry.

The workload never presents a secret to obtain its identity, which is the design goal. The SPIRE “agent” is a node-level daemon, not an AI agent.

Federation between trust domains

Two organizations, or two clusters, each run their own trust domain. Federation works by exchanging trust bundles.

A bundle is a JWK Set (RFC 7517) with:

keys. An array. Rotation adds new keys and drops old ones, and an empty keys array means the domain revoked what it published before.
spiffe_sequence. A revision number.
spiffe_refresh_hint. A refresh interval in seconds.

That specification doesn’t cover how bundles are delivered.

Project status and the latest release

SPIFFE is a graduated project of the Cloud Native Computing Foundation. The CNCF project page gives the dates:

Accepted. March 29, 2018.
Incubating. June 22, 2020.
Graduated. August 23, 2022.

When this page was written, the latest SPIRE release on GitHub was v1.15.3, published August 21, 2026. Check the releases page before you pin a version.

SPIFFE next to other ways to identify software

	SPIFFE / SPIRE	OAuth 2.0 access token	Cloud workload identity federation	API key
What is identified	A workload, by SPIFFE ID	A client, and often a user and scopes, as the authorization server decides	An external workload, mapped to a cloud identity	The holder of the string
Credential lifetime	Short-lived, rotated automatically	Short, set by the authorization server	Short-lived tokens exchanged on demand	Until someone deletes it
How it is proven	Attestation of node and process; then a certificate with a key, or a JWT	A client secret, a signed assertion or a key-bound proof	An external identity provider’s token, exchanged at a token service	Possession of the string
Typical use	Service-to-service calls, mutual TLS	Calls to APIs on behalf of an app or a user	A workload outside a cloud calling that cloud’s APIs	Simple API access

The cloud column rests on one vendor’s description.

Google Cloud’s documentation (read 2026-10-11) says its workload identity federation lets outside workloads use federated identities instead of service account keys. It relies on the OAuth 2.0 token exchange specification and a Security Token Service that returns a federated token.

Other clouds build this differently, so treat the column as one example. Workload identity federation compares AWS, Google Cloud and Microsoft Entra ID for the same token.

Where AI agents fit, and where SPIFFE stops

An AI agent is a workload, so SPIFFE can give it a name and a key-backed identity with no static secret. The agent and the services it calls can authenticate each other, and a leaked credential expires soon.

The sources define workload identity only.

The SPIFFE ID and SVID specifications describe how a workload is named and proven. They say nothing about the person the workload acts for, that person’s consent, or a human approval before a sensitive action.

Those belong to a delegation layer, which a different standard covers. RFC 8693, section 4.1 defines the act claim to record that delegation happened and who the acting party is, while sub stays the original subject.

The two layers answer different questions:

Which software is calling? A workload identity such as a SPIFFE ID answers it.
Whose authority is this call using, and did that person agree? A delegation credential answers it. See OAuth token exchange for how the token is built.

A deployment can use both: the workload identity secures the connection, and the delegation credential carries the person. Neither replaces the other.

For the wider picture of software identities, read non-human identity. For the risks agents add, read agentic AI security.

What SSOGEN’s agent credential carries

SSOGEN covers the delegation side. Its agent credential names the person in sub and the agent in act, is bound to the agent’s own key, and lives 240 seconds by default, never more than 270.

Decode such a token with the JWT decoder, which includes a sample agent credential. See AI agent identity for the model: owners, scopes, consent and approvals.

Common mistakes

Logging or forwarding a JWT-SVID. It is a bearer token until it expires. Scope aud to one service.
Using one SPIFFE ID for many agents. The identity then tells you which deployment called, not which agent.
Assuming workload identity covers consent. It doesn’t; the specifications above stop at the workload.
Reading attestation as authorization. Attestation decides which identity a process gets. What that identity may do is a separate policy decision.

Questions people ask

What is a spiffe?

SPIFFE stands for Secure Production Identity Framework for Everyone. It’s a set of open specifications for giving software workloads short-lived, verifiable identities. They’re written as SPIFFE IDs and proven by SVIDs, either X.509 certificates or JWTs. Infrastructure issues the identity, so services stop using stored passwords and API keys between them.

What is the difference between SPIFFE and SPIRE?

SPIFFE is the set of specifications: the ID format, the SVID documents, the Workload API and federation. SPIRE is software that implements them. A SPIRE server signs identities for a trust domain, and SPIRE agents on each node attest workloads and hand out SVIDs. Other software can implement SPIFFE too.

How do you pronounce spiffe?

The SPIFFE documentation and repository don’t state a pronunciation, so there’s no official one to cite. The acronym expands to Secure Production Identity Framework for Everyone. Many engineers say “spiffy.” Confirm with your team before a talk.

Is spiffe a standard?

SPIFFE is a set of open specifications, not a single product: SPIFFE ID, X.509-SVID, JWT-SVID, Workload API and federation. It’s a Cloud Native Computing Foundation project, graduated August 23, 2022. It isn’t an IETF RFC, so cite the SPIFFE specifications themselves.

Where to go next

Start. The Learn hub.
Identities. Read non-human identity for the five kinds of software identity.
Delegation. Read OAuth token exchange.
Risks. Read agentic AI security for what can go wrong.
Try it. Use the JWT decoder on a token.

Sources, all read 2026-10-11: SPIFFE concepts, SPIFFE overview, SPIRE concepts, SPIFFE ID, X509-SVID, JWT-SVID, Trust domain and bundle, CNCF SPIFFE, SPIRE releases, RFC 8693, Google Cloud workload identity federation.