WorkOS dropped auth.md this week — an open spec plus a concrete file artifact for the problem nearly every agent shop has been hand-rolling: how does an agent prove it's acting on behalf of user X, with credentials that are user-scoped, revocable, and not a raw API key sitting in environment variables. The shape: a small Markdown file an application publishes at its service root (works as documentation for human developers and as a runtime artifact agents can read programmatically), plus OAuth 2.0 metadata extensions. For builders deploying agents into production where they need to call third-party APIs on a user's behalf, this is the spec that addresses the right problem.
Discovery is a two-hop metadata chain. An agent hits `/.well-known/oauth-protected-resource` (Protected Resource Metadata) to find the authorization server, then fetches `/.well-known/oauth-authorization-server` which contains a new `agent_auth` block with four URIs: `register_uri`, `claim_uri`, `revocation_uri`, and `identity_types_supported`. The novel grant type is ID-JAG (Identity-scoped JSON Authorization Grant) per RFC 9728 — agent identity providers attest user identity via signed JWTs, the authorization server validates the assertion, returns scoped credentials. A 401 response on a protected endpoint includes `WWW-Authenticate: Bearer resource_metadata="..."` to bootstrap the agent into the discovery chain without prior configuration. OpenAI, Anthropic, and Cursor are cited as potential identity providers; the spec doesn't require any single vendor.
The distinction from RFC 7591 Dynamic Client Registration matters and the spec is explicit about it. RFC 7591 lets a client register itself with an authorization server — useful, but the client authenticates *as itself*. auth.md solves a different problem: the agent authenticates *as the user*, on the user's behalf, with the authorization server understanding that distinction and issuing user-scoped revocable credentials. That's the right primitive for the agent-loop world: an agent that calls `send_email` should be acting with the user's email permissions, not with global "I am the agent service" permissions, and the user should be able to revoke that specific agent's access without rotating their own credentials. Today most agent products either ask the user to paste raw API keys (insecure, unrevocable per-agent) or run everything through the agent vendor's own auth (lock-in). auth.md is the standardized middle.
Monday morning: if you're shipping an agent that needs to call third-party APIs on behalf of users, read the spec at github.com/workos/auth.md and check whether your auth provider (Auth0, Okta, custom) has a roadmap toward ID-JAG support. The honest gap is implementation status — early access only, no widespread production servers yet, and the article notes that MCP servers or bare LLM API calls typically can't participate in the agent-verified flow at this stage. Compatibility with existing OAuth libraries is not explicitly addressed in the release; expect rough edges. But the architectural call is sound: this is the user-side of the same problem AWS MCP Server's IAM-OAuth bridge solves on the resource side, and the agent-infra stack needs both. WorkOS is early to the spec; the question is whether OpenAI, Anthropic, and the cloud providers ship interop in months or quarters.