AI Agent Identity in 2026: WIMSE, SPIFFE, and OAuth
"Give your agents real identity, not API keys" is good advice you've probably already heard. The trouble is that "identity" hides two different questions, and most homegrown agent auth answers neither cleanly. A March 2026 IETF draft is the first to separate them properly — and its headline finding is that you don't need a new protocol for either. Below: the two questions, the standards that answer each (WIMSE and SPIFFE for one, OAuth for the other), what's deployed versus still a draft, and where NamoID sits in the stack as the OAuth authorization layer.
The draft is draft-klrc-aiagent-auth-00, "AI Agent Authentication and Authorization" (2 March 2026), from authors at Ping Identity, AWS, Zscaler, and Defakto. It's an early -00 Informational draft, so treat specifics as in-flux. But its framing is already the clearest map of this space, and its thesis is refreshingly boring: "rather than defining new protocols, this document describes how existing and widely deployed standards can be applied."
The two questions agent identity actually asks
Agent identity splits into two questions that need different answers. Who or what is this agent? — a stable, cryptographically provable identifier for the workload itself. What may it do, and on whose behalf? — the delegated authority to act for a specific user or system, in a specific context. The first is workload identity; the second is delegated authorization. Conflate them and you get the API-key mess.
The draft's central move is to keep these layers separate and assign each to the standard that already solves it. Workload identity goes to WIMSE and SPIFFE. Delegated authorization goes to OAuth 2.0. As the draft puts it: a credential proves the agent exists; an access token proves it has permission to act for someone right now. You need both, and they are not the same artifact.
Why API keys answer neither
A static API key fails both questions at once, which is exactly why it's the wrong primitive. The draft is blunt: "Static API keys are an antipattern for agent identity. They are bearer artifacts that are not cryptographically bound, do not convey identity, are typically long-lived and are operationally difficult to rotate."
Unpack that against the two questions. A key doesn't answer who — anyone holding the string is "the agent," with no cryptographic binding to a real workload. And it doesn't answer for whom — it carries no delegation context, so a key that can read one user's data can usually read everyone's. We made the broader case for retiring keys in identity for AI agents; the new framing is that you replace one key with two things, one per question.
Who the agent is: WIMSE and SPIFFE
The identity layer is owned by WIMSE, with SPIFFE as its deployed implementation. WIMSE (Workload Identity in Multi-System Environments, an IETF working group) defines the identifier model: every agent "MUST be assigned exactly one WIMSE identifier," a URI that names the workload within a trust domain.
SPIFFE (Secure Production Identity Framework for Everyone) is the mature, in-production realization of that model. An agent gets a SPIFFE ID like spiffe://trust-domain/payments/agent-42 and proves it with a SVID — a SPIFFE Verifiable Identity Document, issued as either a short-lived JWT (JWT-SVID) or an X.509 certificate (X.509-SVID), cryptographically bound to the workload's key and rotated automatically. That binding is the whole difference from an API key: the credential is short-lived, key-bound, and provisioned at runtime by the platform, not pasted into an env var.
This layer says nothing about permissions. A SPIFFE ID proves this is payments-agent-42. It does not say agent-42 may move your money. That's the next layer.
What it may do, and for whom: OAuth
Permission and delegation are OAuth's job, and the draft maps them onto two claims you already know. The agent presents its workload identity, runs an OAuth flow, and receives an access token that carries a dual identity: the agent as client_id, and the user or system it's acting for as sub. In the draft's words, "when the Agent is acting on-behalf of another User or System, the User or System identifier is conveyed in the sub claim."
That token is where the controls you care about live, and they're the same ones any careful OAuth deployment uses:
- Audience binding (RFC 8707 + RFC 9068) so a token minted for one server is rejected by every other — the foundation of securing an MCP server.
- Issuer identification (RFC 9207) so an agent talking to many servers can't be tricked into sending a code to the wrong one.
- Token exchange (RFC 8693) so when the agent must call a downstream API, it trades its token for a new one scoped to that destination instead of passing the original through — and the
actclaim records the delegation chain.
For the full OAuth-for-agents toolkit — PKCE, per-resource consent, refresh rotation, CIMD onboarding — see identity for AI agents and MCP's OAuth 2.1 profile.
The stack, layer by layer
The draft lays the pieces out as a stack, and it's the most useful single artifact in it. Identity sits at the bottom, authorization in the middle, governance on top — each layer a standard, each with a different maturity:
| Layer | Question it answers | Standard | Status |
|---|---|---|---|
| Identifier | Who is the agent? | WIMSE identifier | IETF draft |
| Credential | Prove it cryptographically | SPIFFE SVID (JWT / X.509) | Deployed |
| Authentication | Prove possession across hops | HTTP Message Signatures (RFC 9421), WIMSE proof tokens | RFC / draft |
| Authorization | What may it do, for whom? | OAuth 2.0 access token (RFC 9068) | Deployed |
| Delegation (downstream) | Act across services | OAuth token exchange (RFC 8693), transaction tokens | RFC / draft |
| Cross-domain | Chain across trust domains | OAuth identity chaining | Draft |
| Observability | Reconstruct what happened | Audit / event log | Deployment practice |
One line from the draft is worth pinning to the wall: "Observability is therefore a security control, not solely an operational feature." For an agent that acts autonomously, the audit trail isn't paperwork — it's how you answer "what did it do, and who authorized it" after the fact.
What's solved versus what's still a draft
Build on the deployed layers now; watch the rest. The two foundations — SPIFFE for workload identity and OAuth 2.0 for delegated authorization — are production-grade and won't move under you. The upper and cross-cutting pieces are genuinely early: WIMSE's own credential and proof-token formats, OAuth transaction tokens, and cross-domain identity chaining are all drafts, and the agent-auth draft explicitly marks policy and compliance as TODO.
The practical read: give your agents a real workload identity (SPIFFE) and route every action through audience-bound, delegated OAuth tokens today. Those decisions are safe. Treat transaction tokens and cross-domain chaining as a space to track, not a foundation to pour yet. The draft's whole point is that you can do the safe 80% with standards that already exist — and a fragmented zoo of bespoke "agent auth" SDKs is exactly what it's trying to head off.
FAQ
What is a SPIFFE ID?
A SPIFFE ID is a URI like spiffe://trust-domain/path that uniquely names a workload — including an AI agent — within a trust domain. The agent proves it holds that identity with a SVID: a short-lived, key-bound credential issued as a JWT or X.509 certificate, rotated automatically rather than configured by hand.
Do AI agents need OAuth if they already have a SPIFFE identity?
Yes — they answer different questions. A SPIFFE SVID proves who the agent is; an OAuth access token proves what it may do and on whose behalf. The agent uses its workload identity to obtain delegated OAuth tokens. You need both layers, which is the core point of draft-klrc-aiagent-auth-00.
Is there a standard for AI agent identity?
There's an emerging one. The IETF draft draft-klrc-aiagent-auth-00 (March 2026) composes existing standards — WIMSE and SPIFFE for identity, OAuth 2.0 for authorization — rather than inventing a new protocol. It's an early Informational draft, so expect change, but the two-layer model it describes is built from production-grade parts.
What replaces API keys for AI agents?
Two things, one per question. A cryptographically bound workload identity (a SPIFFE SVID) replaces the key as proof of who the agent is, and a delegated, audience-bound OAuth access token replaces it as proof of what the agent may do for a specific user. Both are short-lived and revocable, unlike a static key.
Where NamoID fits
NamoID is the OAuth 2.1 authorization layer of this stack — the half that answers "what may this agent do, and for whom." It issues audience-bound access tokens (RFC 8707 + RFC 9068) that carry the agent as client_id and the delegated user as sub, defends multi-server agents against mix-up attacks with the RFC 9207 iss parameter, enforces PKCE on every flow, and onboards agents via Client ID Metadata Documents — no static keys anywhere. Pair it with a SPIFFE/WIMSE identity layer and you've got both questions answered. Want to see the agent flow end to end before launch? Book 30 minutes at calendly.com/polymindslabs/30min or reach us at hello@namoid.in.