AIMS: The IETF Finally Draws the Blueprint for AI Agent Identity

For the past two years, the industry has answered the agent identity question by inventing. New protocols, new token formats, new "agent passports," new vendor-specific trust schemes, each announced as if nobody had ever authenticated a workload before. Most of them reinvent mechanisms the identity community standardized, deployed, and hardened over the last decade. The result has been fragmentation, duplicated effort, and a growing pile of implementations that won't interoperate.

The IETF WIMSE working group has now pushed back, and the pushback deserves attention. On September 15, the group adopted the AI Identity Management System (AIMS) draft, draft-ietf-wimse-aims-00, as a working group document. It replaces the earlier individual draft on AI agent authentication and authorization. The author list alone tells you where the industry center of gravity is: Pieter Kasselman (Defakto Security), Jean-François Lombardo (AWS), Yaroslav Rosomakho (Zscaler), Brian Campbell (Ping Identity), Nick Steele (OpenAI), and Aaron Parecki (Okta).

The thesis of AIMS is simple and overdue: agents are workloads.

We don't need a new identity stack for them. We need to compose the standards we already have, correctly, and be honest about the gaps that remain.

What AIMS is, and what it isn't

AIMS is an informational best-practices framework. It defines no new protocol and no wire format. It describes how existing and emerging specifications from the IETF, CNCF, and OpenID Foundation fit together to solve agent authentication and authorization. It also calls out where new work is actually needed.

The draft is explicit that AIMS is a conceptual model, not a product. It's the set of functions required to establish, maintain, and evaluate an agent's identity and permissions. Those functions can live in one system or be spread across identity providers, provisioning services, authorization servers, policy engines, and enforcement points. That matters for anyone evaluating vendors who will inevitably start marketing "AIMS-compliant" platforms. AIMS is an architecture you implement, not a SKU you buy.

The model is a layered stack, with each layer depending on the guarantees below it:

Anyone who has built a federal ICAM program will recognize the shape immediately. It's the same discipline we apply to human identity, adjusted for an entity that spins up in milliseconds, calls tools nobody planned for, and can be manipulated through its own inputs.

The foundation: one identity, cryptographically bound, never static

One identifier per agent. AIMS requires every agent to have exactly one WIMSE identifier, a URI that uniquely identifies the workload within a trust domain. A SPIFFE ID is the operationally mature instance of that model. Authorization, delegation, and audit all depend on that identifier staying stable for the life of the workload identity.

Credentials that prove control of that identifier. An identifier alone proves nothing. AIMS requires a cryptographic binding between the agent and its identifier. The draft maps the credential landscape cleanly: WIMSE Workload Identity Tokens (WITs), X.509 Workload Identity Certificates, and the SPIFFE X.509-SVID, WIT-SVID, and JWT-SVID formats. Credentials should be short-lived and must carry an explicit expiration. Hardware-backed key protection through TPMs or secure enclaves is encouraged where available.

Then comes the line every security team should put on a poster:

Static API keys are an antipattern for agent identity.

The draft states it flatly. API keys are bearer artifacts. They aren't cryptographically bound, they don't convey identity, they tend to live forever, and they're painful to rotate. If your agent platform runs on API keys pasted into environment variables, AIMS says you are doing it wrong.

Provisioning as the posture gate. AIMS treats credential issuance as the point where you decide whether an agent deserves an identity at all. Posture signals about the agent's software, runtime, supply-chain provenance, placement, and configuration can determine whether a credential is issued and which identifier it binds to. They can also shape its attributes and its lifetime. Continuous short-lived rotation then stands in for explicit revocation, so authorization state keeps reflecting current conditions.

And one requirement belongs in every agent architecture review:

The LLM must not have access to the agent's credentials, or to credentials for the tools it uses.

The model is the component most exposed to prompt injection. Anything it can see, an attacker can talk it into disclosing. Credentials belong to the workload runtime, never the context window.

Authentication: pick the right layer for the topology

AIMS follows the WIMSE architecture and recognizes both transport-layer and application-layer authentication. mTLS with short-lived SPIFFE or WIMSE certificates is the right answer inside a service mesh. But the draft is candid about where mTLS breaks down. Proxies, API gateways, load balancers, serverless platforms, and cross-domain hops all terminate TLS and sever transport identity from the application request.

For those topologies, AIMS points to two application-layer mechanisms.

• WIMSE Workload Proof Tokens (WPTs)

  Signed JWTs, generated with the key behind the agent's WIT, that bind authentication to a specific message. WPTs can also carry hashes of related tokens, including a Transaction Token, which ties the agent's proof of possession to the exact transaction it's executing.

• HTTP Message Signatures

  Under the WIMSE profile. It signs the method, target, content digest, and the WIT itself, so integrity survives intermediaries.

Application-layer authentication gives up channel binding. So the draft requires implementations to account for relay and replay, and to mitigate them with short lifetimes, audience restriction, unique identifiers, and binding to request parameters.

Authorization: OAuth is the delegation framework, and it's enough

This is where AIMS does its most important work: it refuses to invent a new authorization model. The agent is an OAuth client. The access token carries the agent's identity in client_id. When the agent acts for someone else, the token carries that user or system in sub. Resource servers must use both.

The draft maps agent scenarios onto grant types we already know. When a user delegates to an agent, that's the Authorization Code grant, with the user authenticating through phishing-resistant methods such as passkeys. When an agent acts on its own behalf, that's Client Credentials or a JWT authorization grant. In every case, the agent authenticates to the authorization server with its workload credential through JWT client authentication, mTLS client authentication, or the emerging SPIFFE client-auth profile. Never with a static client secret. And because the agent holds a delegated token, it never needs the user's credentials.

AIMS also introduces the Agent Mission: the objective an agent receives, usually in natural language, which has to be broken down into concrete resource and access requirements before the agent requests authorization. The draft deliberately leaves that translation out of scope, citing Karl McGuinness's writing on "mission shaping." I'll argue below that this is the hardest unsolved problem in the space. Naming it is the right first step.

From there, AIMS assembles the rest of the chain.

• Transaction Tokens inside the resource

  When an LLM, tool, or agent is built from multiple microservices, the draft calls for exchanging the inbound access token for a Transaction Token rather than passing the access token around. This is the same argument I made in my recent piece on Txn-Tokens, and it's good to see it written into the agent framework. A downscoped, transaction-bound, short-lived token that can't be replayed with modified parameters is the right way to carry authority through an internal call chain.

• No token forwarding from tools

  The draft calls it an anti-pattern for a tool to forward the agent's access token to downstream services. Tools should use OAuth Token Exchange to get a token targeted at the specific downstream resource.

• Cross-domain chaining

  When an agent crosses into a resource protected by a different authorization server, AIMS points to OAuth Identity and Authorization Chaining Across Domains. That includes the Identity Assertion JWT Authorization Grant for enterprise SSO-to-SaaS cases, and the Transaction Token chaining profile from George Fletcher, Pieter Kasselman, and Sean O'Dell.

• Human in the loop, done properly

  When an authorization server decides a request needs explicit user approval, the agent can use CIBA for out-of-band confirmation. The most important sentence in this section: a confirmation click in an agent's UI is not authorization. It must be converted into a verifiable grant from the authorization server. MCP-style "approve this tool call?" prompts are user experience, not security controls. The draft also admits that CIBA is client-initiated and maps poorly to mid-execution approval, which flags a real gap.

• Discovery for dynamic environments

  Authorization Server Metadata, Protected Resource Metadata (RFC 9728), and Client ID Metadata Documents let agents find the right issuer, audience, and grant flow at runtime instead of relying on brittle static configuration.

Observability is a security control

The top of the stack is where AIMS will matter most to federal programs. The draft says outright that observability is a security control, not just an operational feature. It requires enough monitoring to reconstruct agent behavior and authorization context after the fact.

Participants can subscribe to OpenID Shared Signals Framework events through CAEP or RISC. When a session is revoked, a risk level changes, or token replay is suspected, recipients should attenuate access right away. That can mean dropping cached tokens, re-acquiring tokens with tighter constraints, or re-running policy. Revoked authorization must be enforced without undue delay, and stale cached decisions must not be used.

AIMS then sets a minimum audit record, in tamper-evident form. Each record must capture:

• the authenticated agent identifier;
• the delegated subject, when there is one;
• the resource or tool accessed;
• the action requested and the decision;
• the timestamp and correlation identifier;
• the posture or risk state that influenced the decision;
• any remediation event and its cause.

For anyone working under NIST 800-53, that reads like an agent-specific profile of AU-3 content requirements. It is the evidence base an assessor will ask for when your ATO package includes autonomous agents.

What AIMS leaves open, and where the real work is

AIMS is honest about its boundaries, and those boundaries are where practitioners should focus.

• Mission-to-authorization translation is out of scope

  Turning "reconcile last quarter's vendor invoices" into a least-privilege set of scopes, resources, and authorization details is the step that decides whether agent authorization is actually least privilege or just OAuth scopes wearing a new hat. Whoever solves this well, whether with policy engines, AuthZEN-style PDPs, or planning-time authorization requests, sets the real security ceiling for agentic systems.

• Policy format is deliberately left open

  AIMS asks only that policy be versioned, reviewable, and consistently evaluated. That's the right call for a standard. For implementers, it means the governance model is entirely yours to build.

• Mid-execution human approval needs new protocol work

  The draft says so directly.

• Compliance is deployment-specific

  For DoD and civilian agencies, that means mapping AIMS onto the DoD Zero Trust Strategy, the ICAM reference architecture, and the 800-53 baselines is our job, not the IETF's.

Why this matters now

AIMS gives the industry something it hasn't had: a shared, vendor-neutral reference architecture for agent identity, written by the people who built the underlying standards. It tells builders to stop inventing and start composing. It tells buyers what questions to ask: Where do your agent identifiers come from? Are the credentials cryptographically bound and short-lived? Can the LLM ever see them? Do tools forward tokens? Is human approval backed by a real grant? Can you rebuild an agent's full execution chain from your audit logs?

If a platform can't answer those questions against AIMS, it isn't ready for a federal mission environment.

At UberEther, this is exactly the terrain we've been working. Workload identity, NPE governance, and the authorization plumbing that makes Zero Trust real for things that aren't human. AIMS doesn't change the direction. It gives the whole community a common map. Read the draft, join the WIMSE mailing list, and start measuring your agent architecture against it today. The window to get this right before agents are embedded in every mission workflow is short.