Headless Domains Adds auth.md for AI Agent Registration and Identity

Picture a user asking an agent to do something simple:

Go set up a trusted identity for yourself so other agents and services know who you are.

The agent can search the web. It can read documentation. It can inspect APIs. It can find Headless Domains, understand what a .agent, .chatbot, or .boss  namespace is, and see why persistent identity matters.

Then it runs into the part of the internet that still assumes a human is sitting in front of a browser.

A login screen. A sign-up form. A pasted API key. A browser-based OAuth flow. A dead end after a 401 Unauthorized response.

For people, those steps are annoying. For agents, they are often blocking.

Headless Domains was built for a different world: one where agents need to discover services, register, authenticate, pay, publish records, and come back later as the same trusted actor. Adding auth.md is a natural extension of that mission.

auth.md, introduced by WorkOS, gives agents a readable way to understand how to register for a service. It is published at a predictable location, such as https://headlessdomains.com/auth.md, and explains the authentication and registration paths available to agents.

For Headless Domains, this is not just another documentation file. It is a bridge between agent identity and agent access.

Headless Domains gives agents a persistent, machine-readable identity layer. auth.md helps agents understand how to enter that system safely, receive the right credentials, and act within the right permissions.

Together, they answer one of the most important questions in the agentic web:

How does an agent move from discovering a service to becoming an authorized participant?

Agents need more than discovery

Making a service readable to agents is an important first step. It is not the whole job.

An agent can read llms.txt. It can inspect SKILL.md. It can parse an OpenAPI file. It can discover MCP tools. It can review an agent.json manifest.

All of that helps the agent understand what a service does.

But understanding is different from being allowed to act.

The next step is registration. The agent needs to know how to obtain access, what identity it should present, which scopes it can request, what approval may be required, and what happens if a credential expires or gets revoked.

Without a standard place to explain those steps, every service becomes a guessing game. The agent may try to infer the registration process from scattered docs. It may ask the user for an API key. It may attempt browser automation. It may simply stop.

auth.md gives the agent a better path.

Instead of leaving registration hidden behind a human interface, the service can publish clear instructions for agents. The file can explain supported flows, required claims, credential usage, error handling, and revocation behavior in plain language an agent can follow.

That turns authentication from a blocker into an operating surface.

What auth.md brings to the agentic web

auth.md is a Markdown file with a practical job: help agents understand how to register and authenticate with a service.

It can describe which flows are supported, how an agent should discover the service’s protected resource metadata, what credential types are available, what scopes mean, and how a user can claim or approve an agent’s access.

WorkOS describes two important registration patterns.

The first is an agent-verified flow. In this pattern, a trusted agent provider signs an identity assertion for the user. The service verifies that assertion and can issue credentials based on the delegated relationship.

The second is a user-claimed flow. In this pattern, an agent may begin the registration process and then ask a human to complete a claim step, often through an OTP or email-based verification ceremony.

Both patterns matter because not every agent arrives with the same context.

Some agents act for a signed-in user. Some operate inside a team. Some begin as autonomous workers and later need to be claimed by a human operator. Some need only narrow access for a specific task. Others need a persistent identity they can use across sessions, tools, and services.

auth.md gives these agents a way to understand the rules before they act.

Why Headless Domains is the right use case

Headless Domains is not a traditional registrar with an AI label added on top.

It is designed around the idea that agents need their own identity infrastructure. A namespace such as .agent is not just a name. It can become a persistent identity record with machine-readable metadata, public manifests, trusted endpoints, payment information, and discovery hooks.

When an agent registers through Headless Domains, the goal is not simply to reserve a string. The goal is to create a usable identity object for the agentic web.

That identity can include:

• a persistent namespace for the agent,
• an agent.json manifest,
• a SKILL.md file,
• DNS TXT pointers,
• MCP discovery paths,
• payment metadata,
• owner or operator references,
• capability descriptions,
• trusted endpoints,
• and claim or governance information.

This is why auth.md fits so well.

Headless Domains already helps agents become discoverable. auth.md helps agents get registered and authorized in the first place.

The real workflow: an agent registers itself

The most important use case is simple and powerful.

A human, team, or platform gives an agent a job:

Create your own trusted identity and make it discoverable.

The agent starts by finding Headless Domains. It reads the docs. It learns that a .agent, .chatbot, or .bosss namespace can anchor its identity. It sees that Headless Domains can generate or host machine-readable files like agent.json and SKILL.md.

Then the agent needs to do the part most services still make difficult: register and authenticate.

With auth.md, the agent has a known place to look. It can read https://headlessdomains.com/auth.md, understand the supported registration paths, and choose the right flow for its situation.

From there, the experience can become much more agent-native:

1. The agent reads the Headless Domains auth.md file.
2. It discovers the relevant authorization and protected resource metadata.
3. It selects a supported registration method.
4. It obtains a scoped credential or begins a claim process.
5. It searches for an available namespace.
6. It registers using the supported payment or authorization flow.
7. It receives or publishes its agent.json and SKILL.md.
8. It exposes trusted records for other agents and services to inspect.
9. It gives the human operator a way to claim, govern, or review the identity.

This is the difference between a website an agent can read and infrastructure an agent can actually use.

Identity and authentication belong together

Agent identity and agent authentication are often treated as separate topics. In practice, they are deeply connected.

Identity answers questions like:

• Who is this agent?
• Who does it represent?
• Where is its public record?
• What can it do?
• Which endpoints are official?
• Where can another agent verify its capabilities?
• How can a human or organization govern it?

Authentication answers the next set of questions:

• Can this agent register?
• Can it act on behalf of this user?
• Which scopes does it receive?
• How does approval happen?
• What credential should it use?
• How does revocation work?
• What should it do when access fails?

An agent needs both.

A public identity record without an authentication path leaves the agent visible but passive. An authentication flow without a persistent identity record gives the agent access but weak continuity.

Headless Domains and auth.md bring these two pieces closer together.

A .agent namespace can give the agent a durable public identity. auth.md can explain how an agent registers, claims, authenticates, and uses access responsibly.

That combination is what makes the integration important.

Why builders should care

For builders, the benefit is immediate: less ambiguity.

When an agent is trying to use a service, it should not have to guess how registration works. It should not need to scrape a sign-up page or ask a human to paste secrets into a chat. It should have a clear, documented path.

auth.md gives services a standard place to explain that path.

With Headless Domains users, this makes agent identity easier to delegate. A developer can tell an agent to create its own persistent identity, and the agent can follow a registration process that is written for agents instead of improvised through a browser.

The use case remains pivotal for safety as much as convenience.

Agents should not be handed broad, permanent credentials when they only need a narrow task. A better system uses scoped access, clear permissions, claim steps, revocation behavior, and auditable identity records.

Headless Domains already points in that direction with machine-readable manifests, skill files, discovery records, and payment-aware workflows. auth.md adds the missing registration instructions that help agents enter the system correctly.

Why enterprise should care

Enterprises will not trust agents at scale if every agent looks like an anonymous script using a shared key.

They need to know which agent acted, who authorized it, what it was allowed to do, how long access lasts, and where the public or internal record of that agent can be reviewed.

Agents require more than a login box.

They require identity continuity, scoped credentials, approval paths, revocation, auditability, and a reliable way to connect autonomous action back to a human, team, or organization.

Headless Domains provide agents a persistent identity layer. auth.md gives services a readable registration layer. Used together, they help move agent access away from ad hoc secrets and toward governed participation.

As agents begin to interact with APIs, MCP servers, payment rails, marketplaces, and other agents the need for these tools increase.

Every connection becomes a trust decision.

Before an agent calls a tool or spends money or publishes a record, it needs to understand who it is dealing with and how access is supposed to work. auth.md helps make that process inspectable.

The auth.md standard

The strongest examples for auth.md will be services where agents are not just signing up for another SaaS account.

They will be services where agents become real operational participants.

Headless Domains is one use case.

An agent using Headless Domains may register a persistent namespace, publish an identity manifest, expose machine-readable capabilities, connect payment metadata, use MCP discovery, and later attach that activity to a human or organization.

The registration flow is not the end of the story. It is the beginning of a larger lifecycle.

The lifecycle looks like this:

discover → register → authenticate → pay → publish identity → become discoverable → get claimed or governed → renew and continue operating

The flow is a stronger test for auth.md than a basic app registration flow.

It shows how the standard can support the infrastructure layer of the agentic web, where authentication leads directly into identity, trust, discovery, and ongoing operation.

Readable files are the new operating surfaces

The web is filling with files that are not just for people to read. They are for machines to act on.

• robots.txt told crawlers where they could go.
• sitemap.xml helped search engines understand structure.
• llms.txt helps language models find the most useful content.
• SKILL.md helps agents understand what a service or agent can do.
• agent.json gives agents structured identity and capability metadata.
• auth.md tells agents how to register and authenticate.

These files are becoming part of how the agentic web works.

They turn websites into systems agents can inspect. They give machines the context they need before they take action. They make policies, endpoints, permissions, and identity records easier to discover.

Headless Domains already treats machine-readable records as core infrastructure. Adding auth.md extends that pattern from identity discovery into authorized participation.

That is the bigger shift.

The agentic web will not be built only through chat windows and browser automation. It will be built through persistent identity records, structured manifests, discoverable tools, scoped credentials, payment metadata, and readable files that agents know how to follow.

Map of the Headless Domains agent stack

For builders, the stack can be understood this way:

Layer	Headless Domains asset	What it gives agents
Identity	.agent, .chatbot, and related namespaces	A persistent name and identity anchor
Manifest	agent.json	Capabilities, protocols, endpoints, workflows, payment metadata, and trust data
Skill	SKILL.md	Readable instructions for humans and agents
Discovery	TXT pointers, lookup APIs, and MCP auto-discovery	A way to find official records, tools, and endpoints
Authentication	auth.md	A readable path to register, claim, receive credentials, and handle access
Payments	MPP and GFA Gems	A way for agents to pay for registration, renewal, or related actions
Governance	Claim codes, user association, approval, and revocation-aware flows	A way to connect autonomous activity back to a human, team, or organization

auth.md is not a standalone announcement. It becomes part of the public inspection path for agent identity.

The takeaway

Agents need identity before they can earn trust.

They also need a way to register, authenticate, receive scoped credentials, pay for services, recover from access failures, and continue operating under a record that people and other agents can inspect.

Headless Domains is building the identity layer for the agentic web.

auth.md strengthens the path.

It gives agents a readable way to move from discovery to registration. It helps users avoid brittle browser automation and pasted secrets. It gives builders a more reliable way to make services agent-ready. It gives enterprises a clearer foundation for governance. And it gives the auth.md ecosystem a meaningful implementation case where registration leads into persistent identity, machine-readable manifests, payments, discovery, and long-term trust.

The agentic web needs more than readable pages.

It needs readable trust.

Headless Domains is helping build that trust layer with persistent identity records, machine-readable manifests, discoverable tools, scoped access, and registration paths agents can actually follow.

Give your agent a trusted identity.