Who's knocking? How AI agents identify themselves to websites

On the night of September 20, 2026, Amazon slammed a door.

Try to buy something on Amazon through Meta's new Muse agent and you no longer get a cart. You get a wall, and a popup: "Continued access by an unauthorized AI agent violates Amazon's Conditions of Use."¹

Muse had launched twelve days earlier. Amazon had already asked Meta, privately, to exclude Amazon from the experience. Meta declined. So Amazon deployed an anti-bot wall that stops Muse before it can even load a search page.²

It is tempting to read this as another platform slap-fight between two giants, and there is real rivalry in it. But Amazon has the scale to build a wall in a weekend. You probably don't, and the same knock is already arriving at your server.

Because underneath the corporate drama sits a question every website owner now has to answer:

When an AI agent shows up at your door acting on behalf of a human, how do you know who, or what, is actually knocking?

If you've read the AI agent onion, you already know the request that finally reaches your server is a bare fetch carrying a User-Agent value like Claude-User. That User-Agent is a name the agent chooses to type - and right now, on your site, you are taking it on faith. The question is whether you can, whether you should, and what changes when you finally can't.

The old question: "is this a real person?"#

For thirty years the web ran on a crude but workable assumption: traffic is either a human in a browser or a bot. We built a whole immune system around telling them apart - CAPTCHAs, rate limits, IP reputation, the robots.txt honor-system that politely asks crawlers to behave, etc.

Identity, such as it was, lived in one spoofable string: the User-Agent header. Your browser announces Mozilla/5.0 (Macintosh...). Googlebot announces itself as Googlebot. And for decades, the way you verified "is this really Googlebot?" was to check that string against a published list of IP ranges.

Both halves of that check are weak: a User-Agent is just text - anyone can type anything, IP ranges are brittle to maintain, and anyone sharing that range can impersonate the bot. It mostly held together because the stakes were low: a lying crawler scrapes a page it shouldn't.

Agents break that assumption completely.

The new question: "is this a human, a bot, or a human through a bot?"#

An agent like Muse is not a crawler indexing pages. It is software that logs into an account, browses as the user, holds their credentials, and spends their money. It occupies a category the old human/bot binary never anticipated: authorized automation acting on a person's behalf.

That single shift detonates a pile of questions that used to be simple - and they land on your site, not just Amazon's:

• Consent. The human consented to the agent. Did they consent to it hitting your site? Did you consent to being hit by this particular agent?
• Attribution. If that agent submits a wrong order, a fraudulent signup, or a thousand form posts, who owns the mistake - the human, the agent's maker, or you, holding the logs that just say "a browser did it"?
• Credentials. To act "as the user," an agent needs their login to your service. Where does that credential live? Amazon's objection to Muse was exactly this: it claimed Muse "appears to capture and store customer credentials." Meta disputes it.¹
• Identification itself. Amazon's core complaint was that Muse "does not identify itself as an automated agent while browsing." It walks in wearing a human's face - which means your analytics, your rate limits, and your abuse rules are all reasoning about a visitor who doesn't exist.

That last point is the crux. Almost every downstream problem - consent, billing, liability, security - gets easier the moment the agent stops pretending to be a person and instead says, provably: "I am Meta's Muse agent, acting for this user, and here is proof."

Today, most agents don't. Not necessarily out of malice; the web simply never gave them a good way to.

How an agent could identify itself#

The interesting thing is that the fix is arriving in real time. Identification and authorization are not something that is new. For decades, websites have used various cryptography schemes to address identity and permission related issues. A standard called Web Bot Auth is being pushed through the IETF, backed by an unusually aligned group: Cloudflare, Amazon, Akamai, and OpenAI.³

The idea is to replace "guess the bot" with "prove the bot," using plain cryptography:

1. Every agent holds a private key (an Ed25519 keypair). Only the agent has the private half.
2. It signs every request using HTTP Message Signatures (the RFC 9421 standard), attaching a Signature-Agent header that names its signing domain.
3. The site verifies the signature against a public key the agent's maker publishes at a well-known URL (/.well-known/http-message-signatures-directory).

If the math checks out, the site knows, rather than guesses, exactly which agent is calling. A stolen or replayed request doesn't work, because each request is signed fresh. There is no User-Agent to spoof and no IP list to babysit.

In rough shape, a signed request looks like this:

GET /article HTTP/1.1
Host: example.com
Signature-Agent: "https://crawler.example-ai.com"
Signature-Input: sig1=("@authority" "signature-agent");keyid="..."
Signature: sig1=:MEUCIQ...base64...:

The site fetches the agent's published key, verifies the signature, and now has something it never had before: a name it can trust.

The catch: identity is not permission#

Web Bot Auth proves who's calling. It says nothing about whether the're allowed. It is an identity layer, not an access policy.

Today you can't make those choices, because you can't tell agents apart - so you're stuck with two blunt instruments: allow everything (and eat the risk) or block anything that smells automated (and lose the legitimate traffic too). Reliable identity replaces that with a menu you actually control, per agent:

• Allow it - welcome a well-behaved agent, maybe even ship an endpoint or a clean data feed built for it.
• Block it - refuse a specific agent by name, cleanly, without the collateral damage of a blanket anti-bot wall that also catches real customers.
• Charge it - "pay-per-crawl" and metered access become enforceable once you know who is on the other end. If an AI company's agent is reading your content to answer questions, verified identity is what lets you bill for it instead of just absorbing the cost.
• Sandbox it - let an agent read your catalog but not hit checkout; let it browse but not touch a credentialed action. Different rules for the same visitor, because you finally know which visitor it is.

So provable identity does not end the Amazon-Meta fight. It relocates it - from "I can't tell what you are, so I'll wall you off" to "I know exactly what you are, and I'm deciding, deliberately, whether you get in." For a site owner that is the whole game: a door with a lock and a guest list beats a door bricked shut. The catch is that the guest list only helps you once the agents on it actually sign - and today most don't.

What this means if you run a website#

You are not Amazon, so the practical question isn't "which agents do I bless?" - it's "what do I do right now, while the identity layer is still half-built?" A few things are already true and worth acting on:

• Agents are already reaching you, and you can't see them clearly. Some announce themselves with an honest User-Agent; many don't. Before you can decide policy, you need to know what agent traffic actually hits your site today - which paths, how often, identifying itself or not. Most owners have never looked.
• Don't reach for a blanket wall. Amazon could block Muse by name without hurting its business. A blunt "block anything automated" rule on a smaller site tends to catch the agents that send you customers - the ones summarizing your product, answering "where can I buy this," or checking your hours - right alongside the abusive ones.
• Decide what you want agents to do. For most sites the honest answer is: read freely, act carefully. You probably want an assistant to read your content and recommend you. You probably don't want an unidentified agent hammering a login form or a checkout. The split of open to reading, guarded on credentialed actions is a policy you can start forming now, before the tooling to enforce it arrives.
• Get ready to recognize the signature, not the string. When Web Bot Auth adoption grows, the sites positioned to benefit are the ones already thinking in terms of verified identity rather than User-Agent guesswork. The header is coming; treating a signed Signature-Agent as a first-class signal is the upgrade path.

Why we care about this layer#

The Amazon-Meta standoff is not fundamentally about Amazon and Meta. It is one of the first loud, public instances of a question the entire web now has to answer, and it lands hardest on the owners who can't build a wall in a weekend: agents are showing up wearing human faces, and the infrastructure to make them show ID is only half-built.

The technology to fix the identity half is essentially here. The genuinely unsettled half is policy - and for your site, policy starts with a much more basic thing than cryptography: being able to see agent traffic at all. You can't allow, block, charge, or sandbox what you can't distinguish from a person.

That visibility is the layer we work on. At Aandeg we're building Agent Assay, which requests your website the way an agent's harness does and reports what an agent actually experiences when it arrives. Today that answers can an agent even read my page? Identity is the next question stacked on top: not just whether an agent can read you, but which agent it is, and whether you'd want to let it do more than read.

The future web probably isn't human-or-bot. It's a lobby full of agents, and the site owners who do well are the ones who stopped guessing and started asking each one the same quiet question at the door:

Who's knocking - and who sent you?