Which AI operators can actually prove who they are, and which can't. First of a monthly series.
There's a standard for AI agents to prove their identity cryptographically, and there's a widespread assumption that it's basically solved now. It isn't. This post is an attempt to track, monthly, what's actually true — because the gap between "there is a standard" and "the traffic hitting your server carries a signature" is where every practical decision lives.
Everything below is checkable. Where an operator publishes a file, the URL is given; where one doesn't, that's stated plainly rather than left as an absence.
Three kinds of evidence
A request claiming to be GPTBot can carry three different things, and they are not equivalent:
| Evidence | Proves | Fakeable |
|---|---|---|
| A name in the User-Agent | nothing | trivially, by anyone |
| An address in a published range | the request left that operator's network | very hard |
| A Web Bot Auth signature | the identity itself | not without the private key |
Most discussion treats the first as if it were the third. Most tooling still acts on the first.
Signatures: who signs today
Web Bot Auth builds on RFC 9421 (HTTP Message Signatures) with Ed25519 keys. The agent signs each request and publishes its public key at /.well-known/http-message-signatures-directory. The IETF working group was chartered earlier in 2026; the architecture draft is at -05.
| Operator | Signs | Notes |
|---|---|---|
| Google (Google-Agent) | Partially | Signs a subset of agent traffic as agent.bot.goog. Google states explicitly that not all its agents use the protocol. |
| OpenAI (Operator / ChatGPT agent) | Partially | Named as a partner in Akamai and AWS documentation. No confirming documentation from OpenAI itself. |
| Anthropic | No | No documented support. |
| Perplexity | No | No documented support. |
| Mistral | No | No documented support. |
| DeepSeek, Qwen, Moonshot, Zhipu | No | No documented support. |
| Googlebot (indexing) | No | Distinct from Google-Agent; does not sign. |
Practical reading: if you check signatures today, you'll verify some Google-Agent traffic and possibly some OpenAI agent traffic. Everything else arrives unsigned — and unsigned means unknown, not fake. Any tool that flags every unsigned ClaudeBot as an impostor is lying to you.
The infrastructure side has moved faster than the agent side. Cloudflare activated verification at its edge in March 2026; AWS WAF, Vercel, Shopify and Akamai have shipped support. The verifiers are ready. There isn't much to verify yet.
Published IP ranges: who lets you check
This is the part that works right now, and it's underused. Several operators publish the addresses their crawlers use, in a machine-readable format, so any site can confirm that a request claiming a name actually came from that operator's network.
An address is far harder to fake than a name: establishing a connection requires packets flowing in both directions, so a forged source address never completes a request.
Publishing:
| Operator | Location |
|---|---|
| OpenAI — GPTBot | openai.com/gptbot.json |
| OpenAI — SearchBot | openai.com/searchbot.json |
| OpenAI — ChatGPT-User | openai.com/chatgpt-user.json |
| Google — indexing crawlers | developers.google.com/static/crawling/ipranges/common-crawlers.json |
| Google — user-triggered agents | .../ipranges/user-triggered-agents.json |
| Google — special crawlers | .../ipranges/special-crawlers.json |
| Perplexity | published |
| Common Crawl | published |
| Bing | published |
Not publishing: Anthropic, DeepSeek, Mistral, Qwen, Moonshot, Zhipu, ByteDance.
That second list matters more than it looks. ClaudeBot is among the most common AI crawlers on the open web, and there is currently no way for a site owner to confirm that a request claiming to be ClaudeBot is one. Neither a signature nor an address list exists to check against. Reverse DNS is the only fallback, and it's slower and weaker.
A trap worth knowing about
Google moved these files in 2026 — from /search/apis/ipranges/ to /static/crawling/ipranges/ — and renamed googlebot.json to common-crawlers.json.
The old URLs did not redirect and did not error. They began returning 200 with an unrelated payload. Anything parsing loosely got a successful response, found no prefixes, and carried on with an empty allowlist — verifying nothing, with nothing to notice.
If you've implemented range checking against the old paths, it is silently doing nothing. The defensive pattern: treat "parsed successfully but zero prefixes" as a failure, never as an empty list. And when a list can't be loaded, the verdict should be unknown, never mismatch — an outage at the operator's end must not turn genuine crawlers into accusations.
What this means for a site owner today
Checking signatures alone verifies a few percent of agent traffic. Correct, but thin.
Checking published ranges verifies a large share of the named traffic that actually matters — OpenAI's crawlers and Google's — and does it today, with a public file and an HTTP request.
Checking names verifies nothing, which is what most hosting-provider bot rules currently do.
Nothing verifies traffic that makes no claim. The largest category by volume sends an ordinary browser user-agent and no signature. There is no claim to check. Behavioural signals catch the crude ones; the careful ones are indistinguishable at the HTTP layer, and I've tested this with a real headless fetch that scored 18 out of 100 on a behavioural scale where 45 means "probably automated."
What I'll be tracking
Monthly, in this format:
- Which operators began or stopped signing
- Which published or withdrew IP ranges
- Changes to the Web Bot Auth drafts and working group
- Where published files move, since that has already broken silently once
The intent is a reference someone can check rather than a set of claims someone has to trust. Corrections welcome and will be published with attribution.
Method
Signing status: operator documentation, plus observed traffic on monitored sites. Range publication: fetching each file and confirming it parses to a non-empty prefix list. Draft status: IETF datatracker.
Where an operator's documentation and observed behaviour disagree, both are noted. Where I can't confirm something, it's marked unconfirmed rather than omitted.
Next edition: August 2026. The underlying registry — agent names, categories, signing status, published ranges — is maintained openly at crawlprint.com, and corrections are welcome.