agenticweb.wiki

auth.md

Last checked · 65 primary sources

Not to be confused with ACT-AUTH.md, the component-and-host authentication specification in actcore/act-spec, or with OAuth Client ID Metadata Documents (OAuth CIMD). For the IETF cross-domain identity-assertion grant used by auth.md's agent-verified flow, see Identity Assertion Authorization Grant (ID-JAG). For the underlying OAuth discovery metadata pair, see OAuth 2.0 Metadata for Agents (RFC 9728 / RFC 8414).

Overview

auth.md is an MIT-licensed open specification authored by WorkOS (workos/auth.md [1][2], https://workos.com/auth-md [6]) that defines how AI agents discover, register for, and obtain scoped credentials from a web service on a user's behalf without human sign-up forms or browser-based OAuth redirect screens ("A reference implementation of agentic registration — a protocol for agents to authenticate to services on behalf of users. Three roles: an agent acting for a user, an agent provider that mints identity assertions (ID-JAGs), and a service that accepts those assertions, when available, and issues credentials. If the agent is not associated with a user identity, or the agent provider does not support ID-JAGs, the service uses an RFC 8628-style claim ceremony to authenticate the agent instead.") [1][2][6][14]. On Overview — auth.md (https://workos.com/auth-md/docs), WorkOS explains that "At its core, auth.md is a small Markdown file an application hosts at its domain — typically https://service.example.com/auth.md. The file describes how agents register with that service, which flows it supports, the scopes it exposes, and what to do once registered. Because Markdown is plain text, the same file works as documentation for human integrators and as a discoverable runtime artifact for agents.", while The auth.md file — auth.md (https://workos.com/auth-md/docs/auth-md) specifies that "The structured Protected Resource Metadata (PRM) at /.well-known/oauth-protected-resource remains the authoritative source for endpoint URLs and supported flows; auth.md is the prose companion that points back at it." [7][8]. In v0.6.0 (10 June 2026), an unauthenticated API response returns HTTP 401 Unauthorized with a WWW-Authenticate: Bearer resource_metadata="..." header pointing to /.well-known/oauth-protected-resource (RFC 9728: OAuth 2.0 Protected Resource Metadata, "This specification defines a metadata format that an OAuth 2.0 client or authorization server can use to obtain the information needed to interact with an OAuth 2.0 protected resource." [52]), which links to /.well-known/oauth-authorization-server (RFC 8414: "This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities." [53]) containing an agent_auth object (skill, identity_endpoint, claim_endpoint, events_endpoint, identity_types_supported, and events_supported) [3][4][8][52][53].

The v0.6.0 specification (AUTH.md: "You are an agent. This service supports agentic registration: discover → register → (claim if needed) → exchange for an access_token → call API → handle revocation. Follow the steps in order; do not skip ahead." [3]) defines three registration types at POST /agent/identity (renamed from /agent/auth in v0.2.0), grouped into two high-level product flows (Agent verified and User claimed) that issue a service-signed ES256 identity_assertion JWT which the agent exchanges at /oauth2/token using the RFC 7523 JWT-bearer grant (urn:ietf:params:oauth:grant-type:jwt-bearer) for a short-lived access_token ("Separates the identity and credential surfaces. Registration now mints a service-signed identity_assertion that the agent exchanges for an access_token at a standard OAuth token endpoint, instead of having /agent/auth issue credentials directly.") [3][4][9][10][11]:

  1. identity_assertion (Agent verified flow with ID-JAG): On Agent verified — auth.md (https://workos.com/auth-md/docs/flows/verified) and For agent providers — auth.md (https://workos.com/auth-md/docs/agent-providers), "The agent's provider — OpenAI, Anthropic, Cursor, or any trusted agent platform — attests to the user's identity at registration time. Your service verifies the attestation and issues credentials synchronously, no human interaction required." and "Trusted agent providers — companies whose agents act on behalf of users (OpenAI, Anthropic, Cursor, and similar) — power the agent verified flow by asserting a user's identity to a downstream service. The artifact is an Identity Assertion JWT Authorization Grant (ID-JAG)." [9][12]. The assertion uses the IETF Identity Assertion JWT Authorization Grant (draft-ietf-oauth-identity-assertion-authz-grant-04, 21 May 2026: "This specification provides a mechanism for an application to use an identity assertion to obtain an access token for a third-party API by coordinating through an identity provider that the downstream Resource Authorization Server already trusts for single sign-on (SSO), using Token Exchange [RFC8693] and JWT Profile for OAuth 2.0 Authorization Grants [RFC7523]. This pattern is informally referred to as Cross-App Access (XAA)." [56]) with assertion_type: "urn:ietf:params:oauth:token-type:id-jag" [3][9][56]. Since v0.5.0 (5 June 2026), /agent/identity enforces fresh auth_time (401 login_required) and requires a one-time RFC 8628-shaped confirmation ceremony (401 interaction_required, modeled on RFC 8628 [54]) before linking a new (iss, sub) provider delegation to an existing user account: "Gates first-time linking of an ID-JAG to an existing account behind a user-confirmation ceremony, and requires fresh auth_time on every ID-JAG. Without this confirmation gate, any trusted provider could mint an ID-JAG with email_verified: true for a victim's email and silently take over their account. Without the freshness gate, an agent could use a stale upstream session." [4][54]. Provider-initiated revocation uses RFC 8417 Security Event Tokens (application/secevent+jwt with schema https://schemas.workos.com/events/agent/auth/identity/assertion/revoked) pushed to events_endpoint (/agent/event/notify) per RFC 8935 ("Switches the provider-driven invalidation channel from OIDC Back-Channel Logout to RFC 8417 Security Event Token push delivery per RFC 8935. Same trust path as before (issuer JWKS, jti replay protection), with a wire format and event shape that generalizes beyond revocation.") [4].
  2. service_auth (User claimed flow with login_hint): Separated from identity_assertion in v0.6.0 (10 June 2026): "Splits the email-based registration path out from identity_assertion and into a top-level service_auth registration type, with a body modeled on OIDC CIBA's login_hint. The previous shape was honest about how it worked — the service was verifying the email, not the agent — but it was filed under identity_assertion like the agent was asserting something. CIBA's vocabulary fits: the agent is hinting at who the user is, and the service authenticates the user out-of-band." [4]. The agent sends { "type": "service_auth", "login_hint": "<email>" } to /agent/identity, receives a claim_token plus a claim block (user_code and verification_uri), displays the code and URL to the user (since v0.4.0 on 4 June 2026: "Inverts the claim ceremony and consolidates polling onto the standard /oauth2/token endpoint. Service emails have been removed in favor of the agent surfacing the verification URL and user_code to the user, who signs in through the service's own browser-based session (reusing any existing session, SSO, MFA the service applies) and confirms the code on a service-owned page. This borrows the ceremony shape from RFC 8628 device authorization (user_code, verification_uri, expires_in, interval) without overloading the IANA device_code grant."), and polls /oauth2/token with grant_type: "urn:workos:agent-auth:grant-type:claim" until the user signs in on the service's page and confirms the code [3][4][10].
  3. anonymous (User claimed flow with pre-claim scopes): On User claimed — auth.md (https://workos.com/auth-md/docs/flows/claimed), "The agent registers without a provider-attested identity; the user claims it by signing in to your service and confirming a code the agent shows them. No agent-provider participation — just the app and the user." [10]. The agent posts { "type": "anonymous" } to /agent/identity, immediately receives a pre-claim identity_assertion restricted to pre_claim_scopes, and can later invoke POST /agent/identity/claim to upgrade the registration to full user-bound scopes [3][4][10].

Governance and Disambiguation (auth-md.com, ACT-AUTH.md, and CIMD)

Who uses it

Every live /auth.md and /.well-known/oauth-authorization-server endpoint below was fetched and verified (HTTP 200) on 29 October 2026. Inspecting the live documents shows a clear distinction between services running the workos/auth.md registration endpoints (v0.6.0 /agent/identity or v0.1.0 /agent/auth), services exposing custom agent onboarding recipes at /auth.md, and launch partners hosting /auth.md as an out-of-band or coming-soon guidance file:

Who reads it

Recent coverage

See also

References

  1. WorkOS (`workos/auth.md`). `README.md` (`auth.md` reference implementation of agentic registration, checked 29 October 2026): "A reference implementation of agentic registration — a protocol for agents to authenticate to services on behalf of users. Three roles: an agent acting for a user, an agent provider that mints identity assertions (ID-JAGs), and a service that accepts those assertions, when available, and issues credentials. If the agent is not associated with a user identity, or the agent provider does not support ID-JAGs, the service uses an RFC 8628-style claim ceremony to authenticate the agent instead." — https://raw.githubusercontent.com/workos/auth.md/main/README.md
  2. GitHub REST API. `workos/auth.md` repository metadata (created 20 May 2026, MIT License, checked 29 October 2026): ""full_name": "workos/auth.md"" ""spdx_id": "MIT"" — https://api.github.com/repos/workos/auth.md
  3. WorkOS (`workos/auth.md`). `AUTH.md` (reference procedural manifest for agentic registration, checked 29 October 2026): "You are an agent. This service supports agentic registration: discover → register → (claim if needed) → exchange for an access_token → call API → handle revocation. Follow the steps in order; do not skip ahead." — https://raw.githubusercontent.com/workos/auth.md/main/AUTH.md
  4. WorkOS (`workos/auth.md`). `CHANGELOG.md` (`v0.1.0` dated 21 May 2026 through `v0.6.0` dated 10 June 2026): "Separates the identity and credential surfaces. Registration now mints a service-signed identity_assertion that the agent exchanges for an access_token at a standard OAuth token endpoint, instead of having /agent/auth issue credentials directly." "Gates first-time linking of an ID-JAG to an existing account behind a user-confirmation ceremony, and requires fresh auth_time on every ID-JAG. Without this confirmation gate, any trusted provider could mint an ID-JAG with email_verified: true for a victim's email and silently take over their account. Without the freshness gate, an agent could use a stale upstream session." "Switches the provider-driven invalidation channel from OIDC Back-Channel Logout to RFC 8417 Security Event Token push delivery per RFC 8935. Same trust path as before (issuer JWKS, jti replay protection), with a wire format and event shape that generalizes beyond revocation." "Splits the email-based registration path out from identity_assertion and into a top-level service_auth registration type, with a body modeled on OIDC CIBA's login_hint. The previous shape was honest about how it worked — the service was verifying the email, not the agent — but it was filed under identity_assertion like the agent was asserting something. CIBA's vocabulary fits: the agent is hinting at who the user is, and the service authenticates the user out-of-band." "Inverts the claim ceremony and consolidates polling onto the standard /oauth2/token endpoint. Service emails have been removed in favor of the agent surfacing the verification URL and user_code to the user, who signs in through the service's own browser-based session (reusing any existing session, SSO, MFA the service applies) and confirms the code on a service-owned page. This borrows the ceremony shape from RFC 8628 device authorization (user_code, verification_uri, expires_in, interval) without overloading the IANA device_code grant." — https://raw.githubusercontent.com/workos/auth.md/main/CHANGELOG.md
  5. WorkOS (`workos/auth.md`). `package.json` (`version: 0.6.0`, checked 29 October 2026): ""version": "0.6.0"" — https://raw.githubusercontent.com/workos/auth.md/main/package.json
  6. WorkOS. auth.md — Open Protocol for Agent Registration (official landing page, checked 29 October 2026): "WorkOS authors the protocol, but auth.md isn't tied to WorkOS infrastructure — it composes existing OAuth standards (Protected Resource Metadata, ID-JAG identity assertions) and any app can publish or any agent can read one with no WorkOS account required." — https://workos.com/auth-md
  7. WorkOS. Overview — auth.md (official documentation overview, checked 29 October 2026): "At its core, auth.md is a small Markdown file an application hosts at its domain — typically https://service.example.com/auth.md. The file describes how agents register with that service, which flows it supports, the scopes it exposes, and what to do once registered. Because Markdown is plain text, the same file works as documentation for human integrators and as a discoverable runtime artifact for agents." — https://workos.com/auth-md/docs
  8. WorkOS. The auth.md file — auth.md (file anatomy and agent parsing contract, checked 29 October 2026): "The structured Protected Resource Metadata (PRM) at /.well-known/oauth-protected-resource remains the authoritative source for endpoint URLs and supported flows; auth.md is the prose companion that points back at it." "Agents are expected to treat auth.md as both prose and structured data: Scan headings to find sections relevant to the current step (registration vs. operation). Read the Discovery section first to learn which flows are supported before committing to one. Extract code blocks as templates for HTTP requests. Use fenced blocks with language hints (http, json) so the agent can identify request shapes without ambiguity. Treat the PRM as authoritative if anything in this file conflicts with it. The PRM is the runtime source of truth." — https://workos.com/auth-md/docs/auth-md
  9. WorkOS. Agent verified — auth.md (ID-JAG agent-verified flow documentation, checked 29 October 2026): "The agent's provider — OpenAI, Anthropic, Cursor, or any trusted agent platform — attests to the user's identity at registration time. Your service verifies the attestation and issues credentials synchronously, no human interaction required." — https://workos.com/auth-md/docs/flows/verified
  10. WorkOS. User claimed — auth.md (`anonymous` and `service_auth` user-claimed flow documentation, checked 29 October 2026): "The agent registers without a provider-attested identity; the user claims it by signing in to your service and confirming a code the agent shows them. No agent-provider participation — just the app and the user." — https://workos.com/auth-md/docs/flows/claimed
  11. WorkOS. For apps — auth.md (service integration guide, checked 29 October 2026): "Services that want agents to authenticate on behalf of users publish discovery metadata and implement the /agent/identity registration endpoint plus the standard OAuth /oauth2/token and /oauth2/revoke endpoints described here. There are two flows to choose from — agent verified and user claimed — and a service may support either or both." — https://workos.com/auth-md/docs/apps
  12. WorkOS. For agent providers — auth.md (agent identity provider guide, checked 29 October 2026): "Trusted agent providers — companies whose agents act on behalf of users (OpenAI, Anthropic, Cursor, and similar) — power the agent verified flow by asserting a user's identity to a downstream service. The artifact is an Identity Assertion JWT Authorization Grant (ID-JAG)." — https://workos.com/auth-md/docs/agent-providers
  13. WorkOS. Agent Registration – AuthKit – WorkOS Docs (AuthKit production documentation, checked 29 October 2026): "Agent Registration is generally available. It enables AI agents and LLM-based clients to obtain identity credentials from your AuthKit-powered service. Unlike traditional OAuth flows designed for users in a browser, Agent Registration is purpose-built for programmatic clients that need machine-readable instructions, minimal interaction, and secure credential management. Agents discover the registration surface through your service's.well-known/oauth-authorization-server metadata, register with one of several identity types, optionally bind to a user via a claim ceremony, and exchange the resulting identity assertion for an access token or API key." — https://workos.com/docs/authkit/agent-registration
  14. Garrett Galow (WorkOS). Agent Registration with Auth.md — WorkOS (21 May 2026): "Today we're releasing auth.md — an open protocol that tells agents how to register for your service via a Markdown file published on your domain." "A document — plain Markdown, hosted at https://yourservice.com/auth.md. Agents parse it like llms.txt or agents.md: headings to navigate, fenced code blocks to extract request shapes, prose to disambiguate. A protocol — a small set of HTTP endpoints (/agent-auth, /agent-auth/claim, /agent-auth/claim/complete) that agents use to register for services on behalf of users. Once registered agents use standard credentials to access the service." — https://workos.com/blog/agent-registration-with-auth-md
  15. Zack Proser (WorkOS). MCP Night 4 recap: agent auth, auth.md, and the rise of agentic registration — WorkOS (25 May 2026): "WorkOS announced Auth.md, a spec for letting agents register and sign up for services, and demoed it live with Cloudflare and Firecrawl." "Auth.md is a spec, not an IETF-ratified standard — please don't bring the pitchforks. It's a set of ideas that lets you expose your application to agents so they can register, sign up, and start using it. Not as spam. Not as a fake human. As an agent acting as a first-class user." — https://workos.com/blog/mcp-night-4-recap-auth-md-agentic-registration
  16. Zack Proser (WorkOS). auth.md — One week later: who's shipped, who's writing, what's next — WorkOS (28 May 2026): "Spec-compliant auth.md files appeared on real domains within hours, the launch partners who helped build the demo posted their own takes, and a widening circle of agent and identity tools started converging on the same primitive." — https://workos.com/blog/auth-md-one-week-later
  17. Zack Proser (WorkOS). Lifestyles of the AI-Native: WorkOS at the AI Engineer World's Fair 2026 — WorkOS (7 July 2026): "Michael re-introduced auth.md, an open protocol that lets agents register and authenticate users without sign-up forms, and shares what early implementers have learned since launch." — https://workos.com/blog/workos-aie-worlds-fair-2026-recap
  18. Maria Paktiti (WorkOS). How an MCP client should tell your OAuth server who it is — WorkOS (12 August 2026): "Client identity answers which piece of software is this. User delegation answers on whose authority is it acting, and what may it do. DCR and CIMD only do the first." "And auth.md, the open agent-registration protocol we published in May, went live inside AuthKit as Agent Registration on August 4." — https://workos.com/blog/mcp-client-identity-dcr-cimd-auth-md
  19. Fabricio Telles (`auth-md.com`). AI Agent Registration Protocol for Web — auth-md (independent community hub, checked 29 October 2026): "Protocol authored by WorkOS under MIT License. This is an independent community resource." — https://auth-md.com/
  20. Fabricio Telles (`auth-md.com`). `/auth.md` on `auth-md.com` (checked 29 October 2026): "auth-md.com is an independent community resource about the auth.md protocol — the open standard that lets AI agents register for web services on behalf of users." — https://auth-md.com/auth.md
  21. Fabricio Telles (`auth-md.com`). auth.md Protocol Specification — Complete Technical Reference (community technical rendering, June 2026): "CIMD — Claim Interception Mitigation by Design The email field on anonymous /agent/identity/claim binds the registration to the intended human — only that signed-in user can complete the ceremony. Without this, a third party who intercepted the user_code could claim the agent for themselves." — https://auth-md.com/specification/
  22. Fabricio Telles. Como construí o auth-md.com em um fim de … | Fabricio Telles (24 May 2026): "A WorkOS lançou o protocolo auth.md e encontrei livre o domínio auth-md.com. Registrei, e no mesmo dia comecei a construir." — https://ft.ia.br/insights/auth-md-como-construi/
  23. Fabricio Telles (`fabricioctelles/skills`). `skills/auth-md/SKILL.md` (`version 2.1`, dated 20 September 2026, Apache-2.0): "Generate, validate, and explain auth.md files — the open protocol for AI agent registration." — https://raw.githubusercontent.com/fabricioctelles/skills/main/skills/auth-md/SKILL.md
  24. Tuist. `https://tuist.dev/auth.md` (live `auth.md` manifest for the Tuist MCP server, checked 29 October 2026): "Tuist implements the current [WorkOS auth.md protocol](https://workos.com/auth-md) for the [Model Context Protocol](https://modelcontextprotocol.io) server at `https://tuist.dev/mcp`. Follow the discovered endpoints and the sequence below. Registration returns a signed identity assertion, not an access token. Exchange that assertion at the discovered token endpoint before calling the Model Context Protocol server." — https://tuist.dev/auth.md
  25. Tuist. `/.well-known/oauth-authorization-server` (live RFC 8414 metadata with `agent_auth` v0.6.0 block, checked 29 October 2026): ""identity_endpoint":"https://tuist.dev/agent/identity","identity_types_supported":["anonymous","identity_assertion","service_auth"]" — https://tuist.dev/.well-known/oauth-authorization-server
  26. Tuist. Sign agents in with auth.md (Tuist Changelog, 27 May 2026): "Tuist now supports auth.md, the open agent registration specification. Agents that implement the standard can connect to the Tuist MCP server directly: depending on the agent, Tuist either confirms the registration with the agent provider, or emails you a secure link with a six-digit code to read back to the agent. No browser-based OAuth round-trip required." — https://tuist.dev/changelog/2026.05.27-auth-md
  27. Firecrawl. `https://www.firecrawl.dev/auth.md` (live `auth.md` manifest for WorkOS ID-JAG registration, checked 29 October 2026): "You are an agent. Firecrawl supports agentic registration for WorkOS ID-JAG identity assertions: discover -> register -> call API. Follow the steps in order; do not skip ahead. Firecrawl currently supports one registration method: - `identity_assertion` with `assertion_type: "urn:ietf:params:oauth:token-type:id-jag"` - `requested_credential_type: "api_key"` - Credentials are Firecrawl API keys used as bearer tokens." — https://www.firecrawl.dev/auth.md
  28. Firecrawl. `/.well-known/oauth-authorization-server` (live RFC 8414 metadata with `agent_auth` block, checked 29 October 2026): ""agent_auth":{"skill":"https://www.firecrawl.dev/auth.md","register_uri":"https://www.firecrawl.dev/agent/auth","revocation_uri":"https://www.firecrawl.dev/agent/auth/revoke","identity_types_supported":["identity_assertion"],"identity_assertion":{"assertion_types_supported":["urn:ietf:params:oauth:token-type:id-jag"],"credential_types_supported":["api_key"]}" — https://www.firecrawl.dev/.well-known/oauth-authorization-server
  29. Alpic. `https://alpic.ai/auth.md` (live `auth.md` manifest for MCP server deployment, checked 29 October 2026): "Alpic supports agentic registration. If you are an AI agent acting on behalf of a user, you can obtain an Alpic API key without a human filling in a sign-up form, then use it to deploy and manage MCP servers (e.g. `alpic deploy`)." — https://alpic.ai/auth.md
  30. Alpic. `https://api.alpic.ai/.well-known/oauth-authorization-server` (live `agent_auth` metadata, checked 29 October 2026): ""agent_auth":{"skill":"https://alpic.ai/auth.md","register_uri":"https://api.alpic.ai/agent/auth","identity_types_supported":["identity_assertion"],"identity_assertion":{"assertion_types_supported":["urn:ietf:params:oauth:token-type:id-jag","urn:ietf:params:oauth:token-type:jwt"],"credential_types_supported":["api_key"]}}}" — https://api.alpic.ai/.well-known/oauth-authorization-server
  31. agents-txt.com. `https://agents-txt.com/auth.md` (live `auth.md` walkthrough advertised under `Authorization: auth-md`, checked 29 October 2026): "This deployment hosts the [agents.txt](https://agents-txt.com) reference site. The agentic-registration walkthrough below is a working example of the [auth.md](https://github.com/workos/auth.md) shape advertised in `/agents.txt` under `Authorization: auth-md`. The OAuth metadata pair (`/.well-known/oauth-protected-resource` + `/.well-known/oauth-authorization-server`) is the same one used by the [`oauth2`](/spec#112-oauth2--oauth-20) protocol on this site; the additional `agent_auth` block on the AS metadata is what activates this flow." — https://agents-txt.com/auth.md
  32. agents-txt.com. `/.well-known/oauth-authorization-server` (live `agent_auth` metadata, checked 29 October 2026): ""agent_auth":{"skill":"https://agents-txt.com/auth.md","register_uri":"https://agents-txt.com/agent/auth","claim_uri":"https://agents-txt.com/agent/auth/claim","revocation_uri":"https://agents-txt.com/agent/auth/revoke","identity_types_supported":["anonymous","identity_assertion"]" — https://agents-txt.com/.well-known/oauth-authorization-server
  33. mailbox.bot. `https://mailbox.bot/auth.md` (live `auth.md` manifest for physical postal mail API, checked 29 October 2026): "This document describes agent registration for mailbox.bot, a live physical postal mail API at https://mailbox.bot. Protected REST resources live under https://mailbox.bot/api and agent registration lives on the same authorization server. Registration is intentionally guarded: agents can discover the service and request a human-approved claim by email, but live order placement spends prepaid mailbox.bot credits owned by the human operator and requires human-owned onboarding and scoped credentials." — https://mailbox.bot/auth.md
  34. mailbox.bot. `/.well-known/oauth-authorization-server` (live `agent_auth` metadata with `user_claimed_email_required` flow, checked 29 October 2026): ""current_flow":"user_claimed_email_required","identity_types_supported":["identity_assertion"],"anonymous":{"enabled":false,"reason":"Anonymous registration is not enabled because mailbox.bot can place physical mail orders and spend prepaid operator credits."}" — https://mailbox.bot/.well-known/oauth-authorization-server
  35. WorkOS. `https://workos.com/auth.md` (live `auth.md` manifest for WorkOS one-shot environments, checked 29 October 2026): "This document tells you how to register a credential for *WorkOS one-shot environments — temporary, anonymous WorkOS environments you can provision without an account and (optionally) have the user claim later to make permanent. Follow the steps in order; do not skip ahead. This is the user claimed* flow: provision anonymously, work immediately, claim when the user is available. There is no agent-verified or email-verified registration today." — https://workos.com/auth.md
  36. PostHog. `https://us.posthog.com/auth.md` (live `auth.md` manifest, checked 29 October 2026): "Available on the Enterprise plan with XAA enabled, and currently in beta, so most clients should use one of the options above. With it configured, an agent presents an [ID-JAG](https://xaa.dev) identity assertion (`identity_assertion`) to the token endpoint using the JWT-bearer grant" — https://us.posthog.com/auth.md
  37. PostHog. Agent discovery (auth.md) - Docs - PostHog (documentation, checked 29 October 2026): "PostHog publishes machine-readable metadata so AI agents can discover how to authenticate and create accounts, with no PostHog-specific SDK and no hardcoded endpoints." — https://posthog.com/docs/settings/agent-discovery
  38. here.now. `https://here.now/auth.md` (live `auth.md` manifest for email-code API key provisioning, checked 29 October 2026): "here.now supports agent-assisted API key creation with an email code. It does not currently support agent-verified ID-JAG registration, OAuth client registration, MCP auth, or third-party identity provider assertions." — https://here.now/auth.md
  39. HeadlessDomains. `https://headlessdomains.com/auth.md` (live `auth.md` manifest, checked 29 October 2026): "HeadlessDomains supports agent-native authentication for autonomous domain registration, renewal, profile updates, and DNS-linked identity operations." — https://headlessdomains.com/auth.md
  40. NanoGPT. `https://nano-gpt.com/auth.md` (live `auth.md` manifest, checked 29 October 2026): "NanoGPT supports agent and app access through user-approved API keys. OAuth-aware clients should use authorization-code + PKCE. Agents can also use the browser-approved device login flow for CLI-style handoff." — https://nano-gpt.com/auth.md
  41. WebClaw. `https://webclaw.io/auth.md` (live `auth.md` manifest, checked 29 October 2026): "webclaw supports OAuth 2.0 Device Authorization for agent onboarding. Agents can request a short-lived scoped bearer token, show the user a code, and wait while the user approves the request in the browser." — https://webclaw.io/auth.md
  42. Particle Pro. `https://api.particle.pro/auth.md` (live `auth.md` manifest, checked 29 October 2026): "There is *no anonymous agent self-registration*: every credential is tied to a human-owned platform account (the API is paid). The fastest path for a fully headless agent is to ask your operator for an API key from https://platform.particle.pro/tokens. An agent with no operator at all can still call the API by paying per request with x402" — https://api.particle.pro/auth.md
  43. Cloudflare. `https://www.cloudflare.com/auth.md` (live `/auth.md` guidance file, checked 29 October 2026): "Cloudflare is working toward auth.md registration support, including the ID-JAG `identity_assertion` flow. This file exists at `https://cloudflare.com/auth.md` so agents can discover what is coming soon and use supported Cloudflare authentication paths safely today. ## auth.md Registration Cloudflare does not yet advertise production auth.md registration methods, auth.md Protected Resource Metadata, or agent-auth metadata. Do not mint ID-JAGs or attempt `identity_assertion`, `service_auth`, or `anonymous` auth.md registration against Cloudflare until this file links to production discovery metadata." — https://www.cloudflare.com/auth.md
  44. Resend. `https://resend.com/auth.md` (live `/auth.md` guidance file, checked 29 October 2026): "Resend does not support agentic registration today. Credentials are issued by the user out of band; this file tells you how to pick them up and use them without putting them at risk." — https://resend.com/auth.md
  45. Ora. `https://ora.ai/auth.md` (live `/auth.md` guidance file, checked 29 October 2026): "This file lives at `/auth.md`, the conventional discovery path from the WorkOS auth.md spec (https://github.com/workos/auth.md). Ora does not implement that spec's registration machinery; this file documents what ora implements and what it deliberately does not." — https://ora.ai/auth.md
  46. PAX AI (`ax-platform/ax-platform-mcp`). `README.md` (Hermes and shell-agent onboarding via `auth.md`, checked 29 October 2026): "Give a Hermes agent, or the next serious shell-capable agent harness, https://paxai.app/auth.md; it can learn the device-code flow, show you the approval code, store refreshable credentials, and join the aX network on a named MCP route." — https://raw.githubusercontent.com/ax-platform/ax-platform-mcp/main/README.md
  47. PAX AI. Implementing auth.md for MCP agents: field notes from a live platform — aX blog (10 June 2026): "We shipped an auth.md instruction file to solve the first half of that problem — how an agent finds out how to connect —" — https://paxai.app/blog/implementing-auth-md-for-mcp-agents/
  48. Storewalk. TRX-009 auth.md agent registration guide published — Storewalk (check documentation, checked 29 October 2026): "We check that /auth.md exists, is a Markdown document rather than your storefront page, and opens with a heading that names auth.md." — https://storewalk.ai/checks/TRX-009
  49. AgentReady. Auth documentation — check | AgentReady (`usability.auth-docs` methodology, checked 29 October 2026): "Looked for /auth.md or an authentication docs page with code examples." — https://agentready-rho.vercel.app/methodology/usability.auth-docs
  50. ACT Specification (`actcore/act-spec`). `spec/ACT-AUTH.md` (`ACT Authentication`, normative `v0.4.0`, checked 29 October 2026): "This document specifies how authentication is handled in ACT. It covers two independent layers: 1. Component-to-external auth — credentials a component uses to authenticate with external services (databases, APIs). Normative; primary subject of this document. 2. Client-to-host auth — how a client (agent, CLI, browser) authenticates to the ACT host. Normative for HTTP transports; informative for stdio." — https://raw.githubusercontent.com/actcore/act-spec/main/spec/ACT-AUTH.md
  51. GitHub REST API. `better-auth/agent-auth-protocol` repository metadata (checked 29 October 2026): ""full_name": "better-auth/agent-auth-protocol"" — https://api.github.com/repos/better-auth/agent-auth-protocol
  52. Michael B. Jones, Phil Hunt, and Aaron Parecki. RFC 9728: OAuth 2.0 Protected Resource Metadata (IETF Standards Track, April 2025): "This specification defines a metadata format that an OAuth 2.0 client or authorization server can use to obtain the information needed to interact with an OAuth 2.0 protected resource." — https://www.rfc-editor.org/rfc/rfc9728.html
  53. Michael B. Jones, Nat Sakimura, and John Bradley. `RFC 8414: OAuth 2.0 Authorization Server Metadata` (IETF Standards Track, June 2018): "This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities." — https://www.rfc-editor.org/rfc/rfc8414.html
  54. William Denniss, John Bradley, Michael B. Jones, and Hannes Tschofenig. `RFC 8628: OAuth 2.0 Device Authorization Grant` (IETF Standards Track, August 2019): "The OAuth 2.0 device authorization grant is designed for Internet-connected devices that either lack a browser to perform a user-agent-based authorization or are input constrained to the extent that requiring the user to input text in order to authenticate during the authorization flow is impractical." — https://www.rfc-editor.org/rfc/rfc8628.html
  55. Justin Richer, Michael B. Jones, John Bradley, Maciej Machulak, and Phil Hunt. `RFC 7591: OAuth 2.0 Dynamic Client Registration Protocol` (IETF Standards Track, July 2015): "This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers." — https://www.rfc-editor.org/rfc/rfc7591.html
  56. Aaron Parecki, Karl McGuinness, and Brian Campbell. Identity Assertion JWT Authorization Grant (`draft-ietf-oauth-identity-assertion-authz-grant-04`, IETF OAuth Working Group Internet-Draft, 21 May 2026): "This specification provides a mechanism for an application to use an identity assertion to obtain an access token for a third-party API by coordinating through an identity provider that the downstream Resource Authorization Server already trusts for single sign-on (SSO), using Token Exchange [RFC8693] and JWT Profile for OAuth 2.0 Authorization Grants [RFC7523]. This pattern is informally referred to as Cross-App Access (XAA)." — https://www.ietf.org/archive/id/draft-ietf-oauth-identity-assertion-authz-grant-04.html
  57. Aaron Parecki and Emelia Smith. OAuth Client ID Metadata Document (`draft-ietf-oauth-client-id-metadata-document-02`, IETF OAuth Working Group Internet-Draft, 6 July 2026): "This specification defines a mechanism through which an OAuth client can identify itself to authorization servers, without prior dynamic client registration or other existing registration." — https://www.ietf.org/archive/id/draft-ietf-oauth-client-id-metadata-document-02.html
  58. Sid Chatterjee, Celso Martinho, and Brendan Irvine-Broque (Cloudflare). Temporary Cloudflare Accounts for AI agents | Cloudflare Blog (19 June 2026): "Last month, we collaborated with WorkOS on the launch of auth.md, which anyone can adopt, to let agents provision new accounts using well-established, existing OAuth standards." — https://blog.cloudflare.com/temporary-accounts/
  59. John Gruber. Daring Fireball: WorkOS Launches Auth.md -- an Open Protocol for Agent Registration (15 June 2026): "By exposing a single, machine-readable Markdown file at your service root, AI agents can dynamically discover your OAuth Protected Resource Metadata, parse required scopes, and authenticate seamlessly." — https://daringfireball.net/linked/2026/06/15/workos-authmd
  60. Martyn Davies (Zuplo). How auth.md Standardises Agent Signup - Zuplo (28 May 2026): "auth.md, a new open protocol shaped by the folks at WorkOS, attempts to start the process of removing that wall. It's a Markdown file an app hosts at its domain walking an agent through registering for a credential, claiming it against a real user, and using it against the API." — https://zuplo.com/blog/auth-md-agent-signup
  61. Uchi Uchibeke. auth.md Solves Agent Registration. What About Authorization? | Uchi Uchibeke (30 August 2026): "auth.md solves agent registration (who gets credentials), not runtime authorization (what each action is allowed to do)" — https://uchibeke.com/auth-md-solves-agent-registration-what-about-authorization/
  62. Thiago Victorino. auth.md and the OAuth Lineage Move for Agent Registration | Victorino Group (28 May 2026): "A service drops a Markdown file at service.com/auth.md, exposes two well-known endpoints, and any compliant agent can discover how to register, get credentials, and revoke them." — https://victorinollc.com/thinking/workos-auth-md-open-agent-registration
  63. GitHub REST API. `workos/auth.md` Pull Request #20 (`agent-services: Preserve login_hint when re-minting id_jag claim`): ""number": 20, "state": "closed", "locked": false, "title": "agent-services: Preserve login_hint when re-minting id_jag claim", "user": { "login": "devin-ai-integration[bot]"," — https://api.github.com/repos/workos/auth.md/pulls/20
  64. GitHub REST API. `workos/auth.md` Pull Request #21 (`Revoke registration and delegation on provider SET`, merged 23 July 2026): ""number": 21, "state": "closed", "locked": false, "title": "Revoke registration and delegation on provider SET", "user": { "login": "devin-ai-integration[bot]"," — https://api.github.com/repos/workos/auth.md/pulls/21
  65. GitHub REST API. `workos/auth.md` Issue #24 (`Conformance report from a second implementation (id.org.ai)` by `nathanclevenger`): ""number": 24," ""title": "Conformance report from a second implementation (id.org.ai): two stale bits in the spec, and a question about trust-list discovery"," ""login": "nathanclevenger"," — https://api.github.com/repos/workos/auth.md/issues/24

JSON · Markdown · OKF v0.2