Key Findings
- A March 2026 IETF Internet-Draft, AI Agent Authentication and Authorization (AIMS), declares static API keys “an antipattern for agent identity” and mandates cryptographically bound credentials — X.509 certificates (SPIFFE X.509-SVIDs), mTLS, JWTs, or Workload Identity Tokens.
- Rather than inventing new protocols, AIMS composes existing standards — SPIFFE, WIMSE, OAuth 2.0, OpenID SSF, and HTTP Message Signatures — and classifies agents as workloads, so existing workload-identity infrastructure applies directly.
- The draft defines a 9-component identity stack and requires each agent to carry exactly one WIMSE identifier, which may be a SPIFFE ID.
On March 2, 2026, a working draft quietly landed in the IETF’s datatracker with an unglamorous name: AI Agent Authentication and Authorization, the Agent Identity Management System, or AIMS — draft-klrc-aiagent-auth-00. Its authors are not academics theorizing at the margins: P. Kasselman of Defakto Security, J. Lombardo of AWS, Y. Rosomakho of Zscaler, and B. Campbell of Ping Identity. A revision four weeks later, on March 30, added a co-author from OpenAI.
The draft’s central claim reads less like a proposal and more like a verdict. The industry spent two years asking how to give AI agents identity, floating bespoke token schemes and agent-specific protocols. AIMS answers that the problem was solved a long time ago, in a domain that has nothing to do with language models: workload identity.
The antipattern, named
AIMS opens by taking the most common way agents authenticate today — the static API key — and ruling it out of bounds. The language is blunt for a standards document.
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.
— draft-klrc-aiagent-auth-00, §6 (Agent Credentials)
In place of bearer secrets, the draft requires cryptographically bound credentials: X.509 certificates — specifically SPIFFE X.509-SVIDs — mutual TLS, JWTs, or Workload Identity Tokens. The distinction is the whole point. A bearer token proves only that you hold a string; anyone who copies it inherits the identity. A bound credential proves control of a private key, which a copied transcript cannot replay.
Agents are workloads
The draft’s most consequential move is a reclassification. An AI agent, AIMS argues, is a workload — the same category as a microservice, a container, or a serverless function. That single framing collapses the “new identity problem” into an old, solved one: if agents are workloads, then the workload-identity infrastructure already deployed in production — SPIFFE and its reference implementation SPIRE — applies directly, with no new protocol required.
An agent participating in this framework MUST be assigned exactly one WIMSE identifier, which MAY be a SPIFFE ID.
— draft-klrc-aiagent-auth-00, §5 (Agent Identifier)
Rather than inventing protocols, AIMS composes existing ones — SPIFFE, the IETF’s own WIMSE work, OAuth 2.0, OpenID Shared Signals (SSF), and HTTP Message Signatures. On the transport layer, the draft is explicit about why bound short-lived identity matters in practice.
When paired with short-lived workload identities, the draft notes, “such as those issued by SPIFFE or WIMSE, mTLS provides strong channel binding and cryptographic proof of control over the agent’s private key.” That is the mechanism the API key lacks, stated as a requirement rather than a recommendation.
The nine-component stack
AIMS structures agent identity as nine components that have to work together, from issuing an identifier through to ongoing compliance. The list reads as a checklist for anyone building or buying agent infrastructure.
- Identifier — exactly one WIMSE identifier per agent, optionally a SPIFFE ID.
- Credentials — cryptographically bound, not bearer secrets.
- Attestation — proof of the workload’s properties at issuance.
- Provisioning — how identity is delivered to the agent.
- Authentication — proving the identity at runtime.
- Authorization — scoping what the identity may do.
- Monitoring, observability, and remediation.
- Policy — the rules that govern the above.
- Compliance — demonstrating the whole stack meets requirements.
The SecureW2 read
Strip the AI framing and AIMS describes something we have built around for two decades: cert-based workload identity that is short-lived, attested, and cryptographically bound to the thing it represents. The novelty is not the mechanism — it is that a standards body has now named it the default answer for agents, and named the alternative, the static API key, an antipattern by name. The question for security teams stops being “how do we invent identity for agents” and becomes “do our agents carry a real, bound, short-lived credential — or a string anyone can copy.”
Quotes are drawn verbatim from IETF Internet-Draft draft-klrc-aiagent-auth-00. Section references are the draft’s own. Used here in a design mockup.
