--- title: Secure Production Identity Framework for Everyone (SPIFFE) in the AuthPlayground description: Explore how SPIFFE gives AI agents and other workloads verifiable identities in the AuthPlayground. component: identity-for-ai page_id: identity-for-ai:protocols:authplayground-spiffe canonical_url: https://developer.pingidentity.com/identity-for-ai/protocols/authplayground-spiffe.html llms_txt: https://developer.pingidentity.com/identity-for-ai/llms.txt docs_for_agents: https://developer.pingidentity.com/build-with-ai/docs-for-agents.md revdate: 2026-08-24T07:38:08Z keywords: ["Identity for AI", "OAuth 2.0 protocols", "OpenID Connect", "SPIFFE", "SVID", "JWT-SVID", "workload identity", "autonomous AI", "non-human identity", "NHI", "SPIRE", "AuthPlayground"] section_ids: the-spiffe-model: The SPIFFE model static-credentials-are-a-poor-fit: Static credentials are a poor fit spiffe-ids-and-svids: SPIFFE IDs and SVIDs the-authplayground-implementation: The AuthPlayground implementation step-1-fetch-a-jwt-svid: "Step 1: Fetch a JWT-SVID" step-2-load-the-jwt-trust-bundle: "Step 2: Load the JWT trust bundle" step-3-authenticate-to-the-resource-server: "Step 3: Authenticate to the resource server" applying-this-to-an-ai-agent: Applying this to an AI agent how-spiffe-relates-to-other-concepts: How SPIFFE relates to other concepts identity-and-authorization-are-different: Identity and authorization are different human-identity-isnt-required: Human identity isn't required when-human-delegation-matters: When human delegation matters where-the-idp-fits-in: Where the IdP fits in bridging-spiffe-into-oauth: Bridging SPIFFE into OAuth key-takeaways: Key takeaways --- # Secure Production Identity Framework for Everyone (SPIFFE) in the AuthPlayground Identity for workloads running enterprise AI. Enterprise AI is increasingly made up of software talking to software. A typical AI platform might contain an orchestrator, planner agents, retrieval agents, policy services, MCP gateways, and other internal services. For example, a request might flow through the following components: * **AI orchestrator**: Directs the overall flow and calls the planner agent. * **Planner agent**: Decides what work needs to happen and delegates to other agents. * **Retrieval agent**: Gathers information needed by another agent or application. * **Policy service**: Evaluates decisions. * **MCP gateway**: Provides controlled connectivity between AI workloads and tools or APIs. These workloads can operate autonomously. They call each other and perform work without a human participating in every interaction. For one workload to trust another, they need a way to verify the identity of the caller. This is the problem [SPIFFE](https://spiffe.io/docs/latest/spiffe-specs/spiffe/) is designed to address. ## The SPIFFE model A workload is software performing work. AI agents, MCP gateways, microservices, and other running processes are non-human identities (NHI). They don't need to represent a human to have an identity. ### Static credentials are a poor fit Imagine the enterprise runs its AI platform on a Kubernetes cluster with these workloads: ``` Kubernetes Cluster ├── planner-agent-7d9f8 ├── planner-agent-3b2c1 ├── retrieval-agent-82ad4 ├── mcp-gateway-5e921 └── policy-service-91ba3 ``` These workloads can scale, restart, move between nodes, or exist briefly. Giving them long-lived API keys or shared secrets creates a weak relationship between the credential and the actual workload. A shared secret tells us that a caller knows the secret. It doesn't tell us that it's the workload the system intended to trust. Network location isn't enough either. Knowing a call comes from inside the Kubernetes cluster isn't the same as knowing it's the legitimate retrieval workload. SPIFFE provides a standardized identity model for workloads. ### SPIFFE IDs and SVIDs SPIFFE identifies a workload using a SPIFFE ID. A SPIFFE ID looks like a URI: ``` spiffe://bxcompany.internal/agents/planner spiffe://bxcompany.internal/agents/retrieval spiffe://bxcompany.internal/gateways/mcp ``` * The first part of the ID identifies the SPIFFE trust domain: `spiffe://bxcompany.internal`. * The remainder identifies the workload within that domain: `/agents/retrieval`. The workload proves its SPIFFE identity using a SPIFFE Verifiable Identity Document (SVID). SPIFFE supports different SVID forms. The playground demonstrates a JWT-SVID. To summarize the flow: 1. The running workload requests a verifiable identity from the SPIFFE Workload API. 2. The SPIFFE Workload API issues a JWT-SVID that serves as the verifiable workload identity. SPIRE is an implementation of SPIFFE that can perform workload attestation and issue SVIDs. The workload doesn't simply claim whatever identity it wants. The SPIFFE implementation determines which identities the workload is entitled to receive. ## The AuthPlayground implementation **Entities involved**: Client application, SPIFFE / SPIRE, resource server The AuthPlayground demonstrates the [SPIFFE / SVID Workload Identity](https://www.authplayground.dev/flows/spiffe) flow in three steps: 1. Fetch a JWT-SVID. 2. Load the JWT trust bundle. 3. Authenticate to the resource server. | | | | - | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | The playground exposes HTTP endpoints that model SPIFFE Workload API operations, making the flow easy to execute and inspect in a browser. The SPIFFE standard doesn't define `POST /spiffe/fetch-jwt-svid` as an HTTP API. The Workload API uses protocol buffers and RPCs, including the `FetchJWTSVID` operation. The playground HTTP calls are an interactive representation of SPIFFE operations, not the standardized transport. | ### Step 1: Fetch a JWT-SVID The workload asks the SPIFFE Workload API for a JWT-SVID. The request looks like this: ```json POST /spiffe/fetch-jwt-svid Content-Type: application/json { "audience": [ "https://.../rs" ] } ``` Notice that the workload supplies the audience it intends to authenticate to. It doesn't supply a requested `spiffe_id`. The SPIFFE Workload API determines which SPIFFE identities the workload is entitled to receive. This is an important part of the trust model. The playground returns a JWT-SVID for the workload's SPIFFE ID: ```json { "jwt_svids": [ { "spiffe_id": "spiffe://example.org/workload/demo-service", "jwt_svid": "", "hint": "demo-workload", "expires_at": 1787450000 } ] } ``` The decoded JWT-SVID contains the following claims: ```json { "sub": "spiffe://example.org/workload/demo-service", "iat": 1786578067, "exp": 1786581667, "aud": [ "https://.../rs" ], "jti": "25bfe3f5-6348-4c52-a444-69eb31fa1fdb" } ``` * `sub`: The workload's SPIFFE ID. * `aud`: Identifies the audience for which this JWT-SVID was requested. * `exp`: Keeps the credential time-bounded. The SPIFFE Workload API specification defines JWT-SVID retrieval in an audience-oriented way. The workload requests JWT-SVIDs for a specific audience and receives SVIDs for identities that it's authorized to use. ### Step 2: Load the JWT trust bundle The resource server needs a way to verify JWT-SVIDs issued by the SPIFFE trust domain. The playground models that as a separate verifier action: ```json GET /spiffe/fetch-jwt-bundles Accept: application/json ``` The response contains a bundle keyed by trust domain: ```json { "bundles": { "spiffe://example.org": { "keys": [ { "kty": "RSA", "kid": "spiffe-signing-key-1", "use": "jwt-svid", "alg": "RS256" } ] } } } ``` The resource server can use this verification material to validate JWT-SVIDs from `spiffe://example.org`. To summarize the relationships: * **SPIFFE trust domain**: Derives the JWT trust bundle. * **JWT trust bundle**: Provides verification material. * **Resource server**: Uses the bundle to verify the JWT-SVID. This step doesn't have to occur for every individual API request. A verifier can load or refresh the bundle independently while validating JWT-SVIDs. The SPIFFE specification requires JWT bundles to be keyed by trust domain, and the verifier uses the bundle corresponding to the trust domain in the JWT-SVID subject. If it doesn't have a matching trusted bundle, the credential isn't trusted. ### Step 3: Authenticate to the resource server The workload presents its JWT-SVID to the resource server: ```json GET /rs/api/data Authorization: Bearer ``` The resource server validates the JWT-SVID. Among other things, it can check: * **Signature**: Was this JWT-SVID signed by the trusted SPIFFE domain? * **SPIFFE ID**: Which workload is presenting it? * **Audience**: Was this JWT-SVID issued for this resource server? * **Expiration**: Is the credential still valid? The playground response confirms that access is granted: ```json { "message": "Access granted to protected resource", "user": "spiffe://example.org/workload/demo-service", "authorization_details": null, "token_type": "Bearer" } ``` There's no human user in this flow. The identity recognized by the resource server is `spiffe://example.org/workload/demo-service`. The software workload authenticated as itself. #### Applying this to an AI agent Replace the playground's generic `demo-service` with a real AI workload. Suppose the enterprise has a retrieval agent whose job is to gather customer context for other agents. The agent's SPIFFE ID is `spiffe://company.internal/agents/retrieval`. The flow looks like this: 1. The retrieval agent fetches a JWT-SVID from SPIFFE / SPIRE. 2. The retrieval agent authenticates as itself to the customer context service using the JWT-SVID. 3. The customer context service validates the SVID and establishes which workload is calling it. The service doesn't have to trust the request just because it came from inside the network. Policy can decide whether the workload is allowed to perform the requested operation. ## How SPIFFE relates to other concepts ### Identity and authorization are different A valid SPIFFE identity doesn't mean the workload can do anything it wants. SPIFFE / SVID defines which workload is making the request. Authorization policy defines what the workload is allowed to do. These are separate decisions. The playground demonstrates successful authentication to the resource server with a JWT-SVID. A production architecture can layer whatever authorization policy is appropriate on top of the authenticated workload identity. ### Human identity isn't required SPIFFE is particularly important for autonomous AI. Consider a monitoring agent reading platform telemetry. The monitoring agent might run continuously and inspect platform telemetry under its own machine authority. An employee doesn't have to initiate each request. The same applies to policy agents, maintenance services, background AI processes, and many agent-to-agent interactions. ### When human delegation matters Consider Sarah asking the AI assistant to prepare her for a meeting. The AI platform might use several workloads to complete this task, such as a planner agent, a retrieval agent, and an MCP gateway. SPIFFE can establish the identities of the participating software workloads, but not every interaction represents delegation from Sarah. The planner might call the retrieval agent under machine authority. Delegation becomes relevant only when an authorization decision depends on Sarah's identity or authority. The architecture might need to know: * Who is the software? SPIFFE / SVID confirms this is the legitimate MCP workload. * Whose authority is involved? Delegated identity confirms that this operation involves Sarah's authority. Delegation can be added when required, but isn't a prerequisite for workload identity. ### Where the IdP fits in The SPIFFE playground flow doesn't involve an IdP. The SPIFFE identity system establishes the workload identity, and the resource server validates it using the SPIFFE trust bundle. An enterprise IdP isn't required for this interaction. For human identity, the flow looks different: 1. Sarah authenticates via the IdP. 2. The IdP uses OIDC / OAuth to provide human identity and authorization context. These are separate identity planes that operate independently: * **IdP**: Who is the human? * **SPIFFE / SPIRE**: Which workload is running? ### Bridging SPIFFE into OAuth There are architectures where these worlds need to connect. Many enterprise APIs expect OAuth access tokens rather than accepting JWT-SVIDs directly. One integration pattern is to use a JWT-SVID as trusted workload context when requesting an OAuth token. The flow might look like this: 1. The running workload obtains a JWT-SVID from SPIFFE / SPIRE. 2. The workload presents the JWT-SVID to the enterprise authorization server for token exchange. 3. The enterprise authorization server validates the workload identity, applies enterprise policy, and issues an OAuth access token. 4. The enterprise API accepts the OAuth access token. The responsibilities remain separate: SPIFFE establishes which workload it is, and the enterprise authorization server determines what the workload is allowed to do. The resulting OAuth token can preserve workload-related information, such as the SPIFFE ID, that's useful for downstream policy and auditing. This is an integration pattern, not a requirement of SPIFFE. It isn't part of the playground demonstration. ## Key takeaways Autonomous agents, MCP gateways, microservices, and other software components need identities of their own. SPIFFE provides a standard way to give workloads verifiable identities without requiring them to impersonate humans or rely on long-lived shared credentials. Human identity and delegation can be added when a business operation requires them.