WorkOS has published auth.md, an open protocol meant to let software agents register users for apps without sending a human through a conventional sign-up form. The company describes it as a Markdown file that an application hosts on its own domain, usually at /auth.md, where agents can discover how to create or claim access on a user’s behalf.
The pitch is straightforward: if agents are going to install tools, configure apps, or set up accounts for people, those agents need a way to prove who they represent and obtain scoped credentials without scraping a registration page like a caffeinated intern. WorkOS says auth.md gives apps a documented place to list supported registration flows, available scopes, and instructions for issuing credentials.
According to WorkOS, the protocol is not limited to its own infrastructure. The company says it authored the spec, but any app can publish an auth.md file and any agent can read one without a WorkOS account. WorkOS says the design uses existing OAuth standards, including Protected Resource Metadata and ID-JAG identity assertions.
How the registration flows work
WorkOS describes two supported flows: “agent verified” and “user claimed.” In the agent verified flow, the agent presents a verified identity assertion from its identity provider. WorkOS says that lets the agent’s provider vouch for the user without requiring the user to complete a live confirmation step.
The user claimed flow works differently. WorkOS says it does not require an agent identity provider. Instead, the agent shows the user a code, and the user signs in to the application and confirms that code. That gives the app a way to link the agent’s request to a user-controlled session.
In both cases, WorkOS says the application remains in control of which flows it accepts and what credentials it issues. The credential described by WorkOS is a scoped access token tied to the user. The company says the token is short-lived, revocable, and issued using standard OAuth, so applications can reuse their existing API authorization machinery rather than inventing a second agent-only auth system.
Who the spec is for
WorkOS is positioning auth.md at two groups. The first is application developers who want their services to be “agent-ready,” meaning an agent can register or request access on behalf of a customer. The second is identity providers or agent platforms whose agents act for users and need a way to present trustworthy assertions to applications.
The company is also tying auth.md to AuthKit, its authentication product. WorkOS says AuthKit customers can request early access to enable auth.md support on their accounts. That is the commercial on-ramp. The protocol itself, WorkOS says, is published separately and is intended to be implementable outside WorkOS.
The practical test will be adoption. A discovery file at a predictable URL is useful only if apps publish it and agents bother to read it. WorkOS has opened a listing process for applications that want to be included, but the current material does not identify existing adopters beyond inviting developers to add their apps.
This story draws on original reporting from auth.md.
