The Rise of the Agentic Web — auth.md and the Era of AI Signing Up On Your Behalf

• Introduction — Why the Agentic Web Is Trending Now
• What Is the Agentic Web — From Reading to Acting
  • Three Stages of Agent Evolution
  • The Reality of Agent Sign-up Scenarios
• The auth.md Proposal — A Domain-Root Convention
  • The Lineage of robots.txt and sitemap
  • What auth.md Can Carry
  • Why Markdown
• The Technology of Delegated Authority — OAuth and Delegation Tokens
  • Reinterpreting the OAuth Delegation Model
  • The Structure of a Delegation Token
  • Token Exchange and the Delegation Chain
• Bot Distinction and Abuse Concerns — Honest Agents vs Malicious Bots
  • How to Tell Good Bots from Bad Bots
  • Verifiable Agent Identity
  • Abuse Scenarios and Defenses
• Consent and Responsibility — Can an Agent Agree to Terms?
  • The Legal Weight of Delegation
  • Where Human Involvement Is Required
• Practical Application — Designing for Both Sites and Agents
  • A Checklist for Site Operators
  • Principles for Agent Developers
  • A Gradual Adoption Path
• Frequently Asked Questions
• Pitfalls and a Critical View
• Conclusion — Toward a Standard That Ends Human Impersonation
• References

Introduction — Why the Agentic Web Is Trending Now

Throughout the first half of 2026, one topic kept trading places at the top of Hacker News and GeekNews: how should we design a world where AI agents sign up for, log into, pay for, and act on web services on behalf of humans?

For the past two years we have grown comfortable with agents in their "reading" phase. They search, summarize documents, and write code. But the mood shifted entering 2026. Agents moved into the "writing" phase: creating accounts on external services, filling out forms, subscribing, and provisioning API keys on the user's behalf.

This creates a fundamental friction. Today's web is built squarely on the assumption that "a human clicks through a browser." CAPTCHAs, email verification, terms-of-service checkboxes, phone-based identity checks — all of these presume a human on the other side. Agents break that assumption. So some try to block agents, while others try to build standards to welcome them as legitimate guests.

At the center of that standards discussion sits the idea of a "domain-root convention" such as auth.md. Emerging from the authentication-infrastructure camp including WorkOS, the idea is for a site to publish its authentication policy in a machine-readable form at the domain root — much as robots.txt tells crawlers "you may enter here but not there."

In this article we identify what the agentic web actually is, interpret the auth.md proposal in the lineage of robots.txt and sitemap, then walk through how OAuth and delegation tokens fit this picture, what the bot-distinction and abuse concerns are, and what the standardization challenges and design considerations look like.

To offer one perspective up front, a simple asymmetry underlies this entire discussion: agents are not human, yet they must pass through gates designed for humans. There are only two ways to resolve that asymmetry — make agents more human-like (disguise), or redesign the gate so agents can pass through it too (standardize). auth.md is clearly the latter path. And the position of this article is that the latter is the healthier choice in the long run.

What Is the Agentic Web — From Reading to Acting

Three Stages of Agent Evolution

An agent's relationship to the web can be split roughly into three stages.

  Stage 1: Read
    - search, summarize, extract
    - no side effects, idempotent
    - e.g. "summarize this page"

  Stage 2: Interact
    - fill forms, click, navigate
    - transient state change within a session
    - e.g. "search these flights and compare prices"

  Stage 3: Act / Commit
    - sign up, pay, subscribe, post, delete
    - persistent, hard-to-reverse change
    - e.g. "sign up for this service and start a monthly subscription"

Stages 1 and 2 are familiar by now. The real problem is Stage 3. A sign-up, once it happens, creates a user record in a database; a payment actually moves money. At this stage, "who authorized this action" and "who is responsible for it" become decisively important.

The Reality of Agent Sign-up Scenarios

Picture a concrete scenario. A user tells their personal assistant agent: "Look into collaboration tools for next month's business trip, and if one looks good, sign up for the free trial."

The agent finds candidate services and reaches a sign-up page. There, it gets stuck.

  +------------------------------------------+
  |  Start your free trial                   |
  |                                          |
  |  Email: [ ____________________ ]         |
  |  Password: [ ____________________ ]      |
  |  [ ] I am 14+ and agree to the terms     |
  |                                          |
  |  [ Prove you are human: CAPTCHA ]        |
  |                                          |
  |  [        Sign up        ]               |
  +------------------------------------------+

Here the agent hits four walls.

1. Email verification: if it must click a link in the inbox after signing up, does the agent have access to that inbox?
2. Terms agreement: does the agent have authority to legally agree to the terms? What is the scope of the authority the user delegated?
3. CAPTCHA: a demand to prove humanity. The agent is not human.
4. Payment info: when upgrading to paid, does it have authority to enter card details?

Today many agents try to clear these walls by "impersonating a human." They drive a headless browser to click pixels, use CAPTCHA-bypass services, and store the user's email password directly. This is precisely the heart of the problem. With no explicit standard, the agent mimics a human, the site tries to detect and block that mimicry, and both sides spiral into an arms race.

The starting point of agentic-web standardization is simple: "Build an honest channel so agents do not have to pretend to be human."

The auth.md Proposal — A Domain-Root Convention

The Lineage of robots.txt and sitemap

To understand auth.md, look first at its ancestors. The web has long had a pattern of "placing an agreed-upon file at the domain root to talk to machines."

The pattern is clear. Each time a new machine actor appears, the web adds a guidance file at the domain root for that actor. Just as we gave robots.txt to crawlers, sitemap to search engines, and security.txt to researchers, now we give auth.md to authentication agents.

What auth.md Can Carry

The core idea of auth.md is to describe, in machine-readable form, "how an agent can legitimately authenticate and sign up on this site." It is not yet a finalized standard, so conceptually the discussed fields might look like this.

# https://example.com/auth.md (conceptual example — not a final standard)

## Agent Sign-up Policy

Agents allowed: yes
Human-in-the-loop required: for-payment
Identity verification: oauth, did

## Endpoints

Registration: https://example.com/.well-known/agent-register
Token endpoint: https://example.com/oauth/token
Scopes supported: read, create-account, subscribe

## Terms

Terms URL: https://example.com/terms
Machine-readable terms: https://example.com/terms.json
Agent must present: delegation-token

## Rate and Abuse

Max accounts per delegated principal: 1
Contact: agents@example.com

Three things matter here.

1. Policy declaration: the site declares, machine-readably, whether it allows agent sign-up and whether it requires human involvement for sensitive actions like payment.
2. Endpoint guidance: it points agents to the official registration and token endpoints they should call instead of impersonating a human.
3. Machine-readable terms: it provides terms not only as human-readable HTML but also in a parseable form, so agents can understand consent conditions and verify the scope of delegation.

Why Markdown

The name auth.md reflects the choice of Markdown as its format. As with llms.txt, Markdown is easy for humans to read and easy for LLMs to parse. It is a compromise: friendlier to humans than JSON or XML, while still naturally interpretable by an agent's LLM core. That said, some argue for combining structured blocks (such as the key-values above) or a separate JSON supplement for parsing rigor.

This format debate itself reveals a feature of agentic-web standardization. At one end is human-friendliness (Markdown, natural language); at the other is machine rigor (JSON schemas, signed tokens). Agents sit between the two, so the standard tries to settle somewhere in between as well.

The Technology of Delegated Authority — OAuth and Delegation Tokens

If auth.md is the "policy bulletin board," the actual job of safely handing authority to an agent falls to the OAuth family. The key question here: "How do we let a user grant an agent the authority to act on their behalf, while limiting and tracking its scope?"

Reinterpreting the OAuth Delegation Model

OAuth 2.0 was originally made for "a user delegating access to their data to a third-party app." The agentic web pushes this model one step further. What differs is that the party receiving delegation is not an app a human installed, but an agent acting autonomously on a human's behalf.

The difference between traditional OAuth and agent delegation can be summarized as follows.

Because of these differences, agent delegation makes it more important to slice scopes finely, keep token lifetimes short, and clearly record the delegation chain.

The Structure of a Delegation Token

For an agent to prove to a site "I am signing up under this user's delegation," it needs a token that carries the fact of delegation. Conceptually a delegation token carries claims like these.

{
  "iss": "https://agent-platform.example",
  "sub": "agent-instance-7f3a",
  "act": {
    "sub": "user:alice@personal.example",
    "delegation_id": "del-2026-06-25-abc"
  },
  "aud": "https://example.com",
  "scope": "create-account subscribe:trial",
  "constraints": {
    "max_monthly_spend": "0",
    "human_approval_for": ["payment", "data-deletion"]
  },
  "exp": 1782000000,
  "iat": 1781996400
}

The act claim is the heart of it. This is the "actor" concept defined in the OAuth Token Exchange standard (RFC 8693), expressing the delegation relationship that "the subject acting with this token (the agent) is in fact acting on behalf of another subject (the user)." In other words, the fact that "agent 7f3a is acting on behalf of user alice" is baked into the token itself.

The constraints block pins down the limits of delegation. It sets a monthly spend cap of zero and requires human approval for risky actions like payment and data deletion. By verifying this token, the site can accept "honestly declared delegation" instead of the arms race of detecting human impersonation.

Token Exchange and the Delegation Chain

In a real flow, the token is exchanged across several stages. The user logs into the agent platform, the platform issues a narrow delegation token for a specific task, and the agent exchanges it at the target site's token endpoint.

  User (Alice)
     |  1. natural-language instruction + identity proof
     v
  Agent platform
     |  2. issues task-specific delegation token (narrow scope, short life)
     v
  Agent instance
     |  3. exchanges at target site's token endpoint (RFC 8693)
     v
  Target site (example.com)
     |  4. verifies delegation token -> allow or deny sign-up
     v
  User record created (delegator=Alice, actor=agent)

When this chain is clear, you can later trace "who created this account." The account record retains "the delegator is Alice, the actor who performed the sign-up is agent instance 7f3a, and the delegation ID is del-2026-06-25-abc." This becomes the foundation of accountability tracing.

Bot Distinction and Abuse Concerns — Honest Agents vs Malicious Bots

How to Tell Good Bots from Bad Bots

The hardest problem in the agentic web is distinguishing "honestly declared agents" from "malicious bots pretending to be human." auth.md and delegation tokens open the front door to honest agents, but malicious bots still try to slip in the back.

  +---------------------------+
  |   The agent quadrant       |
  +-------------+-------------+
  | honest +    | honest but   |
  | declared    | undeclared   |
  | (follows    | (just a bot) |
  |  auth.md)   |             |
  +-------------+-------------+
  | malicious + | malicious +  |
  | disguised   | declared-    |
  | (spam/fraud,| then-violated|
  |  CAPTCHA    | (violates    |
  |  bypass)    |  terms)      |
  +-------------+-------------+

In an ideal world, every agent sits in the top-left: honestly declared, entering through the front door. But reality contains all four quadrants. The standard's goal is to make the honest agent's front-door passage so easy and attractive that the incentive to disguise shrinks. If the front door is easier than the back door, there is no reason to disguise.

Verifiable Agent Identity

Honest declaration alone is not enough, because anyone can say "I am an honest agent." Hence the need for verifiable identity. There are several approaches.

1. Platform attestation: a trusted agent platform signs its own agents. The site verifies the signature with that platform's public key.
2. Decentralized identity (DID): the agent presents a decentralized identifier and verifiable credentials. This is not tied to a specific platform.
3. mTLS and client certificates: the agent authenticates itself via mutual TLS. A familiar approach in business-to-business communication.

The key is that "who delegated to the agent, and which platform vouches for that agent" must be cryptographically verifiable. With verifiable identity, the site can trace responsibility and revoke trust upon abuse.

Abuse Scenarios and Defenses

Let us honestly enumerate the abuse scenarios the agentic web could open up.

The common principle of defense is to convert "anonymous human impersonation" into "traceable declared delegation." Anonymous bots are hard to block, but an agent carrying a delegation ID and verifiable identity can, upon abuse, be traced all the way back to its delegator and platform.

Consent and Responsibility — Can an Agent Agree to Terms?

The Legal Weight of Delegation

Beyond the technical problem, the agentic web has a thorny consent question. When an agent presses the "agree" button on terms of service on behalf of a user, is that consent legally valid? The user only said "go ahead and sign up" — does that become valid consent to a 50-page agreement?

This hinges on the scope and clarity of the delegation. The clearer the delegation token's scope and constraints — say "this agent may only sign up for free trials; payment requires human approval" — the easier it is to view consent for actions within that scope as attributable to the delegator. Conversely, a vague "full delegation" is the seed of disputes.

Where Human Involvement Is Required

So many designs force "human-in-the-loop" for specific actions. That is the human_approval_for field in the token example above. Generally, the following actions are safest requiring explicit human confirmation.

  Auto-delegation OK         Human confirmation needed
  ----------------------     -------------------------
  - information lookups      - confirming payment/subscription
  - free sign-up             - consent to share PII with third parties
  - saving form drafts       - permanent data deletion
  - comparison/recommend     - entering legally binding contracts
  - read-only APIs           - public posts affecting reputation

This boundary is not fixed; it adjusts with the delegator's trust level and the irreversibility of the action. The core principle: "the harder to reverse and the larger the impact, the more a human's finger should actually press the button."

Practical Application — Designing for Both Sites and Agents

A Checklist for Site Operators

If you operate a service, you can check the following to prepare for the agentic web.

[ Policy publication ]
[ ] Have you decided to allow / conditionally allow / forbid agent sign-up?
[ ] Do you plan to publish a machine-readable policy like auth.md?
[ ] Can you provide terms in a machine-readable form too?

[ Building the front door ]
[ ] Do you have official registration/token endpoints to call instead of impersonation?
[ ] Can you verify a delegation token (RFC 8693 actor claim)?
[ ] Have you defined per-delegator account caps and rate limits?

[ Tracing and accountability ]
[ ] Does the account record separately store delegator and actor?
[ ] Can you trace abuse by delegation ID and revoke trust?
[ ] Do you gate sensitive actions behind human approval?

Interestingly, whether you welcome or block agents, declaring a policy like auth.md is useful for both. A site that wants to block can declare "no agent sign-up," and a site that wants to welcome can point to the front door. This mirrors how robots.txt was useful to sites that both allowed and forbade crawling.

Principles for Agent Developers

Conversely, if you build agents, I recommend these principles.

1. Declare honestly: use the User-Agent and a delegation token to state "I am an agent and I act under so-and-so's delegation." Human impersonation is a short-term gain and a long-term debt.
2. Read auth.md first: as you respect robots.txt, check the site's auth policy first and enter through the front door.
3. Minimize scope: request only the minimum authority a task needs. Full delegation is risky and easily refused.
4. Call in the human appropriately: at risky points like payment, do not exceed the delegation scope; ask the user to confirm.

A Gradual Adoption Path

None of this gets standardized at once. The realistic adoption path is gradual.

  Now (2026):
    - some sites publish llms.txt / experimental auth.md
    - major agent platforms pilot delegation tokens
    - RFC 8693 token exchange is already mature

  Next:
    - attempts to standardize well-known paths (IETF/W3C discussion)
    - agreement on machine-readable terms formats
    - formation of a verifiable agent-identity ecosystem

  Maturity:
    - front-door passage becomes easier than the back door
    - the incentive for human-impersonation arms races declines

The most practical thing an individual developer can do at this stage is to properly master the already-mature OAuth token exchange and scope design. Whatever form auth.md is standardized into, safely delegating authority beneath it will ultimately be the job of the OAuth family.

Frequently Asked Questions

Q1. Does auth.md have enforcement power like robots.txt?

No. Like robots.txt, auth.md is a voluntary convention. Its force comes not from the standard itself but from verifiable identity and token verification. If a site actually verifies delegation tokens and admits only honest agents through the front door, that becomes de facto enforcement. auth.md is the signpost saying "come in this way," and enforcement happens at that front door.

Q2. Will CAPTCHA disappear now?

Not for the time being. auth.md and delegation tokens are a front door for honest agents; they do not replace the tools that block malicious bots. If anything, once a front door exists, CAPTCHA can focus solely on "undeclared traffic." Honest agents pass through with tokens, and only unidentified traffic meets a CAPTCHA — the roles get divided.

Q3. Do small sites need to implement this?

Not right away. Most small sites can wait until the standard matures. That said, if you want to explicitly forbid agent sign-up, it is worth knowing that a means to express that intent is emerging. Whether welcoming or refusing, an explicit declaration benefits both sides.

Q4. What is the difference between a delegation token and a regular OAuth access token?

The key difference is the act (actor) claim. A regular access token only says "the subject of this token is acting," whereas a delegation token makes explicit the delegation relationship: "the subject (the agent) is acting on behalf of another subject (the user)." This is what makes accountability tracing possible.

Q5. Is a paradox possible where agents become more trusted than humans?

Interestingly, yes. An agent with a verifiable identity and an explicit delegation scope can be more traceable and more accountable than a human signing up anonymously. One can even imagine a future where an honestly declared agent comes closer to being a "first-class citizen" than an anonymous human.

Pitfalls and a Critical View

For balance, here is the skepticism about the agentic web and the auth.md proposal.

1. "Just one more standard" critique: does adding yet another file at the domain root actually solve the problem? robots.txt has no enforcement, so malicious crawlers ignore it. auth.md too will be followed only by honest agents, while malicious bots keep impersonating humans. In other words, the standard may only raise costs for the honest side while failing to stop the malicious side.
2. Lack of verification infrastructure: for delegation tokens and verifiable identity to work, you need consensus and infrastructure about who the trusted issuers are. This trust-anchor problem is unsolved. If only a few big-tech platforms are trusted, centralization concerns arise.
3. Hollowing out of consent: if the practice of agents auto-agreeing to terms hardens, terms — which almost no one reads anyway — become even more of a formality. Machine-readable terms risk becoming an excuse: "the agent agreed on its own, so we are covered."
4. Centralization and gatekeeping: if sites start allowing "only agents from verified platforms," a few giant agent platforms become the new gateway to the web. This can clash with the spirit of the open web.
5. Too-early debate: agents signing up on behalf of humans is not even common yet, so building standards first is overreach — one view. Conversely, as with robots.txt, the counterargument is that we must discuss standards before de facto practice sets in, to prevent fragmentation.
6. The risk of format proliferation: domain-root files are already multiplying — llms.txt, security.txt, ads.txt, and more. If auth.md adds yet another, site operators face more files to manage and a harder time keeping them consistent. Opinions split between those who say everything should converge into a single unified well-known metadata file and those who say separating by purpose is better.

Most of these critiques are valid. The first in particular — "only the honest side follows the standard" — is a weakness the history of robots.txt has proven. But there is a counter. The real value of auth.md is not to stop malicious bots, but to make the honest agent's front door so convenient that the majority is funneled through it. It may not end the arms race, but by lowering the cost of honest behavior it can shift the ecosystem's center of gravity.

Conclusion — Toward a Standard That Ends Human Impersonation

The core problem of the agentic web is not technology but the incentive for honesty. The reason agents impersonate humans today is that there is no front door through which to honestly say "I am an agent." The real goal of auth.md and delegation tokens is to build that front door.

The history of the web is also a history of carving out honest paths for each new actor as it appears. Just as we gave robots.txt to crawlers and sitemap to search engines, it is now the agents' turn to be given a front door. Even if that front door is as imperfect as robots.txt, the very attempt to build a path is the first step out of the vicious cycle of disguise and detection.

To summarize:

1. The web was built on the assumption that humans click, but as agents enter the "act" stage, that assumption is breaking.
2. auth.md is a domain-root convention in the lineage of robots.txt and sitemap, proposing that sites tell agents their authentication policy in machine-readable form.
3. Actual delegation can be implemented with the OAuth Token Exchange (RFC 8693) actor claim plus narrow-scope, short-lived delegation tokens.
4. The key is to convert "anonymous human impersonation" into "traceable declared delegation," so that abuse can be traced back to the delegator and platform.
5. The critiques are valid: only the honest side follows the standard, the trust anchor is unsolved, and centralization is a concern. Even so, lowering the cost of honest behavior is worthwhile.

A world where agents act on behalf of humans has already begun. The question is whether we fill that world with an arms race of impersonation and detection, or with a structure of honest delegation and traceable responsibility. auth.md is a small step toward the latter. And what sets the direction of that step is not a standards document but the design decisions of those of us building agents and services right now.

The next time you design an agent or a service, ask yourself just one thing: "Does this system encourage agents to honestly reveal themselves, or does it force them to hide?" These small questions, gathered together, will determine the character of the agentic web.

References

• WorkOS Blog — The Agentic Web and authentication standards
• GeekNews — auth.md and agentic-web authentication discussion
• Hacker News
• RFC 8693 — OAuth 2.0 Token Exchange
• RFC 6749 — The OAuth 2.0 Authorization Framework
• robots.txt standard (RFC 9309 — Robots Exclusion Protocol)
• security.txt (RFC 9116)
• llms.txt proposal
• W3C Decentralized Identifiers (DIDs) v1.0
• W3C Verifiable Credentials Data Model