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. This comparison is closer to a compatibility note than a fight.
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 completes registration either by presenting a verified identity assertion or by walking the user through a confirmation step. The app then issues a "scoped access token tied to the user, short-lived and revocable" through standard OAuth.
WorkOS authored the protocol but designed it to stand alone: "auth.md isn't tied to WorkOS infrastructure, it composes existing OAuth standards," specifically Protected Resource Metadata and ID-JAG identity assertions, and implementing it requires no WorkOS account. Adoption at launch spanned companies including Cloudflare, Firecrawl, and Resend. The protocol's discovery story mirrors what robots.txt did for crawlers: a well-known file that turns "how do I sign up here" from screen-scraping guesswork into a documented contract.
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: the protocol allows identity providers to attest to identity so agents can register without human verification steps.
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: one RFC 7591 registration call with an AgentMail API key unlocks the owner_email scope, served from the userinfo endpoint after the code exchange. When an agent has not granted owner visibility, sign-in fails with a 403 rather than returning a token without the claim. Free for apps, both tiers.
Protocol and provider
auth.md standardizes the question; AgentID is one way to answer it. An app's auth.md file says "here is how agents register here, and here is what proof I accept." An agent carrying an AgentID can present exactly that proof: a verifiable OIDC identity with a stable subject, a working email address, and (for apps that register) the owner's identity behind it. AgentID can plug into auth.md flows as an identity provider, so the accurate framing is potentially complementary rather than competitive.
An app could also adopt either without the other. AgentID sign-in works today through ordinary OIDC integration with no auth.md file involved, and an auth.md file can describe flows that use other assertion sources.
Side-by-side
| AgentID | WorkOS auth.md | |
|---|---|---|
| For | Apps accepting agent sign-ins; agents needing a portable identity | Apps that want to publish a machine-readable registration contract for agents |
| Cross-app support | Yes, one identity works at every app showing the button | Per-app files; the convention is shared, each app defines its own flows |
| Owner email support | Yes, owner_email scope for registered clients via userinfo | Not an identity system; owner identity depends on the asserting provider |
| Standards support | Standard OIDC: code flow + PKCE (S256), ES256, RFC 7591 | Composes OAuth standards: Protected Resource Metadata, ID-JAG |
| Pricing | Free for apps | Open protocol, free to implement, no WorkOS account required |
| Time to integrate | Minutes on an existing OIDC stack | Author and host a file; wire chosen flows into your signup path |
| Who owns the identity root | AgentMail inbox controlled by the agent's owner | None; the protocol defers identity to whoever asserts it |
When to choose auth.md
Adopt auth.md when your problem is discoverability and process: agents keep arriving at your signup flow, and you would rather hand them a documented contract than have them fumble through forms built for humans. It is open, vendor-neutral, and composes with the OAuth machinery you already run. It is also worth adopting defensively; a published file is a policy statement about how you want agents to behave, which beats detecting them after the fact.
Remember what it leaves open. The file describes flows; it does not verify anyone. The trust in an auth.md registration comes entirely from the assertion behind it.
When to choose AgentID
Choose AgentID when your problem is knowing who the agent is. A registration contract is only as good as the identity presented through it, and AgentID supplies that identity: stable across services, cryptographically verified at each sign-in, revocable by the owner, and carrying owner_email for apps that need accountability. For per-human limits, KYC pass-through, or organization allowlisting via the org claim, the identity layer is the part doing the work.
Since the two compose, the strongest setup for an agent-friendly app may be both: an auth.md file telling agents how to register, with AgentID accepted as the identity proof.
Get started
Accept agent sign-ins today: add AgentID as a custom OIDC provider with issuer https://auth.agentid.com, or register a client for owner scopes. Guides at auth.agentid.com/docs.
