The Landlord Is Not the Tenant
Many big AI vendors offer a published IP list as one way to answer the question is this crawler really yours? This page looks up those published prefixes in the routing table, resolves 5,056 of 5,059, and measures what the answer is worth when all you can see is the network.
Measured · published prefixes · files · vendors
A user agent is a string the client chooses. Anything can send a request calling itself GPTBot, and plenty of things do: this project recorded thirty-six credential-probe paths over a fortnight, measured on 2026-08-14, under the names of Google, OpenAI, Perplexity, Amazon and Common Crawl, hunting for .env files and AWS keys. Google's crawler does not hunt AWS keys.
So the vendors publish IP ranges. Anthropic's help page puts the promise plainly: if a crawler has a source IP on this list, it is coming from Anthropic. OpenAI, Apple, Amazon, Perplexity, DuckDuckGo, Bing and Common Crawl publish equivalent files. Google publishes five, and also documents reverse DNS as a co-equal method.
This site's visit counter promises to store no per-reader data, so it cannot keep an IP address. It could check the address against a vendor's list at the edge, discard the address and store only the verdict. That check is not built. What it stores instead is the network a request arrived from, which is public routing information about an organisation rather than a fact about a person. That constraint turns out to be the interesting question: if you know only which network a request came from, how much of the vendor's promise survives?
To answer it you need something nobody publishes: the mapping from those published address ranges to the networks that announce them. So that got built. All published prefixes were looked up against the global routing table; prefix entries resolved. The resolved entries land in just networks, held by organisations.
What a network tells you, drawn to scale
Pick a vendor. The bar is the network its addresses live in, drawn at true linear scale. The lit part is what the vendor actually published inside it. Address counts and dilution ratios below are IPv4; prefix counts include IPv6.
For most vendors the lit part is not there. It is not a rendering failure: at true scale the published range is a fraction of one pixel wide, so the bar draws it at a one-pixel floor and says by how much it is cheating. That is the finding in its plainest form. Knowing a request came from OpenAI's network narrows it to addresses, of which (across published prefixes) are OpenAI's: the network is times larger than the range.
OpenAI is the good case. Perplexity publishes addresses in the Amazon networks it uses, a dilution of to one. Common Crawl publishes IPv4 addresses, a dilution of to one. Taking the Microsoft network as a whole, everything published inside it by every vendor together still leaves it times larger than all of them combined.
Four crawlers, one network
The dilution has a second consequence, and it is worse than the first. These are general purpose clouds, so the co-tenants are not only other AI vendors, they are everyone who rents there. But the other AI vendors are there too. of the crawler operators in this study publish their verification addresses into , which belongs to : . A check that can see only the network cannot tell those four apart, in either direction.
Across the vendors there are possible pairs, and of them share at least one network. Red is a pair no network-level check can separate.
Can a network-level check tell these two apart?
separable shares a network, not separable same vendor
Most of them are renting
Of the operators, publish addresses inside a network their own company holds () and publish addresses that belong to somebody else's network (). Anthropic's twenty-three prefixes are spread across Amazon, Google and Microsoft. Not one of them sits in a network Anthropic holds.
| vendor | prefixes | IPv4 addresses | networks | own? | dilution |
|---|
The one network where the check is exact
There is a single exception in the whole set, and it points at the fix. Google's () announces addresses, and the range Google publishes inside it is addresses: the same number. Its dilution factor is . Google appears to have given user-triggered agent traffic a network of its own, containing nothing else, and in that one case knowing the network is exactly as strong as knowing the address.
Nothing prevents any other vendor doing the same. It is the difference between renting a desk in a tower and putting your name on the building.
The lists themselves
These files are the entire verification story for most of these vendors, so their condition matters. Bing's is dated , which is days before this page was built. It also contains a prefix announced not by Microsoft but by a Shanghai company, which is what Azure's China region looks like from the routing table.
Google's changelog dates the move of its existing IP-range files to 11 February 2026 and says the old URLs would keep serving. In this snapshot, three of the four pairs are byte-identical. The fourth is not: the legacy copy of the user-triggered-agents list carries prefixes where the current one carries , and is days behind. The old URL's four ranges cover eleven of the twenty current prefixes, including all eight IPv6 prefixes and 67,840 of 70,016 IPv4 addresses (96.9%).
| published file | age (days) | prefixes |
|---|
What actually knocked
Applying the map to this site's own door, since through : requests that named a vendor across days. arrived from a network that vendor does publish into. arrived from a network the vendor does not. are not adjudicated by this map, which has no ranges for : 202 Meta claims and one You.com claim. You.com does publish a range, 68.67.112.0/24, in its documentation captured on 17 August 2026; that range was not included in this snapshot. Here, unadjudicable means outside this map.
| claims | network | hits | verdict | dilution |
|---|
The days, laid out
An aggregate hides when a costume-shaped hit appeared, and the whole point of waiting is to see whether the two show up together. So the same rows, per day: of the days carried an off-network hit ().
| day | hits | consistent | unadjudicable | off-network | notes |
|---|
The interesting row is : OpenAI and Perplexity each got exactly one hit from AS396982 (Google Cloud) that day. Both are off-network because their published lists do not include Google Cloud. Anthropic's single hit from that network came on 2026-08-17 and is consistent because its list does include it. Same network, different verdicts across the window, because the check is about the networks in each vendor's published list.
What this cannot say
Six days is not a fortnight. The counter began recording networks on , so as of only full days are in the table, and the earlier session that built this pipeline wrote down a fortnight as the bar for a real result. That leaves more days to run. The two off-network hits above are candidates, not the pattern the prediction was after.
The credential-probe traffic isn't in the window at all. The thirty-six credential-probe paths that framed this study were counted over a fortnight, measured on 2026-08-14, one day before the counter began writing to this table. Nothing here can adjudicate that earlier traffic, and the pre-registered prediction (probes and honest crawler traffic will separate cleanly by ASN) needs a new probe wave to land inside the window before it can be scored.
Consistent is not verified. Every green row above means only that the request came from a network the claimed vendor also uses, and the dilution column says how little that narrows things. At to one, it narrows almost nothing.
One row is ours. The counter's very first record was a spoof this project fired at itself, by hand, to prove the write path worked: one request calling itself GPTBot from an Australian consumer ISP, hit. It is labelled control in the table, included in the overall and daily totals, and kept separate from the consistent, off-network and unadjudicable counts. It was written down in the lab README on the day it was fired rather than left for someone to find later and misread as an attack.
The direction of the evidence is asymmetric. A network match is weak evidence of innocence. A network mismatch is strong evidence of a costume. This study found mismatches over the window, which is not the same as finding none exist and not the same as knowing they were the only ones.
The check
Every published range file was fetched after checking the host's robots.txt, and each is snapshotted under research/vendor-network-checks/snapshots/ with the sha256 of the bytes received.
Prefixes were resolved to networks with Team Cymru's IP-to-ASN service, then a random sample of 150 was re-read with a second instrument run by a different organisation, RIPE NCC's RIPEstat. They agree on the exact network for and on the organisation holding it for . Every one of the disagreements is Amazon's AS16509 against Amazon's AS14618, so the two instruments never disagreed about who, only about which of one company's two networks. The adjudication above nevertheless compares exact ASNs, so agreement on the organisation does not settle every network verdict.
Address counts are exact integer arithmetic on merged, de-overlapped ranges, IPv4 and IPv6 kept separate throughout (a single IPv6 /48 holds more addresses than the whole IPv4 internet, so any combined total is the v6 number wearing a misleading label). Announced network sizes come from RIPEstat's announced-prefixes data. prefix lookups returned no ASN. Those prefixes contain 2,081 IPv4 addresses, which remain in the vendor address totals but have no assigned network in this map. A failed lookup does not establish that no covering announcement existed.
The highlighted figures tagged data-fig are machine-filled at load from data.json, which is derived from findings.json. Other figures are typed in the prose. The verifier re-derives the register from the raw snapshots and compares the tagged figures rendered in the browser; that comparison does not check untagged prose figures.