WorkOS auth.md agent registration is the identity company’s proposed way for an application to tell an AI agent how to create access for a user. WorkOS announced the open protocol on May 21, 2026, saying it is meant to replace the awkward ritual of sending an agent to a sign-up page built for a person with a browser.
The proposal is a Markdown file hosted by the application, generally at https://yourapp.com/auth.md. It describes the registration methods an app accepts, available permission scopes and the steps for obtaining and using a credential. WorkOS also specifies related endpoints, including /agent-auth, /agent-auth/claim and /agent-auth/claim/complete.
The point is discovery as much as registration. An agent that reaches a protected API can retrieve the service’s metadata, read the app’s instructions and select a supported enrollment route instead of trying to operate a human login screen. WorkOS says the protocol extends Protected Resource Metadata at /.well-known/oauth-protected-resource.
How does WorkOS auth.md agent registration work?
WorkOS describes two paths, and the distinction matters more than the “without a browser” pitch suggests.
Agent-verified registration: An agent provider that has identified its user signs an ID-JAG identity assertion stating that the agent acts for that user. The agent sends that assertion to the app, which verifies the provider’s signature and can issue credentials. WorkOS describes this route as requiring no human in the loop.
User-claimed registration: The agent receives or starts a registration, then presents the user with a six-digit one-time code. The user signs in to the service and confirms the code, binding the agent activity or credential to their account. This path does not depend on an identity provider, but it does require user participation.
For the second route, an app can hold credentials until the code is verified, according to WorkOS. It can also allow an anonymous start, issuing a credential with only the pre-claim permissions it chooses before the user completes the claim process. That is a product decision for the service operator, not a magic bypass around account ownership.
WorkOS says the resulting access tokens can be tied to a user, restricted in scope, short-lived and revocable, using OAuth. Those are features an implementing app can configure and enforce; the announcement does not establish how broadly the protocol works across agent providers or services.
WorkOS also says auth.md is not confined to its own infrastructure. The company authored the protocol and says any service can publish the file or any agent can read it without a WorkOS account. Its AuthKit customers can enable Agent Registration in the WorkOS dashboard, which WorkOS says publishes the file for that product’s integration.
WorkOS has separately argued that copying browser cookies or injecting stored passwords gives agents overly broad access and weakens auditability. That is the company’s assessment, rather than independent validation of auth.md’s security. The immediate, concrete claim is narrower: an app can publish machine-readable registration instructions and choose whether an agent’s provider or the user supplies the identity proof.
This story draws on original reporting from auth.md.
