AI Agent Identity Explained: SPIFFE, SPIRE and OPA Instead of API Keys

Many AI agents still run on a static API key: long-lived, and hard to rotate.

It's a bearer secret, not bound to anything. Whoever copies it can act as your agent.

The fix is a passport that expires within the hour.

SPIFFE, SPIRE, SVIDs, OPA, Rego. Alphabet soup. One airport analogy makes it click, plus why a perfect ID won't stop your agent wiping a database.

Two questions: who are you, and may you board?

An airport asks two questions: who are you, and may you board?

SPIFFE and SPIRE issue the passport that answers the first. OPA runs the gate.

SPIFFE is the standard. SPIRE implements it; meshes like Istio issue SPIFFE IDs too.

The SPIFFE ID: the name in the passport

Your agent's name is a SPIFFE ID:

spiffe://example.org/agents/billing
         └─────────┘└─────────────┘
         trust domain     path

First, the trust domain: the trust root, like the country that issues a passport. Then the path, naming this workload.

The SVID: the passport

So what makes a name proof? A signature.

Signed, it becomes an SVID: a SPIFFE Verifiable Identity Document. It comes in two forms:

SVID type	Used for	Lifetime in the video
X.509 certificate	mTLS	1 hour
JWT	bearer token	5 minutes

A JWT-SVID looks like any other JWT:

eyJhbGciOiJFUzI1NiJ9.eyJzdWIiOiJzcGlmZmU6Ly9....MEUCIQDx3k...

Prefer the certificate: its private key never leaves the agent. Stolen JWTs replay until expiry.

SPIRE and secret zero: the passport office

But how does the agent get a passport without a password?

You'd need a secret to get a secret: secret zero. SPIRE solves it in two steps.

The SPIRE Server is the passport office. The SPIRE Agent is a desk on every node. Careful: that's not your AI agent.

Step one: the node proves itself with platform evidence, like a cloud instance document.

Workload attestation: the fingerprint check

Step two: your AI agent asks its local desk for a passport. No credentials.

The desk asks the kernel who's calling, then looks up that process: its container, its service account. Those are its selectors:

k8s:ns:agents
k8s:container-image:…/billing-agent
k8s:sa:billing-agent

Those selectors match an entry you registered, like a fingerprint on file, and the SVID streams back. The entry is something you create up front:

spire-server entry create \
    -parentID spiffe://example.org/spire/agent/k8s_psat/demo-cluster/node-1 \
    -spiffeID spiffe://example.org/agents/billing \
    -selector k8s:ns:agents -selector k8s:sa:billing-agent

Unlike a real passport, it's short-lived and auto-rotates before it expires.

mTLS: passport control in both directions

Now the agent calls a tool, a payments API, over mutual TLS (mTLS).

Each side checks the other's stamp against its trust bundle: passport control, in both directions.

No API key anywhere, at least for internal calls. So you're safe, right?

The catch: identity isn't permission

A prompt injection tells the billing agent to clean up. It sends this:

DELETE /customers HTTP/1.1

HTTP/1.1 200 OK

And the tool happily replies: 200 OK.

SPIFFE proved who called. Deciding what it may do was never SPIFFE's job.

OPA: the gate

That's the gate's job. A popular one: OPA, the Open Policy Agent.

OPA checks the request against a Rego policy. Billing may read invoices. DELETE? Denied.

default allow := false

allow if {
  input.principal == "spiffe://example.org/agents/billing"
  input.method == "GET"
  startswith(input.path, "/invoices")
}

default allow := false is the important line: anything not explicitly allowed is denied. OPA returns the decision. Envoy enforces it, usually with a 403 Forbidden.

The twist: agents act for humans

Agents usually act for a human, so the gate also checks a signed permission slip.

The IETF's September 2026 AI-agent draft splits it the same way: SPIFFE-style IDs for agents, OAuth token exchange for users. Policy? Out of scope: that's a job for OPA.

Recap

Airport	Real thing
the name in the passport	SPIFFE ID
the passport	SVID
the passport office	SPIRE Server
a desk on every node	SPIRE Agent
the fingerprint check	attestation
passport control, both ways	mTLS + trust bundle
the gate, on every single call	OPA + Rego

Your agent never needed a forever key. It needed a passport, and a gate that denies by default.

What does your agent use: API key, OAuth, or SPIFFE? Tell me in the comments.

More in this series: AI agent sandboxing, Pi 1.0 and Pi Durable, AI reverse engineering.

---

This is the written version of a 4-minute animated explainer on RuntimeStack. Sources: SPIFFE ID spec, X509-SVID spec, JWT-SVID spec, SPIFFE Workload API, SPIRE concepts, SPIRE Server, CNCF: SPIFFE and SPIRE graduate, Istio security, OPA docs, OPA-Envoy, Rego, Envoy attribute context, IETF WIMSE AIMS draft, IETF AI agent auth draft, Red Hat: zero-trust identity for AI agents, OWASP LLM01 Prompt Injection.