auth.md: How AI Agents Will Sign Your Users Up

There is a new open protocol called auth.md. It does one thing: it lets an AI agent sign a user up for your app without a signup form.

WorkOS published it. It is not locked to WorkOS. Cloudflare, Firecrawl, Resend, and Monday.com have already shipped it. If you build anything that an agent might touch, this is worth understanding now, while the term is still new and nobody is writing about it.

The problem it solves

Right now, agents fake their way through signup. An agent acting for a user hits your registration page, fills the form field by field, solves the captcha if it can, and hopes nothing changed since last week. It is brittle. It breaks on every redesign. And you, the app owner, have no idea a robot just created an account.

auth.md replaces the form with a contract. You host a Markdown file at https://yourapp.com/auth.md. The file declares how an agent is allowed to register a user. The agent reads the file, follows the declared flow, and gets back a scoped API key or access token. No form. No guessing.

If you have read about MCP, the mental model is the same shape. MCP lets agents use your tools. auth.md lets agents onboard your users. Same world, different door.

How it works

There are two flows, and you choose which ones you accept.

Agent Verified. The agent's identity provider vouches for the user. No human in the loop. Fast, but you are trusting the provider's word that the user is real.

User Claimed. The agent triggers a one-time code. The actual human confirms it. Slower by one step, but a person signed off. This is the flow you want for anything that touches money or data.

You publish a Markdown file that says which flows you support, what scopes you grant, and what the agent gets back. The agent parses it and acts. That is the whole protocol. It is readable by a person and by a model, which is the point.

Why this matters more than it looks

Signup is the front door of every SaaS product. For ten years we built that door for humans: forms, captchas, email confirmation, onboarding tours. None of that works when the user never shows up and an agent comes instead.

The apps that adopt auth.md get a second front door, one built for agents. As more people run agents that buy, book, and subscribe on their behalf, that door starts mattering. The apps without it stay stuck with robots brute-forcing their human forms.

What breaks

This is the part the launch posts skip.

The second an agent can register itself, it can register a thousand times. Agent-driven signup means agent-driven abuse: spam accounts, credential farming, and runaway spend from a loop you did not write. The Agent Verified flow is the scary one here, because there is no human to slow it down.

So if you ship auth.md, you also ship rate limits and budget caps on day one, not later. An agent that can sign up is an agent that can rack up cost. We have written before about prompt injection in AI agents, and this is the same lesson from a different angle: the moment you let an agent act, you have to bound what it can do.

That is exactly the problem AgentGuard exists for. It is a runtime budget, token, and rate limiter for AI agents. pip install agentguard47, wrap the agent, set a ceiling. If you are opening a door for agents, put a meter on it.

Should you ship it today

Probably not today, for most small builders. The protocol is new. The adopters are infrastructure companies with real agent traffic. If your app is a content site or a tool with no signup funnel, hosting an auth.md file is theater.

But put it on the watch list. The pattern is the same one MCP followed: niche, then obvious. If you sell a product that agents could subscribe to on a user's behalf, the team that ships the agent door first wins that traffic. Read our breakdown of MCP for how that curve tends to play out.

And whichever door you open for agents, meter the spend behind it. Start with cost control for your agents before you hand one a key. Try AgentGuard and set the ceiling before the first agent walks in.