Agent Signup with auth.md: Inside WorkOS Auth

The login box was hardened for twenty years against automated traffic, which is why agent signup with auth.md is not just an authentication problem. Blocking bad bots also blocks the good ones, and MCP still keeps a human in the loop for consent. The auth.md specification separates registration from everything else that follows it.

What agent signup with auth.md actually changes

Agent signup with auth.md changes one step in a signup flow: the part where an autonomous process becomes a legitimate account holder. WorkOS, a company that sells enterprise authentication infrastructure, published the specification so agents can register without a human filling forms, solving CAPTCHAs, or copying API keys by hand. Registration is the whole scope; everything before and after stays the responsibility of existing systems.

The auth.md specification is a markdown file a service publishes at a known path. It declares what the service does, which identity proofs it accepts, which signup flows are supported (SSO, email, multi-factor), what scopes and entitlements exist, and what free-tier constraints apply before verification or payment. The goal is a machine-readable answer to the question an agent asks before it commits to a vendor.

Michael Grinich, founder and CEO of WorkOS, presented the work at the AI Engineer World's Fair 2026 in San Francisco. In his framing, agent registration is a missing primitive: discovery, tool connection, and context delivery all have working standards, but the first step where an agent becomes a customer had no answer. He described the file as instructions that tell an agent what to do to be treated as a legitimate user.

The spec is deliberately narrow. Grinich said on stage that it does not solve agent identity, long-duration permissions, or connected services. It covers registration only, which keeps the surface small enough for a service to adopt without replacing its existing API or documentation. Normal API calls, MCP servers, and reference docs keep working after the account exists.

Why login boxes and CAPTCHAs block legitimate agents

Login boxes block legitimate agents because two decades of abuse prevention trained the web to treat all automated traffic as hostile. Denial-of-service prevention, credential-stuffing defenses, and CAPTCHA challenges were built to stop scripts, and they cannot easily tell a helpful autonomous process from a malicious one. Grinich's argument is that the industry needs a way to admit good agents while still turning away bad ones, which filtering alone cannot do.

Today's signup flow assumes a human can read a landing page, enter an email address and password, solve a CAPTCHA, OpenAI verification email, pick a paid plan, and copy an API key into another tool. An agent usually has no mailbox, no credit card, and no patience for a dashboard built for human eyes. Each of those steps is a wall.

Browser-execution services that advertise CAPTCHA-solving as a feature show how far the workaround culture has gone. Grinich noted the irony: the industry is spending effort to reverse controls rather than define a sanctioned path. Token fraud and automated abuse remain widespread regardless, which is why an open door with identity evidence attached is a different proposition from simply disabling protections.

The risk question does not disappear under the spec. A service still has to decide whether the agent signing up is trustworthy, which is why auth.md lets a provider request out-of-band verification, attach organization identity, or restrict what an unverified account can do.

How the registration handshake works, step by step

The handshake runs discovery, identity assertion, verification, and token issuance, and each stage maps to an existing standard rather than a new one. In the demo, an agent working inside a coding harness needed to deploy a prototype beyond the developer's laptop, searched for services that advertise an auth.md file, and selected Cloudflare because it was open for agent registration. No human opened a signup page at any point.

The numbered sequence below follows the demo Grinich showed and the diagram he used to explain it:

1. Discovery. The agent fetches the service's auth.md file and reads what the service does, which identity proofs it accepts, and what free-tier limits apply before verification or payment.
2. Identity assertion. The agent mints a signed credential through its backing identity service. In the demo this was an ID-JAG, an identity JSON access grant that represents the user and is handed to the service.
3. Verification. The service decides how strictly to check that assertion, either inline or out of band, depending on its own risk model.
4. Token issuance. The service returns an access token for a temporary account, and the agent continues with ordinary API calls.

Cloudflare's side granted a short-lived account in the demo, described as roughly 72 hours of deploy access, after which the temporary account could be claimed and upgraded. Grinich emphasized that the dial settings are application-specific: a database service might give away a little traffic to earn a customer, while an email service or anything touching the physical world may give nothing away before identity and payment are settled.

WorkOS also demonstrated the flow working with Firecrawl, a web-scraping API. The demonstration is first-party, run by the specification's authors with a partner, not an independent benchmark. Its value is showing the mechanics end to end, not proving adoption across the web.

What auth.md declares, and what it deliberately leaves out

An auth.md file declares five things an agent needs before it commits to registering: what the service does, how registration works, which identity proofs are accepted, which flows are supported, and what constraints apply to a new account. It can also describe how a human or organization claims the account afterward, which matters because an agent creates the account but a person usually needs custody of it.

Field	Question it answers	Why an agent needs it
Service description	What does this service do?	Decides whether the vendor fits the task
Registration method	How do I sign up?	Replaces form-filling and CAPTCHA steps
Accepted identity proofs	What proves I am legitimate?	Lets the agent choose an assertion it can mint
Flows and scopes	What can this account do?	Sets entitlements before any work starts
Free-tier constraints	What do I get before paying?	Prevents runaway usage on a temporary account
Human claiming	How does a person take custody later?	Keeps a human accountable for the account

The boundary between this spec and MCP is explicit. Model Context Protocol, the open standard for connecting AI assistants to tools and data, handles tool exposure and context delivery well, but its authentication path assumes a human grants consent and signs in. Grinich, who described himself as an MCP supporter, said clearly that MCP is not enough for the registration step, because registration has to happen without a person present at least initially.

That same boundary applies to payments. Crypto protocols and payment-provider initiatives exist for agents that need to pay, and Grinich placed them downstream of registration on purpose. Forcing a credit card into the first step repeats a practice the SaaS industry already abandoned, he argued; an agent should register, use the service, and pay later on the provider's own pricing terms if usage continues.

Where the spec stops, and what to verify before adopting it

The specification stops at registration, so it does not by itself make a service safe, compliant, or ready for regulated workloads. It defines how an agent proves who it is and what a provider chooses to accept. Tenant isolation, audit logging, data residency, and industry-specific rules remain the application's and the organization's responsibility, exactly as they were before.

WorkOS calls auth.md an open spec and says it does not control it, while offering a hosted version for customers. That is a common open-core shape in developer tooling, and it means the governance question is worth checking directly: who maintains the repository, how changes are proposed, and whether the path at a given domain is served by the provider or by a third party. Grinich stated that anyone can build or self-host it.

Adoption is the real test, not the demo. A published file only helps if agents look for it and services actually write one that matches their behavior. The Cloudflare and Firecrawl demonstrations show the flow can work; they do not show how many services have adopted it or how agents behave when the file is missing, stale, or contradicts the API it describes.

For teams evaluating it, the practical checks are straightforward: confirm the file your service publishes matches the real signup and entitlement behavior, decide which identity proofs you will accept and at what risk level, and define what an unverified or temporary account can do before a human claims it.

Who has to change more: the agent or the service?

Services carry most of the work, because agent signup requires them to make registration machine-readable and to define identity and entitlement rules they may never have written down. An agent needs a way to mint an assertion and the judgment to pick a vendor; a service needs a published policy, a verification path, and a plan for accounts that exist before a person does. The second list is longer.

Grinich's broader claim was that building for agents may matter more than building for people, because agents select vendors for deployment, email, storage, and other infrastructure, and they spin up faster than human users. He cited no adoption figures for that shift, and the evidence he offered was anecdotal: founders posting growth graphs that moved after agents started choosing their tools.

That is a directional argument, not a measured trend. Treat the vendor-selection claim as an inference from visible behavior in developer tooling rather than a proven ecosystem-wide replacement of human buyers. The narrower, checkable claim is that a service which cannot be registered by an agent cannot be selected by one, regardless of how good its API is.

The parallel Grinich drew was with product-led growth, where a low-friction entry point expands the funnel and revenue follows usage. Whether agent accounts convert at similar rates is unknown, and no data in the talk answered it.

Frequently asked questions about auth.md and agent signup

• What is auth.md? It is an open specification that tells an AI agent how to register for a web service, published as a markdown file at a known location. It covers discovery, accepted identity proofs, supported signup flows, scopes and entitlements, free-tier limits, and how a human claims the account later.

• Does auth.md replace OAuth? No. It builds on existing open standards including OAuth-style flows and identity assertions, and it targets only the registration step. Authentication and authorization for normal API calls continue to work as they did before.

• Is auth.md a replacement for MCP? No. Model Context Protocol connects agents to tools, skills, and context, but its authentication path assumes a human grants consent and signs in. The two address different steps and are designed to be used together.

• Who created it? WorkOS, an enterprise authentication company, published the spec, and founder and CEO Michael Grinich presented it at the AI Engineer World's Fair 2026 in San Francisco. WorkOS says it does not control the spec and that others can implement or self-host it.

• How does an agent prove its identity during registration? The agent mints a signed identity assertion, such as an ID-JAG, through its backing identity service and presents it to the provider. The provider chooses whether to verify it inline or out of band, depending on its risk model.

• Does auth.md handle payment? No. Payment is deliberately downstream of registration. An agent registers, receives a temporary or limited account, uses the service, and pays later under the provider's own pricing terms if usage continues.

• What did the Cloudflare demo show? A demo agent found Cloudflare's auth.md file, proved its identity, received a temporary account with roughly 72 hours of deploy access, and deployed an application. The human in the session only approved steps; no signup form was filled in.

• What do I still need to build if I adopt the spec? You need a published policy that matches your real signup behavior, a verification path that fits your risk tolerance, entitlement rules for accounts without a human owner, and a claiming flow so a person or organization can take custody later.

• Does it make my service suitable for regulated environments? Not by itself. The spec defines registration mechanics and identity evidence only. Compliance, tenant isolation, auditability, and data-handling requirements remain the application's and the organization's own controls.

A registration door that opens both ways

This article's main workflow, turning a conference talk into a structured post, is a small example of the same idea behind the practical workshops at Crazystack, where developers build agent-facing systems from the ground up and work through the bootcamp format called Bootcamp do Dev Doido. Both efforts share a premise: agents need explicit, machine-readable entry points to participate in real workflows, whether the target is a service or a build pipeline. Gustavo Dev Doido talks about this shift often, and the Crazystack Typescript track is one place to try the pattern out with real code.

The registration door is a good test case because it is small. If a service can describe, in one file, who may enter and what they get, then the rest of the agent-native stack has a foundation to build on. If it cannot, the tooling above it does not matter much.

If you have taught, demonstrated, or explained a workflow like this on video, that recording already contains the structure of an article: an idea, a sequence, a demo, and a set of caveats. Skala Blog turns a YouTube URL into a transcription and then into a publishable draft you can review and edit, which is a reasonable way to test whether your explanation survives outside the room it was delivered in.

Source video