On March 2, 2026, four engineers from Defakto Security, AWS, Zscaler, and Ping Identity published draft-klrc-aiagent-auth-00 — a 26-page IETF draft that finally gives AI agents a proper identity framework. Called AIMS (Agent Identity Management System), it doesn’t invent new protocols. Instead, it composes SPIFFE, WIMSE, and OAuth 2.0 into a coherent stack that solves the “how do AI agents prove who they are” problem.
This matters because the current state of AI agent authentication is dire. An analysis of over 5,200 open-source MCP server implementations found that 53% rely on static API keys, while only 8.5% use OAuth. The AIMS framework provides the architecture to fix this — and with the EU AI Act’s high-risk system requirements taking effect August 2, 2026, the compliance clock is ticking.
The Problem: AI Agents Have No Identity
When a human user authenticates, the flow is well-understood: username/password, MFA, session token. When an AI agent needs to call an API, the current approach is usually one of:
- Hardcoded API key in environment variables
- Service account credentials shared across multiple agents
- User’s OAuth token passed through without scoping
All three approaches fail at scale. Static API keys can’t be rotated automatically, can’t be scoped to specific transactions, and provide no proof that the agent requesting access is actually the agent it claims to be. For a deeper look at how MCP OAuth 2.1 authentication handles some of these issues at the protocol level, the AIMS framework goes further by providing the identity layer underneath.
The AIMS 8-Layer Model
AIMS defines eight layers, each building on the one below:
Layer 1: Agent Identifier
Every agent gets a WIMSE identifier — a URI that uniquely identifies the workload. The operationally mature implementation is SPIFFE:
spiffe://company.example/agents/data-analyst
spiffe://company.example/agents/code-reviewer
spiffe://company.example/agents/customer-support
The identifier is stable throughout the agent’s lifetime and must be unique within its trust domain. This is the foundation — without a stable identity, nothing else works.
Layer 2: Agent Credentials
Credentials are cryptographic bindings to the identifier. AIMS supports three credential types:
| Credential | Format | Use Case |
|---|---|---|
| X509-SVID | X.509 certificate | mTLS, service mesh environments |
| JWT-SVID | Signed JWT | Application-layer auth, API calls |
| Workload Identity Token | JWT per WIMSE spec | Cross-domain federation |
Critical requirement: credentials MUST be short-lived with explicit expiration times. The draft explicitly calls static API keys “an antipattern for agent identity.”
Layer 3: Agent Attestation
How does the identity system know the agent is legitimate? Attestation proves the agent’s runtime environment:
- Hardware attestation: TEE (Trusted Execution Environment) evidence, TPM measurements
- Software attestation: Binary hashes, container image digests
- Platform attestation: Kubernetes pod identity, cloud instance metadata
- Supply-chain attestation: SLSA provenance, SBOM verification
For high-risk scenarios, AIMS recommends multi-attestation — combining hardware, software, and platform evidence.
Layer 4: Credential Provisioning
The SPIFFE runtime (SPIRE) handles this automatically:
- Initial provisioning: Agent starts → SPIRE node agent performs attestation → Issues short-lived SVID
- Automatic rotation: SPIRE renews credentials before expiry — no manual intervention
- Revocation: Compromised credentials are revoked via CRL or OCSP
This eliminates the operational burden of credential management. No more “rotate the API key across 50 agents” incidents.
Layer 5: Agent Authentication
Two patterns, depending on architecture:
Transport-layer (mTLS): Agent presents X509-SVID during TLS handshake. Works well in service meshes but breaks with intermediaries (proxies, load balancers).
Application-layer: Agent signs requests using WIMSE Proof Tokens (WPTs) — JWTs bound to specific HTTP requests:
{
"iss": "spiffe://company.example/agents/data-analyst",
"aud": "spiffe://company.example/services/database",
"exp": 1711234567,
"jti": "unique-request-id",
"wth": "sha256-hash-of-workload-identity-token",
"htm": "POST",
"htu": "https://api.example.com/query"
}
The WPT binds the authentication to a specific request (method + URL), preventing token replay across different endpoints.
Layer 6: Agent Authorization
This is where OAuth 2.0 comes in. AIMS defines three grant patterns:
| Scenario | OAuth Grant | When to Use |
|---|---|---|
| User delegates to agent | Authorization Code | Human approves agent’s access interactively |
| Agent acts on its own | Client Credentials / JWT Grant | Autonomous agent with pre-defined permissions |
| Agent calls another agent | Token presentation | Chained delegation with scoping |
Access tokens follow RFC 9068 (JWT Profile) with standard claims: client_id (agent identifier), sub (delegated user), aud (target resource), scope (permissions).
For cross-domain scenarios — an agent in trust domain A accessing resources in trust domain B — AIMS uses OAuth Identity and Authorization Chaining to obtain tokens from multiple authorization servers.
Layer 7: Monitoring and Observability
AIMS integrates with the Shared Signals Framework (SSF/CAEP/RISC) for real-time security events:
- Credential compromise detected → Revoke all tokens for that agent
- Anomalous behavior → Dynamically reduce authorization scope
- Agent terminated → Clean up all active sessions
This is the runtime equivalent of Identity Threat Detection and Response (ITDR) — but for non-human identities.
Layer 8: Policy
Configuration rules governing all lower layers. Defines which agents get which identifiers, what attestation is required, and which authorization policies apply.
Transaction Tokens: Preventing Lateral Movement
One of AIMS’s most important security patterns is transaction tokens. When an agent calls a tool that internally spans multiple microservices:
- The agent presents its access token to the entry service
- The entry service exchanges it for a transaction token bound to a specific transaction ID
- The transaction token is passed to downstream services — but it’s downscoped and time-limited
- Downstream services cannot use the transaction token to access unrelated resources
This prevents the “compromised microservice uses the agent’s full-privilege token to move laterally” attack pattern.
How AIMS Compares to Current Approaches
| Aspect | Static API Keys | MCP OAuth 2.1 | AIMS Framework |
|---|---|---|---|
| Identity binding | None | Client ID only | SPIFFE URI + attestation |
| Credential rotation | Manual | Token refresh | Automatic (SPIRE) |
| Attestation | None | None | Hardware + software + platform |
| Agent-to-agent auth | N/A | Not specified | WPT + OAuth delegation |
| Monitoring | Logs only | Token events | SSF/CAEP real-time signals |
| Cross-domain | N/A | Single AS | Identity chaining |
AIMS isn’t competing with MCP OAuth — it’s providing the identity layer that MCP (and every other agent protocol) needs underneath.
What This Means for Practitioners
If you’re building AI agents today
- Stop using static API keys. The AIMS draft codifies what practitioners already know — API keys are an identity antipattern.
- Deploy SPIRE for workload identity. It’s production-ready, CNCF-graduated, and handles the credential lifecycle automatically.
- Use OAuth 2.0 Client Credentials for agent-to-service authentication. This is the simplest AIMS-compatible pattern. For user-delegated access, use the Authorization Code flow with PKCE.
If you’re evaluating IAM platforms
Check whether your platform supports SPIFFE/WIMSE identifiers and can issue short-lived credentials to workloads. Keycloak supports OAuth 2.0 Client Credentials and JWT Bearer grants. Commercial platforms like Ping Identity (whose Brian Campbell co-authored the AIMS draft) are likely to add native AIMS support.
If you’re preparing for the EU AI Act
High-risk AI systems must demonstrate proper identity and authorization controls by August 2, 2026. AIMS provides the reference architecture. Start with Layer 1 (identifiers) and Layer 6 (authorization) — these are the minimum for compliance.
The Draft in Context
AIMS isn’t the only IETF work on AI agent identity. Related drafts include:
- draft-ni-wimse-ai-agent-identity — WIMSE applicability specifically for AI agents
- draft-yl-agent-id-requirements — Digital identity management requirements for agent communication protocols
- OAuth Transaction Tokens (draft-ietf-oauth-transaction-tokens-07) — The token exchange pattern AIMS references
The convergence of these drafts suggests the IETF is serious about standardizing AI agent identity before the ecosystem fragments further.
Key Takeaways
The AIMS framework solves a real problem: AI agents need proper identities, not shared secrets. By composing existing standards (SPIFFE + OAuth 2.0), it avoids the “new protocol adoption” barrier. The 8-layer model provides a clear roadmap — start with identifiers and credentials, then layer on attestation and monitoring as your agent deployment matures.
The draft is at version 00 — early, but the authors represent major players (AWS, Ping Identity, Zscaler). Watch the IETF OAuth Working Group for progress.
