nhi.sgit.ai / industry / spiffe

SPIFFE / SPIRE, explained

SPIFFE (Secure Production Identity Framework For Everyone) is the open, vendor-neutral standard for workload identity, and SPIRE is its reference implementation. It is the mature answer for agents you run — and understanding how it works is the clearest way to see why it cannot apply to agents you rent.

The core idea

Every workload gets a name — a SPIFFE ID like spiffe://example.org/billing/agent-4 — and a short-lived cryptographic document proving it holds that name: an SVID (SPIFFE Verifiable Identity Document), typically an X.509 certificate or a JWT. SVIDs rotate automatically, so there are no long-lived secrets to store, leak or rotate by hand. The workload never presents a password; it presents a certificate that expires in minutes to hours and is re-issued continuously.

What makes the identity trustworthy is attestation: the identity is issued only after something you installed verifies what the workload actually is — which node it runs on, which container image, which service account, which process path. Identity is derived from observed properties, not from possession of a secret.

How an identity is issued

sequenceDiagram
    participant W as Workload (your agent)
    participant A as SPIRE Agent (on the node)
    participant S as SPIRE Server
    Note over A,S: You installed both — this is the precondition
    W->>A: Connects to the Workload API (local socket)
    A->>A: Workload attestation: observes selectors
(container image, k8s service account, unix uid...)
    A->>S: Presents node identity + workload selectors
    S->>S: Matches selectors against registration entries
(spiffe://example.org/billing/agent-4 = these selectors)
    S-->>A: Signs and returns a short-lived SVID
    A-->>W: Delivers SVID + trust bundle
    Note over W: Identity expires in minutes-hours
and rotates automatically — nothing to store

Two things to notice. First, the workload itself holds no bootstrap secret — the SPIRE Agent observes it from outside and vouches for it. Second, the whole flow runs on machines you control: the agent on every node, the server with its datastore and certificate authority. That is what "attestation" costs.

How the identity is used

flowchart LR
    subgraph TD["Trust domain: example.org (yours)"]
        A1["Agent 1
spiffe://example.org/agents/1"]
        A2["Agent 2
spiffe://example.org/agents/2"]
        V["Vault / API / database
accepts SVIDs, checks the ID"]
    end
    A1 -- "mTLS with SVID 1" --> V
    A2 -- "mTLS with SVID 2" --> V
    V -. "policy: agents/1 may read,
agents/2 may not" .-> V

Services authenticate each other over mutual TLS using SVIDs, and authorisation policy is written against SPIFFE IDs rather than network locations or shared secrets. This is what gives the four-agents scenario its best possible privileges-granted answer: each agent holds only its own short-lived identity, and a compromised one reaches only its own grants, only until rotation. Separate trust domains (yours, a partner's) can federate by exchanging trust bundles — identity crosses organisations without shared credentials.

What it costs

The practitioner analysis this site cites is blunt: building SPIRE properly is a multi-year engineering project with compounding operational costs — server and agents deployed, scaled, maintained and secured; datastores; certificate infrastructure; proxy configuration; registration policy; monitoring; a dedicated team. And by itself it does not solve SaaS access, legacy credential types, or agent identity specifically. That cost is why the commercial broker category exists, and why Vault now issues SPIFFE identities natively — buying the layer instead of building it.

Why none of this applies to agents you rent

flowchart TB
    subgraph yours["Your infrastructure — SPIFFE works"]
        SA["SPIRE Agent ✓ (you installed it)"] --> WL["Workload attested ✓"] --> ID["Short-lived scoped identity ✓"]
    end
    subgraph theirs["Provider's infrastructure — agents you rent"]
        X1["SPIRE Agent ✗ (you cannot install anything)"] --> X2["Workload unattestable ✗"] --> X3["One lever: the credential you hand over"]
    end

Every step of the issuance flow assumes something you installed can observe the workload. A rented agent — in a hosted coding tool, a chat interface, behind a vendor API — runs where you can install nothing and observe nothing. The mechanism is not merely unavailable; it is unavailable by construction. That is the two-populations thesis in one diagram, and it is why our option assessment scores SPIFFE "No" on works for rented agents while calling its privileges column the best available anywhere.

Learn more

The standard and its documentation: spiffe.io — a CNCF graduated project
SPIFFE for agentic AI and non-human actors: hashicorp.com
The cost analysis: "Everyone wants SPIFFE, almost no one can afford to build it right"
SPIFFE + relationship-based authorisation for agents (2026 reference architecture): stacklok.com
Our scenario assessment: SPIFFE against the four-agents scenario

← Industry map Our SPIFFE assessment →