WorkOS Launches auth.md Agent Registration to Turn Agent Traffic into Signups

# What this announcement is

WorkOS describes auth.md as an open protocol that lets software agents register users on behalf of people, removing the need for a browser signup designed for humans. The company says many agents hit human-facing signup pages and fail to complete them, producing lost signups. Publishing an auth.md file signals to agents how to register and which credential flows you accept.

# How auth.md works

auth.md is a Markdown file an application hosts at a predictable URL (typically https://yourapp.com/auth.md). It lists supported registration flows, available scopes, and instructions for agents to request credentials. An agent fetches that file, chooses a supported flow, and proceeds to register or claim a user according to the app's stated options.

• Agent verified: The agent's identity provider attests to the user, so the registration can proceed without the user performing an interactive sign-in. The agent supplies a verified identity assertion to your app.

# The credentials you issue

When an agent completes registration, your app issues a scoped access token tied to the user. These tokens are short-lived and revocable, and they are issued over standard OAuth so existing API authentication infrastructure can be reused. The short lifetime and scope help limit risk when agents act on behalf of users.

# Open protocol, not a proprietary vendor lock-in

WorkOS authors the auth.md spec, but the protocol itself is open. It composes existing OAuth standards such as Protected Resource Metadata and ID-JAG identity assertions. Any app can publish an auth.md file and any agent can read one without needing a WorkOS account or infrastructure, according to the announcement.

# Product friction and WorkOS's product path

WorkOS positions AuthKit as a one-click enablement path: enroll via the WorkOS dashboard and AuthKit will publish the auth.md file for your domain. The company also offers a provider guide for platforms whose agents act on behalf of users, and an apps guide for services that want agents to register users on behalf of their customers.

# Practical developer considerations

• Hosting location: Place auth.md at a standard, reachable URL on your app's domain so agents can fetch it.
• Flow choices: Decide which flows you will accept (agent verified, user claimed, or both) and list them in auth.md.
• Scopes and token lifecycle: Define concrete scopes you will issue and enforce short lifetimes and revocation hooks for issued tokens.

# Why this matters for product teams

Agent-driven integrations are increasingly common. If agents encounter a human-facing signup flow they cannot complete, they drop out and the app loses a potential user. Publishing auth.md lets agents proceed programmatically while keeping the app in control of what credentials are issued and for how long.

# Next steps for a team evaluating this

• Read the auth.md file format and sample files to confirm it fits your security model.
• Map existing OAuth scopes to the agent scopes you will expose and decide on token lifetime and revocation policy.
• Choose whether to self-host auth.md or enable AuthKit via the WorkOS dashboard for one-click publishing.

# Bottom line

auth.md provides a standard way for agents to discover how to register users for a given app and request limited, short-lived tokens. WorkOS offers AuthKit to publish that file for you, but the protocol is open and built on OAuth standards so it can be implemented independently.