Part 9 of this series named a fleet. Twenty-three addresses inside a single Amazon 216.73.217.0/24, all announcing themselves as Anthropic's crawler, presented as the lead illustration of a new kind of identity theft — attackers renting cloud instances and painting on the newest trusted name.

The fleet does not exist. Those twenty-three addresses were the real ClaudeBot.

This is the retraction, published beside the original rather than folded into it.

The artifact that settles it

Anthropic publishes its crawler prefixes. The feed is at claude.com/crawling/bots.json:

{
  "creationTime": "2026-05-01T20:46:04Z",
  "prefixes": [
    {"ipv4Prefix": "216.73.216.0/22"},
    {"ipv4Prefix": "34.162.230.222/32"},
    {"ipv4Prefix": "34.162.244.71/32"},
    ...
  ]
}

Twenty prefixes. The first is 216.73.216.0/22.

That range spans 216.73.216.0 through 216.73.219.255. It contains 216.73.217.0/24.

Containment is arithmetic. There is no interpretation step, no confidence interval, no room for a second reading. Every address in the retracted fleet sits inside Anthropic's published crawler egress.

Re-tested against the corrected verifier, 216.73.217.42 carrying the ClaudeBot user-agent now returns verified where it previously returned spoofed.

The premise that failed

Part 9 did not guess. It reasoned, and the reasoning was stated plainly:

"OpenAI's ChatGPT-User egresses from OpenAI's own published ranges; Anthropic's ClaudeBot from Anthropic's; neither routes its fetches through Cloudflare Workers or rents AWS instances to crawl from. So an address on Cloudflare or AWS, connecting directly, announcing itself as ChatGPT or ClaudeBot, is not a mislabeled real bot."

The first clause is correct. ClaudeBot does egress from Anthropic's published ranges.

The second clause is where it breaks, and it breaks on a structural detail nobody checked: one of those published ranges is AWS-announced space.

ARIN shows 216.73.216.0/22 as a customer reassignment under Amazon's parent allocation 216.73.208.0/21, carrying NetName AWS-ANTHROPIC and abuse contact arin@anthropic.com. It is announced from AS16509 — Amazon's ASN, not Anthropic's AS399358.

So "on AWS" and "inside Anthropic's published egress" are not mutually exclusive. The argument assumed they were. For this one prefix, staging ground: Amazon was evidence of nothing at all.

Why the same reasoning convicted correctly elsewhere

This matters for how much of Part 9 falls, and the answer is: one row.

The inference holds for the other operators because their published feeds genuinely exclude the clouds where the impostors were found.

Corrected roster: approximately 137 forged addresses, not approximately 160. A fourteen percent reduction, not a collapse.

And Part 9's actual thesis — that crawler-identity theft migrates to whichever names have most recently become valuable — survives intact. If anything the correction strengthens it, because the surviving forgeries cluster on precisely the names that are hardest to check.

The detector had never once worked

The uncomfortable part is not the wrong verdict. It is that the machinery which produced it could not have produced any other.

The verifier rules for the three Anthropic crawler identities checked against AS399358 and the CIDR 160.79.104.0/23.

160.79.104.0/23 is not crawler egress. Anthropic's platform documentation lists it as the inbound API endpoint — the addresses where Anthropic receives connections — alongside 160.79.104.0/21 for outbound API tool calls and five phased-out ranges operators should delete from their firewalls.

A crawler verifier had been configured with an API firewall range taken from a different document entirely.

The consequence is total. No genuine ClaudeBot request could ever have satisfied that rule. Every real visit was scored spoofed by construction, for as long as the rule existed — and a detector that has never once returned its positive verdict looks exactly like a working detector, provided you assume the positive case is rare.

Which is precisely the assumption under which impersonation findings get written.

The rule that replaces it

An allocation's announcing ASN says nothing about whose traffic it carries.

Hyperscalers reassign customer blocks under their own parent allocations and announce them from their own ASNs. First-party vendor infrastructure and rented tenant space are therefore indistinguishable at the ASN layer by construction. Any inference shaped like "it came from a hyperscaler, therefore it is not the vendor" is a category error, and it will get worse as more vendors host inside cloud address space.

The only sound test is CIDR containment against the vendor's own published prefix feed. Not the ASN. Not the RIR organisation name. Not reverse DNS, unless the vendor documents rDNS as the verification method — as Amazon does for Amazonbot.

There is a corollary worth stating separately, because the obvious repair is a worse bug than the defect:

Never fix an ASN mismatch by adding the announcing ASN.

Adding AS16509 to the verifier would have made the test pass. It would also have verified every EC2 instance on earth as ClaudeBot. Widen the CIDR list from the published feed; never widen the ASN list. A detector that fails closed on a legitimate visitor is recoverable. One that fails open on a fleet is not.

The sharpest illustration is in the data. Anthropic's published feed contains nineteen Google Cloud /32 addresses. So "it came from GCP" is no longer disqualifying for ClaudeBot either — while 34.44.177.159, a GCP address that wore the ClaudeBot name to probe /.env, /.env.php.bak, /.streamlit/secrets.toml and /secrets.json, remains spoofed. Same cloud, opposite verdict. Containment decides; the cloud never did.

Why this is an addendum and not an edit

Part 9 could have been quietly amended. One table row changed, one sentence softened, one total moved from 160 to 137. It would have taken minutes and left the corpus looking cleaner than it is.

Nothing would then record that a confident verdict was once issued against a legitimate visitor, on reasoning that looked sound, by a detector that had never worked.

That erasure would be the more serious error. A body of work whose entire value rests on being checkable has to be checkable about itself. A retraction that leaves no trace teaches nothing — not to a reader deciding how much weight to give the next attribution, and not to whoever writes it.

So the original stands. This is bound to it in both directions, and the two should be read together.

TI-2026-065C set the precedent from the other side: a negative result published specifically so that an attractive, unfalsifiable claim could never be made. This is the same discipline applied after the fact, to a claim that was made.

The verdict was wrong. The method that caught it is the same method that produced it — containment against a published list — applied, this time, to a list that had actually been read.