WorkOS auth — Agent Registration Protocol

WorkOS published auth.md on May 25, 2026 — an open protocol that lets AI agents autonomously discover, register with, and obtain scoped credentials from any web service without a human pasting in an API key. Built entirely on existing OAuth infrastructure, it is positioned as a zero-new-infrastructure path to secure, auditable, per-session agent credentials at scale.

The Claim

The core idea is deceptively simple: a service publishes a small Markdown file at service.com/auth.md that describes what OAuth flows and permission scopes it supports. That file is simultaneously human-readable documentation and a machine-parseable registration guide. When an AI agent hits a 401 from any API, it can trigger a two-hop discovery sequence — first checking /.well-known/oauth-protected-resource for a pointer to the Authorization Server, then reading that server's metadata to find the agent_auth block with registration endpoints. The entire discovery is automatic, triggered by an ordinary authentication failure.

WorkOS designed two distinct registration flows to cover the real range of agent deployment scenarios. The first, called Agent Verified, is frictionless by design: if the agent's provider — Anthropic, OpenAI, or Cursor are the named examples — issues a signed JWT called an ID-JAG, the target service verifies that token against the provider's published public keys and hands back credentials with no human involved at any point. The second flow, User Claimed, covers agents that lack a trusted provider relationship. It routes through an OTP email step. Crucially, there are two sub-variants: an anonymous-start path where the agent receives limited-scope credentials immediately and a human can claim ownership later, and an email-required path where nothing is issued until the OTP completes.

WorkOS frames auth.md as a fix for the "API key antipattern" — the widespread practice of generating a long-lived secret, copying it into an environment variable or agent config, and hoping no one rotates or leaks it. Credentials issued under auth.md are scoped to a specific delegation record anchored to a (iss, sub, aud) triple, time-bounded by session, and revocable via a standard logout-token call. The protocol is proposed as an open standard, not a WorkOS-proprietary mechanism, and the spec relies entirely on existing RFCs — RFC 9728 for protected-resource metadata and the ID-JAG draft for provider-issued JWT assertions.

What We See

Our read is that this is one of the more structurally honest proposals to come out of the agent-auth conversation in 2026. Most competing approaches require either a new identity layer (agent wallets, DIDs, custom token formats) or vendor lock-in to a specific orchestration platform. auth.md sidesteps both by making the protocol a thin coordination layer on top of OAuth flows that most services already implement. If your authorization server can issue scoped tokens and verify a JWT signature against a JWKS endpoint, you are most of the way to supporting auth.md — the new work is just the discovery metadata and the auth.md file itself.

The anonymous-start User Claimed flow is the design decision worth watching. It solves a real problem: autonomous agents running on schedules or in background queues cannot pause to wait for a human to complete an OTP. Issuing pre-claim credentials at restricted scopes lets the agent do useful work immediately, while the delegation record sits unclaimed until a human optionally asserts ownership. That is a meaningful improvement over the current norm, which is either blocking the agent entirely or handing it a full-access key with no audit trail.

The Agent Verified flow is equally significant, but its value is conditional on provider adoption. Right now the named providers — Anthropic, OpenAI, Cursor — are listed as the reference integrations, but the protocol document does not come with confirmed commitments from those organizations to issue ID-JAG tokens in production. The spec is sound; whether the ecosystem closes around it is a different question. That said, WorkOS has a reasonable track record of building infrastructure that enterprise customers actually adopt, and publishing this as an open standard rather than a hosted product reduces the adoption friction considerably.

Where It Falls Short

The largest open question is the bootstrapping problem on the service side. For auth.md to change anything, services need to publish the file and wire up their authorization servers accordingly. That is not a heavy lift technically, but it requires a deliberate decision by API providers. Until the major platforms — AWS, GitHub, Stripe, and the LLM API providers themselves — publish auth.md files, the protocol exists mostly as a well-designed spec that agents cannot use. WorkOS can host the standard and provide tooling, but it cannot publish other companies' files for them. The announcement does not include a list of services already live on the protocol, which would have been the most persuasive data point.

There is also a question of how the revocation model holds up in high-volume agentic environments. The logout-token approach is standard OAuth, but at the scale of many short-lived agent sessions — hundreds of cron-style tasks running in parallel across different services — the operational overhead of tracking active delegation records shifts to the service side. The spec is quiet on rate limits, token lifetime defaults, and what services are expected to do when a provider's JWKS endpoint is temporarily unavailable during Agent Verified flows. These are implementation details, not design flaws, but they are the kinds of gaps that produce inconsistent behavior across early adopters before the community settles on conventions. The protocol needs a reference implementation and a conformance test suite before it can be called production-ready for adversarial environments.

Source