The Verifier's Dilemma: Why the Strongest Verdict Is the Most Fragile

TI-2026-086L · Series: The Wardrobe · Case 12 · Classification: HIGH · Confidence: HIGH

The previous case showed an autoban that convicts a proven impostor on its first hostile request. That aggression rests entirely on one word — SPOOFED — and this case turns the light on that word. SPOOFED is the strongest signal the classifier produces: checked-and-contradicted provenance, the only verdict aggressive enough to unlock threshold-one banning. It is also the most fragile thing in the system, because it is only ever as true as the ground-truth ranges it checks against, and those ranges are a moving target. This is the case that keeps the whole series honest: the verifier does not compute the truth once; it maintains it, forever, against two cliffs.

Executive Summary

Every provenance verdict lives between two errors:

• False-verify — a spoofer read as VERIFIED and laundered into the allowlist. The cost: the wardrobe's costume works after all.
• False-spoof — a genuine crawler read as SPOOFED and wrongly convicted. The cost: you ban Googlebot, or (085C's real example) OpenAI's search bot.

The four verification methods the taxonomy uses each guard one cliff and expose the other, and each was confirmed failing-or-holding live via wt_agents_test:

The dilemma in one line: the SPOOFED verdict that lets 086K be aggressive is exactly the verdict that most depends on curation being current. You cannot be aggressive without being fresh. The resolution is not a fix but a posture — fail open for legitimate crawlers, prefer CIDR over ASN on shared clouds, require operator-owned rDNS, refresh ranges live, and mark the un-verifiable honestly. The verdict is a maintained artifact, not a computed fact.

The Two Cliffs

Picture the verifier walking a ridge. On one side is false-verify: make the check too loose and a spoofer's forged Googlebot passes as real, laundered straight into the allowlist the whole wardrobe exists to reach. On the other side is false-spoof: make the check too strict, or let it go stale, and a genuine crawler is convicted — the real Googlebot, or the real OAI-SearchBot that 085C found legitimately operating from Microsoft Azure.

These are not symmetric in consequence, and the series has always resolved the asymmetry the same way: a false-spoof is worse. Laundering one spoofer costs you one missed catch; convicting Googlebot costs you your search ranking, and convicting it automatically at threshold one (086K) costs you it for a week before anyone notices. So the ridge is walked with a deliberate lean — when in doubt, do not convict. Every design choice below is a way of staying on the ridge while leaning away from the false-spoof cliff, and the surprising part is how many different ways there are to fall off, one per verification method.

Method One: verify_asns and the Shared-Cloud Trap

The simplest verifier checks the operator's autonomous system: is this IP announced by the ASN the operator says its crawler lives on? For an operator that runs its own network — OpenAI's AS394699, Anthropic's AS399358 — this is tight and correct.

It collapses the moment the operator's "home" is a shared hyperscaler. Azure (AS8075), AWS (AS16509/AS14618), OVH, Akamai/Linode (AS63949), Fastly (AS54113) are single ASNs shared by millions of tenants. If you verify a crawler against one of those ASNs, you have not verified the operator — you have verified the entire cloud, and every impostor renting a VM there reads VERIFIED. That is the false-verify cliff in its purest form, and it is dangerous precisely because it looks like it is working: the check passes, the spoofer sails through.

The codebase treats this as a bug to be prevented mechanically, not merely avoided by discipline: a unit test, test_no_verify_asns_on_shared_hyperscaler, fails the build if any rule lists a shared hyperscaler as a verify_asns entry. The lesson from 086E — that a ClaudeBot on AWS is SPOOFED because Anthropic's real home is AS399358, not AWS — is the same lesson enforced structurally: an operator that lives on a shared cloud cannot be verified by ASN at all. It must be verified by the narrower ranges it actually announces.

Method Two: verify_cidrs and the Staleness Cliff

The fix for the shared-cloud trap is granularity: instead of "is it on Azure," check "is it in the specific CIDR blocks the operator publishes for its crawler." OpenAI's OAI-SearchBot carries verify_cidrs=35 — thirty-five published ranges — precisely so a genuine OAI-SearchBot on Azure verifies while an Azure impostor does not. This is the right tool, and it is why 085C's real crawler-on-a-stranger's-cloud could be cleared without clearing every tenant beside it.

But narrowness buys a new fragility: the ranges change, and the list can lag. Operators re-announce prefixes, add ASNs, rotate egress. The moment the published-CIDR list falls behind reality, a real crawler's new range is not in it — and the verdict swings to the false-spoof cliff. I demonstrated the coarse version live: wt_agents_test(OAI-SearchBot, asn=8075), tested with the Azure ASN and no member IP, returns SPOOFED — correct for an impostor, but a false-spoof for the genuine Azure-hosted OAI-SearchBot, and the only thing separating the two is whether the CIDR list is current and specific enough to contain the real one. CIDR verification trades the false-verify cliff for a false-spoof cliff whose depth is measured in curation lag.

Which is why the ranges cannot be static. The classifier supports pulling verify_cidrs live from RIPEstat and re-fetching them via wt_agents_refresh_cidrs. The verdict's freshness is an operational task with a clock on it: a verify_cidrs rule that is not refreshed is a false-spoof waiting for the operator to renumber.

Method Three: verify_rdns and the Generic-PTR Trap

Some operators do not publish ranges but do offer reverse-DNS verification: their crawler IPs resolve to a hostname under a domain they own. Amazonbot resolves under crawl.amazonbot.amazon; Ahrefs under ahrefs.net. Check the PTR, and you have a verifier that survives cloud-hosting.

The trap here is subtle and I confirmed it live. I asked the classifier to verify an Amazonbot whose reverse DNS was ec2-54-240-1-10.compute-1.amazonaws.com — a perfectly real AWS PTR — and it returned SPOOFED. Correctly. Because that is a generic hosting PTR, shared by every EC2 tenant, and the rule requires the operator-owned suffix crawl.amazonbot.amazon. A verifier naïve enough to accept "the PTR mentions Amazon" would false-verify every EC2 instance on the internet the moment it claimed to be Amazonbot. The discipline is exact: only an operator-owned rDNS suffix is proof; a generic hosting PTR is not. (The roadmap records the same trap for Bytespider, whose AWS nodes PTR to ec2-*.amazonaws.com — proof of nothing.)

There is a second wrinkle, rdns_ptr_only: some operators forward-confirm (the hostname must resolve back to the IP), and some (Ahrefs) publish PTR records with no forward record. A verifier must know which operators forward-confirm and which are legitimately PTR-only, or it will either false-spoof the honest PTR-only vendors or false-verify a forged PTR. Even the rDNS method, the most cloud-robust of the three, carries an operator-by-operator configuration burden.

Method Four: NO-VERIFIER and the Honest Non-Verdict

And then there are the operators who give you nothing. ByteDance publishes no fetchable range for Bytespider and offers no operator-owned rDNS. I tested it: wt_agents_test(Bytespider, asn=16509) returns UNVERIFIABLE — not spoofed, not verified, unverifiable. There is no discriminator to check, so no verdict is possible, and the classifier says exactly that.

This is the most important restraint in the whole system, because it is the one that refuses to guess. The temptation, faced with a Bytespider doing something hostile, is to convict it anyway on vibes. The taxonomy does not: with no verifier, the strongest available verdict is CLAIMED, and CLAIMED does not unlock threshold-one banning. The un-convictable frontier of 086E is, seen from here, the verifier declining to manufacture a verdict it cannot support. The cost is real — a Bytespider impostor keeps its permanent alibi — but the alternative (guessing) is the false-spoof cliff dressed up as diligence. Honest uncertainty is a feature, not a gap.

The Compounding Problem: Even the Lookups Go Stale

Underneath all four methods sits a dependency they share and none control: the data that maps an IP to an ASN in the first place. The classifier uses an offline iptoasn database, and that database goes stale for newly-allocated ASNs. The failure is silent and nasty: a verify_asns-only vendor whose ASN is too new to be in the offline DB silently degrades to CLAIMED — the check cannot even find the ASN to compare against, so it quietly stops verifying, with no error. A verifier can be perfectly configured and still fail because the ground beneath it — the IP-to-ASN map — has drifted.

This is why the honest description of the verdict is not "computed" but "maintained." Three separate clocks tick against it: the operator's ranges (which they renumber), the RIR/BGP reality (which the offline DB samples imperfectly), and the operator's ASN allocations (which appear before the DB knows them). Keeping SPOOFED trustworthy means keeping all three current. The verdict is a garden, not a formula.

The Dilemma Stated Plainly

Now put 086K and 086L side by side, because together they are the tension the whole series has been building toward.

086K is aggressive: it bans proven impostors at threshold one, automatically, for a week, at host and edge. That aggression is justified only because SPOOFED is a strong verdict. 086L shows that SPOOFED is strong only while it is fresh — and freshness is a maintenance treadmill with three clocks and four per-method traps. So the two cases are not independent; they are one coupled system. You cannot safely run the enforcement of 086K without continuously paying the curation cost of 086L. An unrefreshed CIDR list, a stale ASN DB, a generic-PTR rule slipped in, a shared-hyperscaler verify_asns — any one of them turns the aggressive autoban from a precise weapon into a false-spoof machine.

The system's answer is the posture already visible in 086K's guards, now seen as a coherent epistemics:

1. Fail open for legitimate crawlers. The autoban's VERIFIED_CRAWLER_ASN skip means a curation lapse produces a missed ban, never a false one — the lean away from the false-spoof cliff, made structural.
2. Match the method to the operator. CIDR (not ASN) for shared-cloud operators; operator-owned rDNS (not generic PTR); ASN only for operators on their own networks.
3. Refresh, live. verify_cidrs from RIPEstat, wt_agents_refresh_cidrs, so the ranges track reality.
4. Never manufacture a verdict. NO-VERIFIER is stated honestly; UNVERIFIABLE is a real answer.

None of these eliminates the dilemma — there is no verifier without a cliff. They manage it, by choosing, everywhere, to fall toward the cheaper error.

Steelmanning: "Then the whole enforcement stack is built on sand"

The sharpest objection turns the case against the series: if SPOOFED is this fragile — four traps, three staleness clocks — then 086K's automated banning is built on a foundation that can silently crumble, and the honest conclusion is that automated enforcement on this verdict is unsafe.

The objection is right about the fragility and wrong about the conclusion, and the difference is the direction of failure. A fragile verdict that fails open is not sand; it is a bias. Every trap and every clock in this case, when it slips, degrades SPOOFED toward CLAIMED or UNVERIFIABLE — a weaker verdict — not toward a false VERIFIED-of-a-spoofer or a false-SPOOF-of-a-real-crawler. A stale CIDR list makes a real crawler CLAIMED (unbanned), not SPOOFED (banned). A missing ASN makes a vendor CLAIMED (unbanned). A generic PTR is rejected (unverified), not accepted. The VERIFIED_CRAWLER_ASN guard makes a lapse a missed ban. The system is engineered so that its fragility spends itself on the cheap side of the ridge — false negatives, missed catches — and almost never on the expensive side. That is not a stack on sand; it is a stack that, when it shakes, drops the impostor's catch rather than the real crawler's freedom. Given that the alternative to an occasionally-missed impostor is an occasionally-banned Googlebot, the fail-open fragility is the correct design, not a flaw in it. The objection identifies the risk exactly and misreads which way it points.

What Holds, and What Is Bounded

Documented, HIGH confidence: the two-cliff frame; the four methods and their specific traps; the three live wt_agents_test demonstrations (generic-PTR Amazonbot → SPOOFED, Bytespider → UNVERIFIABLE, Azure-ASN OAI-SearchBot → SPOOFED); the shared-hyperscaler test guard; the offline-ASN-DB staleness degradation; the fail-open posture and its four policies.

Bounded: the rate at which curation actually lapses in production — how often a range goes stale, how long the ASN DB trails a new allocation. The failure modes and their directions are documented and reproducible; their empirical frequency is not measured here and is the natural monitoring follow-up (paired with 086K's error-rate follow-up, since they are one system).

Why It Matters

The Verifier's Dilemma is the case that refuses to let the series end on a note of triumph. Every prior case sharpened a signal or closed a loop; this one names the price. The powerful verdict at the centre of the whole method — SPOOFED, the checked-and-contradicted provenance that unmasks the wardrobe and unlocks the autoban — is not a fact the system possesses. It is a claim the system maintains, against operators who renumber, clouds that are shared, PTRs that lie by being generic, databases that trail reality, and a standing temptation to guess. Strong and perishable are the same property here: the verdict is strong because it checks against ground truth, and perishable because ground truth moves.

The defensive lesson is therefore not "verify identities" — every prior case said that. It is subtler and more durable: treat the verdict as a maintained artifact, and bias its failures toward mercy. Match the method to how each operator actually publishes; refresh the ranges on a clock; require proof that only the real operator could produce; and when you cannot verify, say so instead of convicting. Do that, and an aggressive autoban is safe because its worst failure is a missed impostor. Skip it, and the same autoban becomes the thing the series has warned against since 085C — a machine that convicts the innocent crawler with the confident air of a verdict. The mask convicts the wearer only as long as the verifier convicts nothing else. Keeping that true is not a one-time build. It is the work.

Cross-references

• TI-2026-086E — The Newest Trust — the operator-ASN verifier and the NO-VERIFIER frontier this case stress-tests.
• TI-2026-086K — The Mask That Convicts — the aggressive autoban whose safety depends entirely on this verdict's freshness; the two are one coupled system.
• TI-2026-085C — Verified, and Still Where It Shouldn't Be — the canonical false-spoof (a real OAI-SearchBot on Azure) this case generalises.
• TI-2026-086A — The Wardrobe Rack — the SPOOFED verdict, first defined, here examined for its failure modes.

Next in the series — TI-2026-086M, The Operators Behind the Rack: turning the entity graph on the fleets themselves — the deferred question of who, and whether the wardrobe is one operator, a service, or a crowd.

TLP:WHITE. Defensive methodology and impersonated brands only. No internal addresses or secrets disclosed. Empirical curation-lapse rates explicitly left as a monitoring follow-up.