Authenticating AI Agents: A New IETF Draft on Agent Identity and Authorization

Here's how almost everyone wires up an AI agent today. You create a .env file, paste in OPENAI_API_KEY, STRIPE_API_KEY, GITHUB_TOKEN, and a database URL with the password baked in, and hand the whole thing to the agent. Maybe the keys live in a secrets manager instead of a file — but they're still long-lived bearer tokens, and the agent can use any of them, for anything, at any time, until you remember to rotate them. If the agent gets prompt-injected or its logs leak, so does the key.

A new IETF Internet-Draft, AI Agent Authentication and Authorization, argues this is exactly backwards — and it's interesting both for what it says and for who is saying it.

Who wrote it

The draft is notable because it isn't from an AI lab inventing something new. It's from the people who built the identity plumbing the rest of the internet already runs on:

• Aaron Parecki (Okta) — author of OAuth 2.0 Simplified, maintainer of oauth.net, and an editor of OAuth 2.1.
• Brian Campbell (Ping Identity) — author of foundational OAuth RFCs (7521–7523).
• Pieter Kasselman (Defakto Security) — co-author of Transaction Tokens and OAuth Identity Chaining.
• Jean-François Lombardo (AWS), Yaroslav Rosomakho (Zscaler, co-author of the WIMSE workload identifier spec), and Nick Steele (OpenAI).

An OAuth spec author at Okta, an OAuth RFC author at Ping, and identity engineers from AWS, Zscaler, and OpenAI agreeing on anything is itself the headline. Here are the three ideas at the core of their argument.

1. Don't invent new agent-auth protocols

The single biggest design decision in the draft is a refusal: it proposes no new protocols. Its stated goal is to show how existing, widely deployed standards — the OAuth 2.0 family, OpenID, and the workload-identity standards WIMSE and SPIFFE — already cover agent authentication and authorization, then to identify the gaps worth standardizing later.

That's a deliberate shot across the bow of a noisy field. Everyone shipping an agent framework right now seems to be bolting on a bespoke auth scheme. The draft's authors — who have spent a decade watching people reinvent OAuth badly — are saying: you almost certainly don't need a new protocol, you need to apply the boring proven ones correctly.

2. An agent is a workload, not a user

This is the conceptual move everything else hangs on. When we think of an agent as "acting on my behalf," it's tempting to give it our identity and our credentials. The draft rejects that. An agent, it argues, is a workload — closer to a microservice than to a person — and should get a workload's identity.

Concretely, that means every agent gets a unique, verifiable identifier — a WIMSE identifier, which may be a SPIFFE ID shaped like spiffe://trust-domain/path. Three things follow from treating agents as first-class workload identities rather than borrowed human ones:

• Delegation becomes explicit. When an agent acts for you, your identity is carried as a separate, auditable claim (the sub) while the agent authenticates as itself (the client_id). The audit log can finally answer "which agent did what, on whose behalf."
• Authorization can be scoped to the agent, not just to you. The agent gets its own permissions, not a copy of all of yours.
• It plugs into existing infrastructure. Service meshes, mutual TLS, and workload-identity systems like SPIFFE already do this for microservices today — agents just become another workload in the same model.

3. Static API keys are an antipattern

With those two ideas in place, the draft says the quiet part out loud. Static API keys, it states flatly, 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."

That's the .env file from the opening paragraph, indicted point by point. A key in a file proves possession, not identity — anyone holding it is the agent. It says nothing about which agent is calling or who they're acting for. And because it's long-lived, a single leak is a standing liability until manual rotation.

The replacement: short-lived credentials, cryptographically bound to the agent's identifier, issued at runtime and automatically rotated before they expire. Issuance can even be gated on the agent's posture — hardware attestation, software-integrity measurements, or supply-chain provenance — so a credential is only minted if the workload looks trustworthy at that moment. Short lifetimes replace the revocation problem with expiry, which is far easier to get right at scale.

Why it matters

None of the building blocks here are new — that's the point. The interesting thing is a group of the internet's identity standards-setters looking at the agent gold rush and saying: the answer isn't a shiny new protocol, it's the discipline the rest of production infrastructure already adopted. Treat agents as workloads, give them real short-lived identities, and stop handing them your keys.

It's an Internet-Draft with no formal IETF standing yet, and it expires in December 2026. But as a statement of where serious identity people think agent security has to go, it's worth reading before you paste one more secret into a .env file.