Worth noting that this RFC is squarely in the M2M API auth space — it assumes the agent is calling an API that can be updated to speak OAuth/OIDC. That's the enterprise-to-enterprise layer, and it makes sense.
The gap it doesn't touch: consumer services (email newsletters, SaaS signups, SMS verification flows) will never adopt IETF agent auth standards. They expect a real human email and phone. The verification SMS goes to a phone number. The confirmation email goes to an inbox. A human clicks it.
That's a fundamentally different problem — not 'how does an agent authenticate to an API' but 'how does an agent prove it exists to a service that was built assuming a human is on the other end.' The RFC doesn't help there. You need a different layer.
There are two elements here. Agent can start a full authorization request with AS through authorization code grant flow, even requiring a step-up or some rich authorization details, therefore whatever OTP by SMS or Magic link is an AS - Subject/Client "problem".
For Agent that cannot start a full authorization request (too costly, to complex, subject directly unreachable at the moment), we have a mention to OpenID Connect CIBA into it. With it, the Agent will start a back channel authorization request with the AS and the AS will use a method of authentication / confirmation with the subject in front channel, for example sending a SMS or sending a link to click. Again the resolution will remain an AS - Subject/Client "problem".
This is a solid draft. glad to see it building on SPIFFE/WIMSE and OAuth rather than inventing new identity primitives. The "agents are workloads" framing in Section 3 is exactly right and should settle the debate about whether agents need their own identity model.
The Transaction Token pattern (Section 10.4) is particularly important. We arrived at something similar — short-lived ES256-signed tokens scoped to a single task with a 60s TTL, encoding the specific tools and operations authorized. The key addition we found necessary: embedding data classification and governance evidence in the token itself, so the token isn't just authorization ("you may call this tool") but also proof that scanning and policy evaluation happened. Makes the audit trail self-verifying.
One gap I'd flag: the draft covers the auth layer thoroughly but doesn't address the data protection layer: what happens to the content flowing through these authenticated channels. An agent can be
perfectly authenticated and authorized to call an LLM, and still send PII or credentials in the prompt. That's a different control plane (content scanning, classification, taint tracking) that sits
alongside auth, not inside it. Might be worth a forward reference to indicate this is complementary scope.
The static API keys antipattern callout in Section 6 is important. In practice, most agent deployments today still use long-lived API keys passed as environment variables. The gap between what this draft recommends and what people actually do is enormous.
The gap it doesn't touch: consumer services (email newsletters, SaaS signups, SMS verification flows) will never adopt IETF agent auth standards. They expect a real human email and phone. The verification SMS goes to a phone number. The confirmation email goes to an inbox. A human clicks it.
That's a fundamentally different problem — not 'how does an agent authenticate to an API' but 'how does an agent prove it exists to a service that was built assuming a human is on the other end.' The RFC doesn't help there. You need a different layer.
reply