CAPTCHAs for Agents: The Webs Broken Identity Model Is About to Collapse

The CAPTCHA is dead. It just hasn’t been buried yet. Last month my personal shopping agent — a fairly basic LangGraph thing I wrote to compare flight prices — got stopped by a Cloudflare Turnstile challenge on a travel site I’ve been using for eight years. The agent had my session cookie, my OAuth token, my device fingerprint, and explicit instructions from me to book the cheapest Tuesday flight to SFO. It was, by any reasonable definition of the word, me. And yet the site’s bot detection system correctly identified it as “not a human” and slammed the door shut. I had to finish the booking manually, which defeated the entire point of having an agent.

This is the crisis nobody is talking about loudly enough. The web’s identity model has exactly two categories: human and bot. For two decades, that binary was good enough. Humans had fingers and eyeballs and attention spans; bots had headless Chrome and scraper farms and obvious behavioral tells. CAPTCHAs — from the original squiggly-text nightmares of 2003 to Google’s reCAPTCHA v3 invisible risk scoring to Cloudflare’s Turnstile and hCaptcha’s private proofs — all built on this binary. Prove you are the human class, or be denied.

AI agents shatter that taxonomy. They are authorized by humans, acting on behalf of humans, often carrying human credentials, but they are indistinguishable from bots in every behavioral signal a modern detector can measure. Mouse entropy? None. Scroll velocity? Robotic. Headless browser signatures? Obvious. And they are about to become the dominant form of web traffic. Gartner projects that by the end of 2027, agent-originated HTTP requests will outnumber human-originated ones on consumer services. Cloudflare’s own Q1 2026 radar report put “likely-agent” traffic at 23% of all requests crossing their edge — up from 4% one year ago.

Yesterday an HN post (79 points before it got buried in the firehose) proposed “CAPTCHAs for agents” — a dedicated challenge system that would let websites differentiate good agents (user-authorized) from bad agents (scrapers, credential stuffers, fraud rings). It’s a reasonable-sounding idea that is, on closer inspection, exactly the wrong abstraction. CAPTCHAs are about proving membership in a class. What the agent web actually needs is proving authorization from a principal. Those are different problems, and pretending the old tool fits the new shape is how we get another decade of broken UX.

I’ve built bot detection systems — at a DSP where we filtered $40M/month in ad spend from invalid traffic, and at a startup where I wrote the browser-fingerprint stack from scratch. I’ve also built agent tooling on the other side: MCP servers, OAuth-delegated scrapers, LangGraph agents that book real things with real money. I have watched both sides of this war from the inside, and I can tell you with high confidence: the CAPTCHA paradigm is obsolete, and the sites that cling to it will be bypassed by agents anyway, just less gracefully. The only viable path forward is an agent-aware identity model, and MCP’s client identity design — for all its rough edges — is the closest thing the industry has to a real answer.

This is a long argument, because it needs to be. I’ll walk through why CAPTCHAs broke, why every proposed replacement (Private Access Tokens, Worldcoin proof-of-humanity, Kagi’s Orion initiative, Browserbase’s stealth approach) has load-bearing flaws, why OAuth alone won’t save us, and what a proper delegation-aware identity stack looks like. Then I’ll tell you what to actually implement in 2026, and make some concrete predictions about where the post-CAPTCHA web lands by 2027.

How We Got Here: A Brief Archaeology of the Human/Bot Binary

The original CAPTCHA — Luis von Ahn’s 2003 paper at CMU — was a beautiful hack. It exploited a capability gap: at the time, OCR on distorted text was hard, and humans could still read it. Every CAPTCHA since has been a variation on the same theme: find a task where humans outperform machines, and use it as a gate. reCAPTCHA v1 digitized old books via this labor. reCAPTCHA v2 (“I’m not a robot”) quietly shifted most of the work to behavioral fingerprinting while keeping the checkbox as theater. reCAPTCHA v3 dropped the theater entirely and became a pure risk-scoring engine.

hCaptcha emerged around 2018 as a privacy-positioned alternative, offering similar risk scoring but without feeding data into Google’s ad graph. Cloudflare Turnstile, launched in 2022, went further: it replaced the challenge with passive signals harvested from the TLS handshake, HTTP/2 fingerprint, and browser environment — no user interaction required on the happy path. FunCAPTCHA (now Arkose Labs) doubled down on interactive puzzles for high-risk flows like account creation.

All of these systems share an architectural assumption that is now false: the requesting entity is trying to be a human, or trying to pretend to be one. The detector’s job is to distinguish “genuine human” from “adversarial machine pretending to be human.” Both options assume the machine wants to hide.

An AI agent acting on behalf of a legitimate user has no interest in hiding. It would happily identify itself, declare its principal, present a signed delegation, and tell the server exactly which tool calls it intends to make — if the server had any way to consume that information. It doesn’t. The standards don’t exist. So the agent either lies (headful browser, human-like mouse jitter injected by Browserbase or Anchor Browser) or it gets blocked. Those are the only two options, and both are bad outcomes for everyone.

Why “Just Use OAuth” Isn’t the Answer

Whenever I raise this problem, half the audience says “OAuth solves this.” It doesn’t. OAuth is a delegation protocol for a specific API that already knows about the agent. If I have a Google Calendar token, I can hit calendar.googleapis.com with it and Google knows exactly what I’m doing. Great. That covers maybe 5% of what agents need to do.

The other 95% is agents interacting with arbitrary websites that have no API, no OAuth integration, and no concept of “third-party client on behalf of user.” When my travel agent hits united.com, there is no OAuth flow for “LangGraph agent booking flights on behalf of Michael.” There’s just a session cookie and a bot detector. OAuth was designed in a world where services integrate pairwise. The agent era needs an identity model that works for any website the user has credentials with, without requiring that website to explicitly onboard every agent vendor.

The Failed Contenders: A Tour of Attempted Fixes

Several proposals have surfaced in the last two years. Each is interesting. None is sufficient. Let me walk through them with the specific failure modes I’ve hit in production.

Cloudflare Private Access Tokens (and Apple’s PAT)

Private Access Tokens are genuinely clever. Originally proposed by Apple and Cloudflare in 2022, PATs use the IETF Privacy Pass protocol to let a trusted attester (Apple’s device check, Cloudflare’s edge) vouch that a request is coming from a real device without revealing which device. A server receives a token that says “this is a genuine iPhone in good standing” or “this is a residential Safari session with no automation signals,” and it can skip the CAPTCHA.

I like PATs. I’ve deployed them. They’re a real improvement for human traffic. But they are fundamentally a device attestation mechanism, not a delegation mechanism. A PAT says “real device.” It does not say “real device running software the user explicitly authorized to act on their behalf.” When my agent runs in a container in AWS — which it does, because running agents on user laptops is a terrible operational model — there’s no device attestation available. And when agents run on phones (which is coming), Apple’s current attester explicitly won’t issue PATs for requests originating from programmatic contexts. The attester treats “user clicked something” and “agent is acting for user” as the same hostile category.

Cloudflare’s version is slightly better because it can be extended to issue tokens based on enterprise-issued credentials, but the ecosystem for “my agent vendor is a recognized attester” does not exist and has no obvious path to existing. The trust graph is wrong-shaped for delegation.

Worldcoin and Proof-of-Humanity Schemes

Worldcoin (now rebranded World) and similar proof-of-humanity projects (Proof of Humanity DAO, BrightID, Idena) try to establish that there is exactly one human behind an account. Worldcoin’s orb scans your iris; others use social graph verification or Turing tests. The resulting credential — World ID, a zero-knowledge proof of unique humanity — is a real cryptographic primitive that works.

Here’s the problem: it solves the wrong problem. Agents don’t need to prove they are human. They need to prove they are authorized by a specific human. A World ID attached to an agent request would mean “the user who owns this ID is a real person” — which is true and useless, because the whole question is whether this particular request is something the human sanctioned, or something a compromised agent is doing unilaterally.

Worldcoin advocates will tell you that the ID can be used as a basis for delegation — “real human holds ID, ID signs delegation to agent, agent presents delegation.” Fine, but at that point the proof-of-humanity step is vestigial. What’s doing the work is the delegation signature. You could skip the orb and use any user-held key. Which is, not coincidentally, what MCP does.

Kagi’s Orion Initiative

Kagi (the paid search engine) announced the Orion initiative in late 2025: a proposal for browser-signed “user present” assertions, where the browser itself attests that a request was triggered by real user intent, bundled with a per-site anonymous identifier. It’s better than PATs because it’s not tied to device manufacturers, and better than Worldcoin because it doesn’t require biometrics.

It also doesn’t work for agents. Orion assumes there is a browser with a user in front of it. Agents don’t have users in front of them at request time — the user issued an instruction minutes or hours ago and went to make coffee. The whole point of agents is asynchrony. Orion’s model is “verify the user is here right now,” which is orthogonal to “verify the user authorized this action at some prior moment.”

The Kagi team has hinted at extensions for “deferred intent” but nothing has shipped. And philosophically, Orion is still in the human/bot binary — it just shifts the attestation layer into the browser.

Browserbase and the Stealth Agent Approach

Browserbase, Anchor Browser, Steel.dev, and the rest of the managed-headless-browser vendors represent the market’s cynical but accurate answer to the current mess: if the site won’t let your agent in the front door, sneak it through the back. These services run real Chromium instances with residential IPs, realistic TLS fingerprints, human-like input trajectories, and aggressive anti-detection patches. An agent running on Browserbase looks, to Cloudflare, exactly like a human on a MacBook.

I use Browserbase. It works. It is also a terrible long-term equilibrium. The entire industry is now in an escalating arms race where legitimate user-authorized agents pay $0.05 per page view to a third party to evade detection systems that would otherwise correctly identify them as non-humans — which they are, because they’re agents, but they are authorized non-humans, which the detection system has no vocabulary for. Every party in this arrangement is wasting money and moving entropy.

The Browserbase approach also has a critical failure mode: when something goes wrong (fraudulent transaction, spam, abuse), the site has no way to distinguish “user-authorized agent made a bad call” from “stolen credentials in the hands of attackers” because the agent was specifically designed to be indistinguishable from a human. The audit trail is destroyed by the evasion layer.

The Real Problem: Identity Is the Wrong Layer

Step back. What are websites actually trying to accomplish with bot detection?

• Rate limiting: prevent a single actor from overwhelming the service.
• Fraud prevention: prevent credential stuffing, carding, fake accounts.
• Content protection: prevent mass scraping for competitive or training purposes.
• Monetization: ensure ad impressions are served to humans who might click.
• Trust and safety: prevent automated abuse, spam, harassment.

Notice that none of these are actually about the human/bot distinction per se. They’re about accountability, intent, and resource control. “Is this request human?” is a proxy for “can I hold someone accountable for this request’s behavior?” In the pre-agent era the proxy worked because humans were the only accountable actors. In the agent era the proxy has broken because agents can carry accountability (via delegation from their principal) without being human.

The right abstraction is not “prove humanity” but “prove a principal chain.” A request should arrive with a verifiable claim: “I am agent X, acting on behalf of user Y, authorized by delegation D signed at time T, with scope S.” The server can then apply its policies: does it accept agent traffic at all? Does it trust agent X’s vendor? Does it trust user Y based on past behavior? Does scope S cover the action being requested?

This is not a new idea. It’s how every serious distributed system already works internally. SPIFFE/SPIRE does this for service-to-service auth. Google’s BeyondCorp does it for zero-trust enterprise networking. Macaroons (Google’s 2014 paper) formalized delegation chains a decade ago. The technology is solved. What’s missing is a web-native profile and ecosystem buy-in.

MCP’s Client Identity Model: Imperfect but Real

Model Context Protocol started life as a way for Claude (and later other agents) to talk to tools. Anthropic shipped the spec in late 2024, and in the 2025 revisions it grew a proper identity story — one that, almost by accident, solves the agent-delegation problem better than any dedicated proposal I’ve seen.

The relevant piece is MCP’s notion of client identity. When an MCP client (agent) connects to an MCP server (tool or resource), the handshake includes:

• A client identifier (who is the software?) — a stable ID for the agent implementation, like “anthropic-claude-desktop/1.2” or “my-custom-langgraph-agent/v0.4”.
• A principal identifier (on behalf of whom?) — typically an OAuth-style subject, but extensible to any verifiable user identifier.
• A delegation proof — a signed statement from the principal authorizing this client for this scope.
• A session binding — cryptographic material tying subsequent requests to this handshake.

The server can inspect all four before deciding to serve the request. It can maintain a reputation graph over client IDs (this agent software has behaved well), over principal IDs (this user has behaved well), and over the cross product. It can apply per-principal rate limits, per-client policies, and per-scope restrictions.

Critically, this is not a bot detector. It is not trying to decide if the requester is human. It doesn’t care. It’s trying to decide if the requester is accountable. That is exactly the question bot detection has been a blurry proxy for.

Why MCP-Style Identity Generalizes Beyond MCP

The client-identity pattern doesn’t require MCP-the-protocol to be everywhere. It requires the shape of the handshake to be standardized. A websocket, an HTTP request, a GraphQL query — any of them can carry the same four pieces of information in headers. Imagine:

GET /flights/search?origin=JFK&dest=SFO HTTP/1.1
Host: united.com
Agent-Client: urn:agent:anthropic/claude-desktop/1.2
Agent-Principal: urn:user:[email protected]
Agent-Delegation: eyJhbGciOiJFZERTQSIs... (signed JWT)
Agent-Scope: flights.search flights.book:under-1000usd
Agent-Session: 0x8f2a...

The delegation JWT is signed by the user’s key (provisioned through their identity provider — Google, Apple, whatever), scoped to specific operations, and time-bounded. United.com verifies the signature, checks its policy (“we accept Anthropic-Claude-Desktop for flights.search, require step-up auth for flights.book over $1000”), logs the principal, and responds.

This is not science fiction. IETF is drafting a Delegation-Token HTTP header (draft-ietf-oauth-delegation-01 as of March 2026) that formalizes exactly this. The Cloudflare and Anthropic teams have both sent engineers to the working group. Adoption is real, if quiet.

Comparison Table: CAPTCHA vs Proof-of-Humanity vs Agent Delegation

What OAuth Delegation Is Missing (And How MCP Fills It)

Let me be more precise about the OAuth gap, because OAuth defenders tend to elide it. OAuth 2.0 was designed for a specific pattern: a user authorizes a specific third-party application to access a specific API on their behalf. Classic example: “Allow Buffer to post to your Twitter account.” Buffer is a known entity, Twitter is a known entity, the user clicks through a consent screen, and a token is issued.

This breaks down for agents in three ways:

1. Agents Are Not Pre-Registered Applications

When I spin up a custom LangGraph agent on Tuesday afternoon, there is no OAuth client registration step. The agent doesn’t have a client_id at united.com. It can’t go through the authorization code flow because the user flow would require opening a browser, having the user click consent, and completing a redirect — which is exactly the kind of friction agents exist to eliminate.

MCP handles this with dynamic client registration (RFC 7591) combined with user-mediated delegation: the user grants the agent a broad delegation once (at agent setup time) and the agent derives scoped sub-delegations for each target service on the fly. The user never has to do a per-site OAuth dance.

2. OAuth Doesn’t Compose

If my agent needs to call Service A, which needs to call Service B on the user’s behalf, OAuth’s delegation chains are ad-hoc and non-standard. Token exchange (RFC 8693) exists but is rarely implemented. Macaroons solved this in 2014 with attenuation and third-party caveats; MCP’s delegation proofs are macaroon-shaped, allowing clean composition.

3. OAuth Assumes the RP Is a First-Class Participant

Traditional OAuth requires the resource provider to be an OAuth-aware server. united.com‘s flight search is not OAuth-aware in any meaningful sense — it’s a cookie-session web app. For an agent to authenticate to it, the site needs to speak a protocol it currently doesn’t. MCP’s HTTP-header-based identity carriage means the site can add agent-awareness incrementally without rebuilding its auth stack.

Concrete Guidance: What to Build in 2026

Enough theory. If you’re a developer shipping real systems this year, here’s what I’d actually do — on both sides of the agent/site divide.

If You Run a Website (The Resource Side)

Step 1: Stop treating agent traffic as adversarial by default. Audit your bot-detection configuration. If you’re using Cloudflare Turnstile or similar with a blanket block on “likely-automation” scores, you’re already losing legitimate transactions from agent-equipped users. Instrument what you’re blocking. Compare conversion rates on challenged sessions vs. unchallenged.

Step 2: Accept signed delegation headers. Even if you don’t trust them yet, start parsing them. The IETF Delegation-Token draft header, the MCP client-identity headers, or your own custom scheme — just start reading them. Log the principal and client IDs. Build a shadow reputation graph. This is the same playbook that let companies adopt TLS certificate transparency incrementally.

Step 3: Tier your traffic. Create three buckets:

• Verified principal chain: request carries valid delegation from a known IdP. Give it elevated rate limits, skip CAPTCHA, log the principal for accountability.
• Human-validated via PAT/Turnstile: traditional human path, existing behavior.
• Unverified: apply CAPTCHA or block. But treat this as the explicit fallback, not the default.

Step 4: Publish an agent policy. At /.well-known/agent-policy.json, declare what you accept. Which agent clients are allowed? Which scopes? What are your rate limits? This lets agents configure themselves correctly instead of probing and getting blocked.

{
  "version": "2026-03",
  "accepted_clients": [
    "anthropic-claude-*",
    "openai-agents-*",
    {"pattern": "*", "require_attestation": true}
  ],
  "scopes": {
    "search": {"rate": "60/min", "auth": "optional"},
    "book": {"rate": "10/min", "auth": "required", "step_up": ["amount>1000"]}
  },
  "delegation_formats": ["rfc-delegation-token-01", "mcp-v2"],
  "fallback": "turnstile"
}

Step 5: Build your agent-aware fraud model. The old fraud model asked “is this a bot?” The new one asks “is this principal behaving anomalously, regardless of whether the actor is human or agent?” Anomaly detection on principal behavior is strictly more powerful than binary bot detection, because it catches insider threats too.

If You Build Agents (The Client Side)

Step 1: Implement MCP client identity end-to-end. Even for tools that aren’t MCP servers, adopt the MCP identity shape as your canonical internal representation. When you hit a plain HTTP endpoint, translate your identity state into the appropriate headers. When the IETF spec stabilizes, you’ll be one substitution away.

Step 2: Build a principal-key infrastructure. Your users need a way to sign delegations. You can piggyback on existing IdPs (Google, Apple, Microsoft) using OpenID Connect plus DPoP-bound tokens, or you can use a passkey-based direct-signing flow. Either way, the user should sign the delegation once; the agent should derive scoped sub-delegations on demand.

Step 3: Be honest in your identity headers. Do not spoof. Do not use Browserbase as a primary architecture. Use it as a fallback for sites that haven’t adopted anything better, and clearly mark those requests in your audit log. When sites complain that your agent hit them, you want to be able to show “here is the user who authorized it, here is the scope, here is the timestamp” — not “here is a forged residential fingerprint.”

Step 4: Implement confirm-before-act for high-impact actions. Even with valid delegation, your agent should require a fresh user confirmation for irreversible or high-stakes actions (payments over threshold, account deletion, legal consent). This is both good UX and the ethical floor for agent authority. It also plays nicely with step-up auth on the server side.

Step 5: Publish your agent’s capabilities manifest. Mirror of the server’s agent-policy.json: at https://your-agent.example/.well-known/agent-capabilities.json, declare what your agent does, what scopes it requests, who its vendor is, and how to contact you for abuse reports. Websites can use this to decide whether to trust you.

Reference Architecture Sketch

Here’s a minimal Python-ish sketch of what the client side looks like in practice. This isn’t copy-paste code, but it captures the shape:

class AgentHTTPClient:
    def __init__(self, principal_key, client_id, root_delegation):
        self.principal_key = principal_key  # user's signing key
        self.client_id = client_id          # e.g. "my-agent/v0.4"
        self.root = root_delegation         # signed by principal, held in memory

    def request(self, method, url, scope, **kwargs):
        site_policy = self.fetch_policy(url)
        if self.root.covers(scope):
            sub = self.root.attenuate(
                scope=scope,
                audience=urlparse(url).netloc,
                exp=now() + 300,
            )
            headers = kwargs.setdefault("headers", {})
            headers["Agent-Client"] = self.client_id
            headers["Agent-Principal"] = self.root.principal
            headers["Agent-Delegation"] = sub.serialize()
            headers["Agent-Scope"] = scope
        resp = http.request(method, url, **kwargs)
        if resp.status == 401 and "agent-policy" in resp.headers.get("WWW-Authenticate", ""):
            raise AgentAuthRequired(resp)
        if resp.status == 403 and site_policy.fallback == "turnstile":
            return self.turnstile_fallback(method, url, **kwargs)
        return resp

The server side is equally straightforward — verify the JWT, check the scope, apply rate limits keyed on principal rather than IP.

The Objections, Answered

Every time I’ve presented this argument in a room, the same three objections surface. Let me address them directly.

“Attackers will forge delegations or steal principal keys.”

Yes, some will. Key theft is a real threat. So is credential stuffing today. The difference is that a stolen delegation has a scope, a time window, an audience, and a traceable issuance event. A stolen password has none of those things. Moving from passwords-plus-CAPTCHA to scoped delegations is a strict improvement in the defender’s position, because compromises are narrower and more detectable.

“Small websites can’t implement delegation verification.”

They don’t have to. The same CDNs and edge providers that ship Turnstile today will ship delegation verification as a one-line config option tomorrow. Cloudflare has already telegraphed this publicly. Fastly’s engineering blog ran a piece in February 2026 on edge-verified delegation. The infrastructure is coming; small sites will inherit it.

“This just recreates the walled-garden problem — only blessed agents can access the web.”

This is the objection I take most seriously. If only Anthropic and OpenAI can get their agent clients onto the “accepted_clients” lists of major sites, that’s a new oligopoly. The mitigation is making agent registration permissionless: a new agent just needs to be able to demonstrate a principal chain. Reputation is built over time, not gated on enterprise partnerships. The require_attestation: true clause in the policy example above is the key — it lets unknown agents in, with elevated friction but not total exclusion. Whether the actual ecosystem evolves this way or slides into closed partnerships is a governance question the standards bodies are actively fighting over. It is not inherent to the design.

The Economic Argument: Why This Transition Happens Anyway

Even if you don’t buy the technical argument, the economics force the transition. Consider the flows of money:

• E-commerce: agents with clear delegation will convert at much higher rates than humans because they’re deterministic and don’t abandon carts. Sites that accept agent traffic will capture revenue from sites that block it.
• Travel: agents shop continuously. Airlines and hotels that expose agent-friendly booking will see booking volume migrate to them.
• Advertising: the ad ecosystem is already collapsing under invalid traffic, which is not going to get better. A world where agent impressions are declared and non-agent impressions are verified is strictly cleaner for advertisers than the current “everyone lies” equilibrium.
• SaaS: every vertical SaaS product is going to have a 10x surface area of agent integration within 18 months. Products that are agent-hostile will be replaced by products that aren’t.

The sites that hold the line with 2024-era bot detection are going to bleed transactions to the sites that don’t. This is not a prediction about ethics or engineering elegance. It’s about the dollar signs.

What Happens to CAPTCHAs Themselves

CAPTCHAs don’t vanish in 2027. They become a last-resort fallback — the thing you make an unverified, unsigned, unattested actor do when you have no other signal. The role shrinks from “primary gate” to “tarpit for the genuinely hostile.” Cloudflare will still ship Turnstile. hCaptcha will still exist. Arkose puzzles will still guard account creation at banks. But they’ll handle 5% of traffic instead of 50%, and the other 95% will flow through signed-delegation paths.

The interesting design question is what the residual CAPTCHA looks like. Once you’ve already filtered out every reasonable actor with delegation, what’s left is either (a) genuine humans with misconfigured or privacy-hardened browsers who can’t produce attestations, or (b) actually adversarial automation. For category (a), a short honeypot or pay-per-request micro-payment is kinder than a puzzle. For category (b), proof-of-work or expensive challenges are fine — you want to tarpit attackers.

I suspect we’ll see a revival of interest in proof-of-work CAPTCHAs (mCaptcha is one such experiment) specifically because they are computation-efficient to verify and computation-expensive to bulk-abuse. They sidestep the whole human/bot question in a clean way: they just cost.

Predictions for 2027 and Beyond

Here’s where I plant specific flags. Grade me in 18 months.

1. The IETF Delegation-Token spec reaches RFC status by Q3 2027. It may be rebranded (the OAuth working group has a habit of renaming things mid-process), but some standardized header-carried signed delegation will be an RFC by then. Cloudflare, Anthropic, and at least one major IdP (I’d bet on Okta) will ship production support before the RFC lands.

2. Turnstile-equivalent services pivot to delegation-first. Cloudflare, hCaptcha, and Arkose will all ship “agent-aware challenge” products by end of 2026. The marketing will pretend this is a natural extension of what they’ve always done; it’s actually a concession that the old model doesn’t scale to agent traffic. Expect the phrase “agent-aware bot management” to become industry-standard pitch language.

3. At least one major e-commerce site goes agent-first. My bet is Shopify publishes a merchant-facing agent commerce API that includes delegation verification, competing directly with how the open web handles agent traffic. This becomes a flywheel: merchants opt in because conversion rates are dramatically higher.

4. Worldcoin pivots. The proof-of-humanity angle doesn’t find product-market fit for agent traffic. World ID gets repositioned as a fraud-prevention primitive for financial services, or the company restructures. The orb network becomes a curiosity.

5. MCP or its successor becomes the de-facto identity protocol for agent-to-service interaction. Not because MCP is beautifully designed — it has warts — but because it’s early, it’s practical, and Anthropic plus OpenAI plus Google have rough alignment on the shape. The open-web IETF work will end up resembling MCP’s identity model more than any other existing proposal.

6. Browserbase and peers consolidate. The stealth-browser-as-a-service market peaks in late 2026 and contracts sharply in 2027 as delegation paths become available. The winners are the ones who pivot from evasion to orchestration — providing the signed-delegation infrastructure their customers need.

7. The first big agent-fraud incident happens, and the industry overreacts. Within the next 12 months, a user’s delegation gets compromised and an attacker drains a real amount of money through an agent. The public reaction will be “agents are unsafe” and there will be a 6-month panic. The right lesson — “scoped delegations should be time-bounded and require step-up for high-value actions” — will be drowned out by calls to ban agents from the web. Sanity returns in year two. If you’re building agent infrastructure, bake in step-up auth and delegation revocation now, before you have to.

8. CAPTCHA-for-agents proposals like yesterday’s HN thread will recur. They’ll keep surfacing until the delegation infrastructure is visibly winning, because they’re the obvious incremental patch. I’d gently push anyone drawn to that framing to spend a week reading the MCP spec and the IETF delegation drafts instead.

Closing: The Web Wants Agents, Even If the Web Doesn’t Know It Yet

The web’s identity model — human versus bot, adjudicated by CAPTCHAs and risk scores — was adequate for an era where all accountable actors were humans. That era is ending. Agents are accountable actors that are not human. The sensible response is to update the identity model. The obstinate response is to ratchet up the old detection stack and play whack-a-mole with Browserbase clones.

I’ve spent a lot of words here because the problem is deeply underestimated. I’ll leave you with the operational mental shift that matters most: stop asking “is this traffic human?” and start asking “is this traffic accountable?” The answers to those questions used to be the same. They aren’t anymore. Every system you build from now on should reflect that, because the users on the other end — whether they’re typing with fingers or instructing an agent with natural language — are going to route around systems that refuse to recognize them.

My travel agent will book flights for me next year. The only question is which airlines accept its paperwork and which ones I’ll have to sign into manually, cursing each time. I know which list I want to be long, and I know which list will lose my business. So will yours.

The CAPTCHA era asked “prove you are human.” The agent era asks “prove who sent you.” Those are different questions, and the answer is not a harder puzzle. It is a signed chain of custody from a principal to a request. Build toward that, or be bypassed.