AI agent identity standards: the 2026 landscape

Why "agent identity" is not one problem

The phrase "AI agent identity" collapses at least four distinct questions that different standards answer separately:

1. What is this thing? A stable, verifiable identifier for the agent as a running workload, independent of any user.
2. Who is it acting for? The delegation chain binding an agent action back to a human principal and a specific consent.
3. Is it allowed to do this, right now? An authorization decision evaluated at the moment of the call, not at token issuance.
4. Can we stop it mid-flight? Revocation that takes effect faster than the agent can act.

Classical enterprise identity answers (1) and (2) well for humans and (1) reasonably for workloads. It answers (3) statically and (4) badly. Agents break the last two because the interval between authorization and consequential action collapses from minutes to milliseconds, and because a single user request can fan out into hundreds of downstream calls across trust boundaries.

The six layers of the emerging agent identity stack

Layer 1. Workload identity: what the agent is

An AI agent is, architecturally, a workload. It runs somewhere, it needs a credential, and that credential should be short-lived and attested rather than a static key in an environment variable. This is the problem SPIFFE/SPIRE has solved in production for years and that the IETF's WIMSE working group is now formalising.

WIMSE has split into a family of documents rather than a single specification: an architecture document, a canonical Workload Identifier URI format, Workload Credentials (certificate and JWT-based), the Workload Proof Token for request-bound proof of possession, and an informational survey of existing workload identity practices. All are standards-track or informational drafts as of mid-2026; none is an RFC.

What this means for you: if you are issuing agents static API keys today, the migration path is not "wait for WIMSE." It is "adopt SPIFFE-shaped workload identity now, because WIMSE is being designed to be reachable from there."

Layer 2. Delegation: who the agent acts for

An agent that books travel on your behalf must be distinguishable from an agent that booked travel claiming to be you. The dominant pattern in 2026 gives the agent its own standing identity and issues per-invocation delegation tokens carrying the user-authority context separately, so that an action is attributable to both the agent and the delegating human, scoped to what that human actually consented to for that invocation.

The building blocks are all existing OAuth machinery: OAuth 2.1 with PKCE for the consent leg, OAuth 2.0 Token Exchange (RFC 8693) for converting a broad credential into a narrow downstream one, and the On-Behalf-Of pattern for propagating delegation. CIBA (Client Initiated Backchannel Authentication) is being used for the case where an agent must interrupt and ask a human to approve a specific operation out of band.

Layer 3. Proof of possession: binding the credential to the caller

Bearer tokens are stealable, and agent architectures multiply the places a token can leak: prompt context, tool outputs, logs, memory stores, inter-agent messages. Proof-of-possession binds a token to a key the holder must demonstrate control of. DPoP (RFC 9449) covers the OAuth case; WIMSE's Workload Proof Token covers workload-to-workload HTTP, binding authentication to a specific request via audience and token-hash claims.

This layer is the most under-implemented and the one most likely to matter after the first major agent-token-theft incident.

Layer 4. Authorization: the decision at the moment of the call

AuthZEN, from the OpenID Foundation, standardises only the interface between a Policy Enforcement Point and a Policy Decision Point. It is deliberately not a policy language and does not dictate how the decision point sources information. That scope discipline is why it is likely to survive: it is substitutable underneath.

The significance for agents is architectural. Static, long-lived scopes are the wrong primitive when an agent's context changes between one tool call and the next. Externalising the decision means the answer to "may this agent do this" can change without reissuing a credential.

Layer 5. Revocation: stopping an agent faster than it acts

Token expiry is not revocation. A fifteen-minute token is a fifteen-minute window in which a compromised agent operates with full authority, and an agent executes a great many actions in fifteen minutes. The Shared Signals Framework and CAEP (Continuous Access Evaluation Profile) carry security events between parties so a decision point can react to session revocation, credential compromise, or risk-level change in near real time.

If you take one architectural commitment from this page, take this one: design the kill path before you design the grant path. Most agent deployments we see have a well-specified provisioning flow and no tested revocation flow at all.

Layer 6. Propagation: carrying authority across the call chain

Transaction Tokens (TraTs), an IETF OAuth working group draft, address what happens when a request crosses many internal services: the original authorization context is preserved and cryptographically carried rather than being re-derived or trusted implicitly at each hop. For multi-agent systems where one agent invokes another which invokes a tool, this is the layer that makes end-to-end attribution possible.

What to track, and what it actually means

Where this goes in five years

This section is analysis, not fact. We label our confidence explicitly.

• Composition wins over a unified "agent identity" standard. Confidence: high. The economics favour reusing deployed OAuth and PKI infrastructure. The klrc draft's framing is already the consensus position among the vendors doing the work.
• Agent registries become a governance requirement. Confidence: moderate-high. Agent impersonation is named as a distinct threat class in CSA's MAESTRO threat model, and the prescribed mitigations (trusted registries, cryptographic identities, short-lived credentials) are the same three controls that keep appearing independently.
• Authorization overtakes authentication as the hard problem. Confidence: high. Proving what an agent is is nearly solved. Deciding what it may do, per call, with fresh context, is not.
• Credential lifetimes collapse toward minutes. Confidence: high. The same forcing function reshaping TLS. See 47-day certificates and crypto-agility. Applies harder to agents.
• Audit evidence becomes the procurement differentiator. Confidence: moderate. Regulators and auditors will ask organisations to demonstrate which agent did what under whose authority. Systems that cannot reconstruct a delegation chain will fail that question regardless of how well they authenticate.

What to do now, before any of this ratifies

1. Inventory your agents as identities, not as applications. If an agent does not appear in your NHI inventory with an owner and an expiry, nothing downstream works.
2. Eliminate credential borrowing. No agent should hold a human's credential. This is a policy decision available to you today with no dependency on any standard.
3. Give every agent a distinct, attested, short-lived workload credential. SPIFFE-shaped today, WIMSE-shaped later.
4. Separate the agent's identity from the delegation. Two facts, two tokens, both logged.
5. Externalise authorization decisions. Even a crude PDP is more substitutable than scopes hard-coded into token issuance.
6. Build and test the kill path. Measure the time from "revoke" to "agent cannot act." If you have not measured it, you do not know it.
7. Log the delegation chain, not just the caller. This is what an auditor will ask for, and it is very hard to retrofit.

Every item on that list is achievable now and none of it becomes wasted work if a different draft wins.

Frequently asked questions

Is there an official AI agent identity standard?

No. As of August 2026 there is no ratified standard for AI agent identity. The most significant effort is draft-klrc-aiagent-auth at the IETF, which is an individual Internet-Draft with no formal IETF standing, and its own position is that agents need no new protocols, only the correct composition of WIMSE and the OAuth 2.0 family. Anyone marketing compliance with an 'agent identity standard' should be asked which document they mean and what its status is.

Should AI agents have their own identity or use the user's identity?

Their own. The pattern that has converged across the standards work is that the agent holds a standing workload identity of its own, and user authority is carried separately as a per-invocation delegation token. Letting an agent hold a human's credential destroys attribution permanently, because downstream logs cannot distinguish agent action from human action after the fact.

What is the difference between WIMSE and SPIFFE?

SPIFFE is a production system with a mature open-source implementation, SPIRE, that many organisations run today. WIMSE is the IETF working group formalising workload identity as a standards-track protocol family. They are complementary rather than competing: SPIFFE is what you deploy now, WIMSE is what interoperability will eventually be specified against. Adopting SPIFFE-shaped workload identity is the practical migration path.

How does MCP handle authorization?

The Model Context Protocol specification mandates OAuth 2.1 with PKCE for protected HTTP-based deployments, requiring HTTPS on all endpoints and discoverable authorization server metadata. MCP was contributed to the Agentic AI Foundation under the Linux Foundation in December 2025, which means its governance no longer sits with a single vendor. See our page on MCP security for the threat detail.

Why is revocation harder for agents than for humans?

Because of the ratio between token lifetime and consequential action. A human with a fifteen-minute token performs a handful of operations in that window. An agent can perform thousands. Token expiry is therefore not an adequate substitute for revocation, and this is what the Shared Signals Framework and CAEP are designed to address by carrying security events to decision points in near real time.

Which of these standards should we build against today?

None exclusively. The defensible architecture is one where the credential format, the policy decision point, and the signal transport are each substitutable. The seven actions in the section above are all achievable now and none of them is invalidated regardless of which draft eventually ratifies.