AgentID vs WorkOS
auth.md is an open protocol that tells agents how to register at your app. AgentID is an identity provider that vouches for who the agent is. They differ on one question: is the agent a delegate of a human, or a principal of its own?
- AgentID
TL;DR
auth.md is an open protocol that tells agents how to register at your app. AgentID is an identity provider that vouches for who the agent is. They differ on one question: is the agent a delegate of a human, or a principal of its own?
auth.md is a registration protocol and AgentID is an identity provider, so they operate at different layers and can compose. The substantive difference is who ends up holding the account. Under auth.md the agent registers on behalf of a human and receives a token scoped to that human; under AgentID the agent is the account holder and the human travels as a separate claim the app can read.
What is auth.md?
auth.md is "a Markdown file an application hosts at its domain, typically https://yourapp.com/auth.md, that tells agents how to register on behalf of a user". An agent visiting a new service fetches the file, reads which flows the app supports, and registers. The credential the app issues is "a scoped access token tied to the user, short-lived and revocable".
The protocol defines two flows. "Agent verified is agent-attested: the agent's identity provider vouches for the user, no human in the loop. User claimed needs no provider: the agent shows the user a code, they sign in and confirm it." WorkOS authored the protocol but designed it to stand alone: "It's open. WorkOS authors the protocol, but auth.md isn't tied to WorkOS infrastructure."
In the agent verified flow, "the agent's provider, OpenAI, Anthropic, Cursor, or any trusted agent platform, attests to the user's identity at registration time." WorkOS is direct about the limit: the flow "only works when the agent's provider participates. Agents built on MCP servers or bare LLM APIs typically can't mint ID-JAGs, those need the user claimed flow." Apps also "take on the operational responsibility of curating which providers you trust."
It is thoroughly standards-based, and implementing it is real engineering. An app supporting auth.md hosts /oauth2/token (RFC 7523) and /oauth2/revoke (RFC 7009), accepts Security Event Tokens (RFC 8417), publishes Protected Resource Metadata (RFC 9728), maintains a trust list of agent providers, and implements a claim ceremony page for the user-claimed flow.
Adoption is real rather than theoretical. Cloudflare and Firecrawl were launch partners, per WorkOS CEO Michael Grinich. Resend adopted within the first week. Firecrawl is live with a spec-compliant implementation supporting the identity_assertion (ID-JAG) method only. The standards community has taken it seriously too: Aaron Parecki, Senior Director of Identity Standards at Okta, oauth.net maintainer and an OAuth 2.1 co-author, wrote that the agent verified flow is "exactly what I've been telling the agent platforms they should be doing".
What auth.md deliberately does not do is issue identities. It defines how an app describes its registration flows and how assertions are presented. Someone still has to make the assertion, which is where identity providers enter.
What is AgentID?
AgentID is a "Sign in with AgentID" button run by AgentMail: a standard OpenID Connect provider agents use to authenticate as themselves. Each sign-in returns an ES256-signed id_token with a stable subject and the agent's verified inbox address. The agent's own signing credential never leaves it; the app verifies fresh one-time signatures against published keys and never holds anything reusable.
The accountability layer is the registered tier: an application created in the AgentID console or with the CLI unlocks the owner_email scope, which arrives in the id_token and from the userinfo endpoint. If the agent isn't allowed to share its owner, the organization owner has to approve the sign-in, so the app never gets a token without the claim. Free for apps, both tiers.
Delegate or principal
This is the whole comparison, and it is a product decision rather than a technical one.
Under auth.md the agent is a delegate. It acts on behalf of a human, the registered identity is the human's, and the token it receives is scoped to that user. Accountability is structural: the human is the account, so there is never a question of who is responsible.
Under AgentID the agent is a principal. It has its own identity in the form of an email address, its own account, and its own inbox. The human is a separate claim, owner_email, that the app can read when it needs to. The agent holds its own credentials, receives its own receipts and support threads, and can invite the human to an organization later as a separate member.
Neither model is wrong. auth.md fits apps where the human is the customer and the agent is a tool they point at you. AgentID fits apps where the agent is a customer in its own right, with a human who is reachable if something goes wrong.
They also compose in a specific way. AgentID could act as the identity provider inside auth.md's agent verified flow: an AgentMail agent minting an ID-JAG that asserts its owner's identity to an auth.md-enabled app. That is architecturally consistent with both designs rather than something shipping today.
Side-by-side
| AgentID | WorkOS auth.md | |
|---|---|---|
| What it is | An OpenID Connect identity provider | A registration protocol apps host at /auth.md |
| Who is the account holder | The agent; the human is a claim | The human; the agent acts on their behalf |
| Human accountability | owner_email delivered in the id_token and /userinfo | Built in: the human is the registered user |
| Agent provider requirement | Any agent with an AgentMail inbox | Agent verified flow needs a participating provider (OpenAI, Anthropic, Cursor); MCP and bare API agents fall back to user claimed |
| Standards | OpenID Connect, ES256, PKCE S256, RFC 7591 | RFC 7523, RFC 7009, RFC 8417, RFC 9728, ID-JAG |
| What the app builds | Two config values in an existing OIDC client | /oauth2/token, /oauth2/revoke, event ingest, provider trust list, claim ceremony page |
| Usable without the other | Yes, through ordinary OIDC integration with no auth.md file involved | Yes, an auth.md file can describe flows that use other assertion sources |
| Live adopters | Turso, plus launch partners | Firecrawl, Resend (Cloudflare announced) |
| Relationship | Complementary: AgentID can serve as an identity provider inside the agent verified flow | |
When to choose auth.md
Choose auth.md when your app treats agents as extensions of human users, your users run agents on platforms that participate in ID-JAG, and you want the human to be the account holder. If your billing, support, and terms of service all assume a person on the other end, a protocol that keeps the person as the registered user fits your product rather than fighting it.
Budget for the build. Between the token and revocation endpoints, event ingest, the provider trust list, and the claim ceremony page, adopting auth.md is a set of new endpoints to run, plus the ongoing operational responsibility of deciding which agent providers you trust.
When to choose AgentID
Choose AgentID when you want the agent to have its own account, and when you want to support agents on any model or framework. That last point is the sharpest practical difference: WorkOS documents that agents built on MCP servers or bare LLM APIs typically cannot mint ID-JAGs and must fall back to the user-claimed flow, with its human confirmation step. Those agents can use AgentID directly, because the identity belongs to the agent rather than being vouched for by its platform.
The integration cost is also different in kind. Accepting AgentID is two configuration values in an OIDC client you already run, rather than a new set of endpoints to host and a trust list to curate.
Get started
Accept agent sign-ins today: add AgentID as a custom OIDC provider with issuer https://auth.agentid.com, or create an AgentID application for owner scopes. Guides for Clerk, Supabase, Auth0, and Better Auth are in the AgentID docs.
