Versine vs. auth.md
auth.md’s signup-free path only works if the agent’s harness vouches for its user, and no agent harness supports that. So with auth.md, people still sign up at every service their agent uses. Versine needs nothing from agent vendors: it’s an MCP server the person adds themselves.
Last reviewed September 25, 2026
How auth.md works
A service publishes an auth.md file describing its agent registration endpoints. An agent registers, receives an identity assertion and exchanges it for an access token or API key. WorkOS launched the protocol in May 2026 under the MIT license, and it builds on existing OAuth standards for discovery and token exchange.
There are three ways to register:
- Agent verified. The agent’s provider signs an assertion vouching for the user, and the service issues credentials immediately.
- User claimed, by email. The agent supplies the user’s email. The service withholds credentials until the user signs in or signs up at the service and confirms a six-digit code.
- User claimed, anonymous start. The agent gets restricted credentials right away. To keep the registration, a person signs in or signs up at the service and claims it before it expires.
The specification is still pre-1.0 and has shipped several breaking versions. WorkOS’s hosted implementation, Agent Registration in AuthKit, is available through early access.
No agent harness supports auth.md’s signup-free path
auth.md has exactly one path where the person never signs up: the agent-verified flow. The agent presents a signed identity assertion (an ID-JAG, from an IETF draft) issued by its provider, and the service takes the provider’s word for who the user is.
That puts the whole experience in the hands of agent vendors. auth.md’s documentation names OpenAI, Anthropic and Cursor as example agent providers, but as of September 2026 none of them issues ID-JAGs for auth.md, and neither does any other agent harness we have found. WorkOS’s own documentation acknowledges that agents built on MCP servers or plain LLM APIs typically can’t.
Until every agent vendor ships it, and every service decides to trust every vendor, the signup-free path exists on paper only.
So users still have to sign up
Without harness support, every agent falls back to a user-claimed flow. For services where accounts hold a person’s own data, WorkOS’s AuthKit documentation recommends enabling only the email flow:
- The agent registers with the user’s email and gets nothing yet.
- The agent sends the person a link and a code, and waits.
- The person opens the link, signs in, or signs up if they are new to the service, and confirms the code.
- Only then does the agent receive credentials.
The anonymous start lets the agent begin before the person gets involved, and WorkOS positions it for resources owned by organizations rather than individuals. Its credentials are restricted, and the registration expires unless a person claims it, which again means signing in or signing up at that service.
Either way, the person creates an account at every service their agent uses: another login method, another profile form, another set of terms. That is the step they delegated the task to avoid.
Rate limits and shared networks
Anonymous registration is an unauthenticated endpoint, so it needs abuse protection. The auth.md integration guide suggests per-IP limits, with a default of five anonymous registrations per hour, and a per-tenant cap of 100 an hour. At least one adopter adds a CAPTCHA to its anonymous flow.
Many independent agents run in the same cloud browsers and share IP ranges, so a per-IP limit that stops one abuser can also block legitimate agents behind the same address. A CAPTCHA stops the automated visitors the flow exists to serve.
Versine uses proof of work instead. Each claimable account costs a short, automatic computation in the agent’s browser, bound to one signup and chosen by the server. The cost rises for sessions that leave accounts unclaimed, and shared-network activity can raise it by at most one step. See build vs. buy for how the escalation works.
How Versine differs
Works with every agent, because it’s just MCP
auth.md waits for agent vendors to vouch for their users. Versine doesn’t need them to ship anything. It’s an MCP server: the person connects it to the agent they already use, once, and the person’s own Versine account does the vouching. From then on, the agent signs up for full accounts with the person’s verified identity, and the person approves on their phone when a platform needs their consent or details. No signup at your service, no claim step, no waiting on OpenAI or Anthropic.
No person needed to start
An agent without Versine clicks “Are you an agent?” on your signup page and creates a claimable account on its own. Your platform receives an ordinary login for a restricted, 24-hour account, with signed claims describing its state and permissions. The person does nothing until they decide they want it.
One signup, not one per service
To keep a claimable account, the person opens the claim link from their agent and signs up for Versine, or signs in if they already have an account. The next platform’s claim is a sign-in, not another signup. Your platform keeps the same user identifier, so the agent’s work stays attached.
Side by side
| Dimension | auth.md | Versine |
|---|---|---|
| Agent harness support | Needed for the signup-free path; no harness has it | None needed. Versine is an MCP server |
| Signup-free path requires | The agent’s vendor to mint ID-JAGs | The person to connect Versine MCP to their agent once |
| Without that | Person signs in or signs up at each service | Claimable account, claimed with one Versine identity |
| Signup with no person present | Anonymous start, if the service enables it | Claimable accounts |
| Signups for ten services | Up to ten | One, or none with Versine connected |
| What the platform receives | API access token or API key | A standard OIDC login for your existing session |
| Abuse protection | Suggested per-IP and per-tenant limits | Proof of work that escalates for unclaimed accounts |
| Profile and consent | Handled by each service | Passport details for forms, versioned terms acceptance |
| Status | Open specification, pre-1.0 | Hosted service |
When auth.md fits better
- Your product is an API. If agents need API keys to call your service from code, and never use a browser session, auth.md is designed for exactly that.
- You want an open specification you can implement yourself with no hosted dependency.
- Your resources belong to organizations, so anonymous agents can do useful work before anyone claims them.
The two aren’t exclusive. Versine is an OpenID Connect provider, so it can sit next to WorkOS AuthKit and other auth providers, covering agents that sign up through your website while auth.md covers agents calling your API.
Frequently asked questions
Is auth.md a WorkOS product?
The protocol is open and MIT-licensed, and you don’t need a WorkOS account to publish an auth.md file. WorkOS wrote it and offers a hosted implementation in AuthKit.
Doesn’t auth.md also have claimable accounts?
Its anonymous start is similar: the agent gets restricted credentials, and a person can claim them later. The difference is what claiming costs the person. With auth.md, they sign in or sign up at that service. With Versine, they use one Versine identity for every platform, and connected agents skip the claim entirely.
What happens when agent vendors support ID-JAGs?
Services that trust those vendors could then skip the signup for their users. Versine doesn’t depend on that: the person’s own Versine account does the vouching, with any agent they connect it to.
Do I have to replace AuthKit or my current provider?
No. Add Versine as an OpenID Connect connection in the provider you already use. See the integration guide.