Who’s on FirstChoose a flow

Flows / No human

SPIFFE identities and mutual TLS

Every agent process gets a cryptographic identity from the infrastructure it runs on, and uses it to authenticate both ends of every connection.

Based onSPIFFE specificationsFinal specGuide reviewedNovember 2026

Sources and review details
This page
Implementation guideAn explanation, not a specification
Primary specification
SPIFFEFinal spec · CNCF graduated project
2 required references
1 published, 1 project3 more listed as optional or background
Human involvement
No human
Review
Checked against sources in November 2026How it was checked

SPIFFE is a set of open specifications for giving software an identity without giving it a secret. Each workload gets a name, a SPIFFE ID such as spiffe://example.org/ns/agents/sa/research-agent, and a short-lived credential that proves the name: an X.509 certificate or a JWT, called an SVID.

The workload does not log in to get it. It asks a local agent over a Unix socket, and the local agent works out who is asking by inspecting the calling process: which pod, which service account, which container image. Identity is derived from what the workload is, checked by something outside it.

For agent systems this gives you a per-workload identity that works the same across clusters and clouds, authenticates both sides of a connection, and rotates without anyone noticing. Service meshes use the same identities under the hood.

Step by step

8 steps between 4 parties. Each step shows the message and who holds which credential afterward. Use ←→ or select any arrow.

Sequence diagram4 participants, 8 steps
  • Direct call
  • Response
  • Local action

Drag to see every party and step. Tap a step to jump to its explanation.

1Node attestation2Registrationentries3Workload API:fetch SVID4Attest the calling process5X.509-SVID +trust bundle6mTLS handshake7Authorize the SPIFFE ID8Response over mTLS

  1. 1SPIRE agentSPIRE serverDirect call

    The node proves what it is

    Before any workload gets an identity, the SPIRE agent on each node proves its own to the SPIRE server, using evidence the platform provides: on Kubernetes a projected service account token, on a cloud VM a signed instance identity document.

  2. 2SPIRE serverSPIRE agentResponse

    The server tells the node which identities it may issue

    Registration entries map selectors to SPIFFE IDs: “a pod in namespace agents with service account research-agent is spiffe://example.org/ns/agents/sa/research-agent.”

    Who holds what after this step

    SPIRE agent
    newnode SVID

    Parties not listed hold none of this flow’s credentials at this point.

  3. 3AI agentSPIRE agentDirect call

    The agent asks for its identity, presenting nothing

    The agent connects to the Workload API on a local Unix domain socket. It sends no password, token or key. This is the answer to the bootstrap problem: how do you authenticate a workload that has no credential yet?

    Who holds what after this step

    SPIRE agent
    node SVID

    Parties not listed hold none of this flow’s credentials at this point.

  4. 4SPIRE agentLocal action

    The node agent identifies the caller

    From the socket it learns the caller’s process ID. From the kernel and the kubelet it learns which container and pod that process belongs to, its service account, labels and image. It matches those facts against the registration entries.

    Who holds what after this step

    SPIRE agent
    node SVID

    Parties not listed hold none of this flow’s credentials at this point.

  5. 5SPIRE agentAI agentResponse

    The agent receives a short-lived certificate

    The certificate carries the SPIFFE ID in its URI subject alternative name. It typically lives for an hour or less and is pushed again over the same stream before it expires. The trust bundle is the set of CA certificates for verifying peers.

    Subject Alternative Name:
  URI: spiffe://example.org/ns/agents/sa/research-agent
Validity:
  Not After: +1h

    Who holds what after this step

    SPIRE agent
    node SVID
    AI agent
    newX.509-SVID + key

    Parties not listed hold none of this flow’s credentials at this point.

  6. 6AI agentTool serviceDirect call

    Both sides present certificates

    The agent presents its SVID as a client certificate. The tool service presents its own. Each verifies the other against the trust bundle. The connection is authenticated in both directions before any application data flows.

    Who holds what after this step

    SPIRE agent
    node SVID
    AI agent
    X.509-SVID + key
    Tool service
    newX.509-SVID + key

    Parties not listed hold none of this flow’s credentials at this point.

  7. 7Tool serviceLocal action

    The tool applies policy to the caller’s identity

    The tool, or a sidecar or mesh proxy in front of it, reads the peer’s SPIFFE ID and decides whether that identity may call this endpoint.

    allow:
  - from: spiffe://example.org/ns/agents/sa/research-agent
    to:   [ "POST /tools/search", "POST /tools/summarize" ]

    Who holds what after this step

    SPIRE agent
    node SVID
    AI agent
    X.509-SVID + key
    Tool service
    X.509-SVID + key

    Parties not listed hold none of this flow’s credentials at this point.

  8. 8Tool serviceAI agentResponse

    The call proceeds

    If the call is on behalf of a user, the request carries an access token as well. Workload identity for the hop, user delegation for the request: the two layers answer different questions and are stronger together.

    Who holds what after this step

    SPIRE agent
    node SVID
    AI agent
    X.509-SVID + key
    Tool service
    X.509-SVID + key

    Parties not listed hold none of this flow’s credentials at this point.

Watch out for

  • SPIFFE says who a workload is. It says nothing about which user the workload is acting for. For that you still need a token carrying the user’s delegation, alongside the workload identity.
  • Authentication is not authorization. Mutual TLS with no policy means every workload in the trust domain can call every other.
  • Registration entries decide which workloads get which IDs. Loose selectors (a whole namespace) hand the same identity to things that should differ.
  • An LLM agent that spawns sub-agents in one process shares one SVID among them. Workload identity stops at the process boundary.

JWT-SVIDs

When a load balancer or gateway terminates TLS, the certificate does not reach the application. SPIFFE also issues JWT-SVIDs: signed tokens with the SPIFFE ID as subject and a specific audience, sent in a header. They are bearer tokens, so keep them short-lived and audience-bound. The IETF WIMSE work adds proof-of-possession for this case; see workload tokens.

Standards in play

See the full tracker for status and links.

Required

What the flow implements, shows in a step, or must support. These decide its maturity rating.

Final specSPIFFE specifications

SPIFFE

The de facto workload identifier reused by the IETF agent architecture draft, cloud agent-identity products and agent gateways.

Project / platformSPIRE 1.16

SPIRE

The usual way to run SPIFFE yourself, on Kubernetes or elsewhere.

Optional extensions

Variants and additions the page mentions. No step depends on them, and the flow does not require them.

WG draftdraft-ietf-oauth-spiffe-client-auth

SPIFFE Client Authentication

Secretless OAuth client authentication for agents that already have a workload identity.

Background

Related reading. Not what the flow implements, and not used in a step.

WG draftdraft-ietf-wimse-arch

WIMSE Architecture

Includes a section on agents: each hop in an agent chain must explicitly scope and re-bind the security context.

Workload identity federation

Your agent uses an identity established by its runtime to obtain short-lived access from a system that trusts that identity.

No humanStable standards

Workload tokens (WIMSE)

A workload identity that is bound to a key and proven on every request, so it survives the gateways and proxies that agent traffic passes through.

No humanEmerging

Transaction tokens

Inside your own infrastructure, replace the access token with a short-lived token that pins down one transaction and travels the whole call chain.

With or without a humanEmerging

Client credentials

The agent authenticates as itself. No user, no consent screen, no one to ask.

No humanStable standards