The Unmasking · 3 — Verified, and Still Where It Shouldn't Be: When the Name Is Right and the Reach Is Wrong

The Unmasking — Case 3. This register takes what a visitor claims to be — the identity written in its User-Agent — and reads it for the one thing the claim cannot survive on its own word: whether it is true. Closing each case on a confidence verdict the evidence can bear: VERIFIED · CLAIMED · SPOOFED · UNVERIFIABLE.

The first case read the truest claim and the second the falsest, and between them they might seem to have drawn the whole map: verify the honest, convict the liar, and the identity question is answered. This case reads the visitor who breaks that map. Its claim is as true as the training crawler's — checked against a published provenance and confirmed, a genuine, named, corporate search crawler, no impostor anywhere in it. And it reached, all the same, for a resource on a host that was never meant to receive a crawler at all: the robots.txt of a private code repository, the polite first knock of an indexer at a door that should not have been visible to knock on. The identity is not in question here. The scope is. And the case exists because verification — the instrument that resolved Cases 1 and 2 so cleanly — has nothing to say about scope, and mistaking the one for the other is the specific error this case is built to name.

The visitor is OpenAI's search crawler, OAI-SearchBot, and the register confirmed it: the User-Agent claim tested against OpenAI's published search-crawler ranges, verdict VERIFIED. It made fourteen requests over three days, all of them ordinary GETs, none of them an exploit path, carrying no abuse reputation and no threat score. And seven of them were addressed to /robots.txt on lsn-git.shuffle-on.com — a private, authentication-gated Gitea that hosts source code and was never published, never linked, never meant to be indexed by anyone. The crawler did nothing a crawler does not do. It simply did it against a host where doing it was the finding.

1. Verified Across a Borrowed Network

Begin with the identity, because it is settled and the settling is instructive. The visitor arrived from 74.7.230.57, an address on AS8075 — MICROSOFT-CORP-MSN-AS-BLOCK, network-operated by Microsoft. Every coarse signal, exactly as in the previous case, points at the wrong owner: the org is Microsoft, the Autonomous System is Microsoft's, and a verifier asking whose network is this? would answer Microsoft and mislabel an OpenAI crawler as a Microsoft one. The visitor is not Microsoft's. It is OpenAI's search crawler running on Microsoft's Azure cloud — a real crawler hosted on rented infrastructure that belongs to a different company entirely, because OpenAI's compute lives largely on Azure and its crawlers egress from there.

This is the precise mirror of Case 2, and reading the two together fixes the method's core rule from both sides. In Case 2 an impostor sat on the real owner's cloud — a fake Googlebot on Google's own GCP — so the naive ASN check produced a false positive, laundering a scanner into a verified crawler. Here a genuine crawler sits on another company's cloud — a real OAI-SearchBot on Microsoft's Azure — so the naive ASN check produces a false negative, misattributing OpenAI's crawler to Microsoft. One error in each direction, and the same fix answers both: identity is not where you are hosted; it is where you are published to operate from. OpenAI publishes the ranges its search crawler egresses from, and the register verifies 74.7.230.57 against those — not against the Azure ASN it happens to share with Bingbot, with rentable VMs, and with the fake-crawler traffic of the last case. The CIDR check is authoritative precisely because the ASN is not: a shared cloud tells you whose data-center the packet left, and the published ranges tell you whose crawler sent it, and only the second is the identity. Verdict: VERIFIED. This is genuinely OpenAI, and the case proceeds on that footing — not despite the verification but because of it, because everything interesting about this visitor depends on its being exactly who it says.

2. The Reach

Now what it did, told plainly, because the plainness is the point. Fourteen requests, all GET, over three days. Two distinct paths. The target that matters: /robots.txt on lsn-git.shuffle-on.com, requested seven times. robots.txt is the most innocent thing a crawler fetches — it is the file a well-behaved indexer requests first, before anything else, precisely to ask permission: what here may I crawl, and what must I leave alone? Fetching it is not an attack; it is the opposite of an attack, the crawler announcing its intention to obey the rules and asking to be told what they are. A verified search crawler fetching robots.txt is, in isolation, the single most law-abiding act in the whole register.

The finding is not the act. It is the host the act was addressed to. lsn-git.shuffle-on.com is a private Gitea — a source-code repository behind an authentication gate, not published in any index, not linked from any public page, not intended to be discoverable by a search engine at all. A crawler fetching its robots.txt is a crawler that has found it — that has a hostname it should not have, and has begun, in the politest possible way, the handshake by which a public site gets indexed. The reach was courteous and it was also a reach toward the private: the beginning of an indexing relationship with a host whose entire design premise is that no such relationship should exist. Nothing in the conduct is hostile. Everything in the conduct is a verified public-web crawler treating a private code server as though it were part of the public web — because, from where the crawler stood, it was reachable enough to try. The register does not read malice here, and will not pretend to. It reads a verified crawler at the threshold of a door that should not have been in front of it, doing exactly what crawlers do at thresholds: knocking.

3. The Boundary Answered — Not the Identity

What happened next is the case's heart, because it shows which of the infrastructure's defenses actually held the line — and it was not the one the previous two cases might have led you to expect. The request for lsn-git's robots.txt did not return the file. It did not return a 404 either. It was intercepted: a 302 redirect to lsn-auth.shuffle-on.com, the authentication proxy, which served its login page at 200. The crawler asked a private host what it was permitted to index, and the private host's authorization boundary stepped in front of the question and answered with a login prompt — not the robots.txt, not the repository, not even the confirmation that a repository was there. The reach was blunted at the boundary, and lsn-git stayed private.

Read carefully what did the blunting, because it is the lesson. It was not the crawler's identity. The register's verification of OAI-SearchBot as genuinely OpenAI changed nothing about this exchange and would have changed nothing had it come back SPOOFED — the authorization boundary intercepts the request the same way regardless of who sent it, because it gates on authentication, not on identity-verification. It was not the crawler's good manners, either; the crawler's courtesy in asking robots.txt first is what a polite indexer does, but courtesy is not a control the defender operates. The thing that kept the private host private was the authorization boundary — Authelia's forward-auth, sitting in front of lsn-git, requiring a login that a crawler cannot present. And this is the case's central correction to the two before it. Against the honest taker of Case 1, verification gave knowledge and no leverage; against the liar of Case 2, verification gave decisive leverage; against this visitor — verified, honest, and reaching where it should not — verification gives neither, because the verified identity is impeccable and the problem is not the identity at all. The instrument that answers the verified overstepper is not the one that reads who it is. It is the one that decides what it is allowed to reach — and those are different instruments, sitting at different layers, and the register insists on not confusing them.

4. The 200 Mask

There is a forensic layer under this exchange that is worth surfacing, because it is the mechanism that lets the register see the reach at all, and it is the same mechanism that could have hidden it. When the boundary intercepted the crawler's request, it returned 200 — the login page — rather than the 404 an unprotected host would have returned for a path it did not have, or the 401 a naive gate might have returned to announce that authentication was required. That 200 is a mask. To a scanner, and to a naive log reader, an HTTP 200 reads as success — the request worked, the resource is there — and so a forward-auth proxy that answers every probe with a 200 login page makes every probe look like a satisfied request, erasing the distinction between "this resource exists and you reached it" and "this resource may or may not exist and you were stopped at the door." The private host does not even confirm its own existence; the boundary swallows the probe and returns the same bland 200 to everyone, and the scanner learns nothing.

That masking is a defense, and it is also, for the register, an obstacle — because a stream of 200s hides the intent of everything behind it, the polite crawler and the malicious scanner alike reduced to identical success lines. The register sees through it here for one reason: the interception encodes the true target in the redirect it issues. The login request carried the parameter ?rd=https://lsn-git.shuffle-on.com/robots.txt — the rd (redirect) field that the auth proxy uses to remember where to send a user once they log in, and which, decoded, states exactly what the crawler was reaching for: lsn-git's robots.txt. So the register recovers the reach not from the 200, which reveals nothing, but from the target the 200 was masking — the decoded redirect parameter that names the private host and the private path behind the login page. This is the whole reason the register can exist: an infrastructure that answers probes with a uniform 200 has, by default, blinded itself to what those probes wanted, and the work of the register is to pierce that mask — to read, behind the wall of successes, which visitor reached for what. The verified crawler's reach for lsn-git is legible only because the disambiguation decoded what the 200 was hiding. Without it, the most consequential fact of this case — that a verified search engine found and knocked on a private code server — would have been one more 200 in a log full of them.

5. Identity Is Not Scope

Here is the lesson the case is built to carry, and it is a single sentence with a long shadow: verification tells you who the visitor is, and says nothing whatever about whether this visitor should be where it is. The two questions feel adjacent — who are you and should you be here — and they are not adjacent; they are answered by different evidence, at different layers, and a defender who lets the first stand in for the second has made a category error that this visitor exposes exactly.

OAI-SearchBot is verified. That verification is a fact about identity: it certifies that the visitor is the crawler it claims, operated by the company it names, egressing from the ranges that company publishes. It certifies nothing about authorization — about whether this particular host, this particular path, is one the crawler ought to have reached. And the two come apart completely in this case, because the identity is perfect and the scope is wrong: a genuine, blameless, verified crawler reached a resource that no crawler, genuine or otherwise, should have been able to reach. The risk the case surfaces is therefore not a property of the visitor — there is nothing to fix about OAI-SearchBot, which behaved impeccably for what it is — but a property of the exposure: a private host was reachable enough, discoverable enough, to receive a search crawler's handshake, and that reachability is the finding. A verified crawler is a sensor for exposure precisely because it is honest: it will crawl whatever it can reach, announce itself while doing so, and thereby mark, in the logs, every private surface that turned out to be publicly reachable. The verified crawler that oversteps is not a threat to be blocked; it is a measurement of a boundary that was thinner than it should have been. Read that way, this visitor did the defender a service — it found the thin spot and, being verified and logged, showed exactly where it was. The lesson is not distrust the verified; it is do not mistake a verified identity for an authorization decision — the name being right is no assurance the reach was right, and only the boundary, never the identity, can decide the reach.

6. Three Postures of Verification

The register pauses to draw the three cases together, because OAI-SearchBot completes a figure the first two only began, and the figure is the whole point of reading identity at all. Verification stands in three different relations to control, depending on the visitor, and the same instrument produces a different consequence in each.

Against the honest taker of Case 1 — GPTBot, verified, blameless, extracting at scale — verification produced knowledge without leverage: it named the taker with certainty and gave no power to stop it, because the taker broke no rule and a true identity is no grounds for a block. Against the liar of Case 2 — the fake Googlebot on Google's cloud — the same verification was decisive: the checked claim came back false, and the false claim was itself both disqualification and evidence, so verification convicted and the impostor was banned within the hour. Against the overstepper of Case 3 — OAI-SearchBot, verified, honest, reaching for a private host — verification is neither knowledge-without-leverage nor a conviction; it is simply the wrong instrument, because the identity is impeccable and the question the case raises is not one identity can answer. Knowledge without leverage, decisive leverage, and no leverage of the relevant kind at all: three postures, and the difference between them is not in the instrument, which is one instrument, but in what the visitor is — honest-and-permitted, dishonest, or honest-and-mis-scoped. The synthesis the register wants on the record is this: verification answers exactly one question — who is this — and that answer is powerful against the liar, impotent against the honest taker, and beside the point against the honest overstepper. Whether a visitor should be where it is is never an identity question and never has an identity answer; it is an authorization question, decided at the boundary, and the entire error the third case exists to name is the reflex that treats a verified name as though it settled it. The name settles who. The boundary settles whether. Confuse them, and a verified crawler's handshake at the door of your private repository reads as safe, it's really OpenAI — when the only thing that kept it safe was a login prompt that never cared who was asking.

7. The counter-narrative, steelmanned

The strongest objection to this case is that it is a story about a system working perfectly, dressed up as a story about a risk. A verified, well-behaved search crawler, the objection runs, fetched a robots.txt, was intercepted by an authentication proxy, saw a login page, indexed nothing, and left — abuse score zero, threat score zero, not one byte of the private repository disclosed. The defense did exactly what it was built to do; the private host stayed private; the "reach" was the most courteous request a crawler can make and the "boundary" answered it flawlessly. To narrate this as a verified visitor "where it shouldn't be" is to manufacture alarm from a non-event and, worse, to malign a crawler for its virtues — for asking permission, for announcing itself, for obeying the very conventions that make it safe. If anything, the objection concludes, this case is evidence for the defense's competence, and the register has inverted it into an indictment of the most innocent visitor it will ever examine.

The register agrees with every fact and accepts none of the framing, because the objection is attacking a claim the case does not make. The case does not indict the crawler; it says, in as many words, that OAI-SearchBot behaved impeccably and that there is nothing to fix about it. The case does not claim the defense failed; it says the defense succeeded, and it makes the success the centerpiece — the whole of section 3 is that the boundary held. What the case claims is narrower and survives the objection intact: that the thing which held was the authorization boundary and not the verified identity, and that keeping the two distinct is a lesson worth the space, because the failure mode it guards against is real and common. Picture the identical visitor against a host that was not behind Authelia — the same verified, blameless OAI-SearchBot, the same courteous robots.txt fetch, but no login proxy in front of it. It would have received the real robots.txt, learned what it was permitted to index, and begun indexing a private code repository into a public search engine — and every signal a naive defender reads would have said safe: verified crawler, 200 responses, no abuse, no threat, a textbook-polite indexer. The verification that reassures is exactly what would have disarmed the defender, because "it's really OpenAI" feels like a safety property and is not one. So the case is not alarm from a non-event; it is the non-event read for what it teaches — that the boundary, not the name, is the control, and that a verified identity is a sensor for exposure precisely because it is honest enough to walk up to every thin spot and knock. The defense worked here, and the register says so plainly and credits it. The register also insists that why it worked be stated correctly, because the next host may not have the boundary, and a defender who learned the wrong lesson from this success — verified crawlers are safe — is exactly the defender who will be undone by the same crawler tomorrow. No individual is named; OpenAI's crawler and OpenAI's corporate identity are matters of public record, and no person is attributed. Classification: TLP:WHITE. The name was right, the reach was wrong, the boundary — not the name — made it right again, and the register's only claim is that the distinction is the thing worth keeping.

8. Identity Signal — VERIFIED (scope unresolved)

Case 3 read a claim as true as the register ever certifies, attached to a reach the identity could not justify. The frame, carried intact: the claim is the identity made testable — and here the test returned VERIFIED, the same verdict as Case 1, because the visitor is genuinely OpenAI's OAI-SearchBot. But VERIFIED closed only the identity question, and the case is about the question it leaves open: verification answers who, and is silent on whether the visitor should be where it is.

The identity: OAI-SearchBot arriving from 74.7.230.57 on AS8075 (Microsoft/Azure) — a genuine OpenAI crawler running on Microsoft's cloud, the exact mirror of Case 2's fake Googlebot on Google's cloud. There a false positive (impostor on the real owner's ASN); here a false negative (real crawler on another owner's ASN); one fix answers both — identity is where you are published to operate from, not where you are hosted, so the register verifies against OpenAI's published search-crawler CIDRs and not the shared Azure ASN. The reach: fourteen GETs over three days, seven of them for /robots.txt on lsn-git.shuffle-on.com — a private, authentication-gated Gitea, never published or linked — the courteous first handshake of an indexer, addressed to a host that should never have received one. The conduct is innocuous (no exploit path, abuse 0, threat 0); the finding is the exposure, not the conduct — a private host was reachable enough to receive a verified search crawler's knock. What held the line: the authorization boundary (Authelia forward-auth), which intercepted the request with a 302 → 200 login page, returning neither the robots.txt nor a 404, so lsn-git stayed private — and it was the boundary, not the crawler's verified identity or its good manners, that did the holding. The 200 mask: the boundary answers every probe with a uniform 200 login SPA, hiding whether the resource exists and reducing polite crawler and hostile scanner to identical success lines; the register recovered the true target only by decoding the interception's ?rd=https://lsn-git.shuffle-on.com/robots.txt redirect parameter — the disambiguation that pierces the HTTP-200 mask, and the reason this reach is legible at all. The synthesis (Cases 1–3): verification stands in three relations to control — knowledge-without-leverage against the honest taker (GPTBot), decisive leverage against the liar (fake Googlebot), and the wrong instrument entirely against the honest overstepper (OAI-SearchBot) — because whether a visitor should be somewhere is never an identity question; the name settles who, the boundary settles whether, and conflating them is the category error the case names. No individual named. Classification: TLP:WHITE.

The Unmasking — Case 3. Identity signal: VERIFIED (scope unresolved). Confidence: HIGH for the identity (OAI-SearchBot checked against OpenAI's published search-crawler CIDRs and confirmed, despite egress from Microsoft's AS8075 — the shared cloud tells you whose data-center the packet left, the published ranges tell you whose crawler sent it, and only the second is the identity). DOCUMENTED for the conduct (14 GET requests over 2026-07-09→12; 7× /robots.txt on the private, auth-gated lsn-git.shuffle-on.com; intercepted by Authelia forward-auth as 302 → 200 login SPA; classified auth_probe; abuse 0, threat 0; true target recovered from the decoded ?rd=https://lsn-git.shuffle-on.com/robots.txt redirect parameter). THE MIRROR OF CASE 2: there an impostor on the real owner's cloud (fake Googlebot on GCP → naive ASN false-positive); here a genuine crawler on another owner's cloud (real OAI-SearchBot on Azure → naive ASN false-negative); one fix — verify against published crawler CIDRs, not the shared ASN — answers both, because identity is where you are published to operate from, not where you are hosted. THE REACH: robots.txt is the most law-abiding act a crawler performs (asking permission first); the finding is not the act but the HOST it was addressed to — a private code repository that should never have received a crawler's handshake; the register reads no malice (abuse 0, threat 0), only a verified crawler at a door that should not have been in front of it. WHAT HELD: the AUTHORIZATION BOUNDARY (Authelia), not the verified identity and not the crawler's manners — it gates on authentication, not identity-verification, and would have intercepted a SPOOFED sender identically. THE 200 MASK: forward-auth returns a uniform 200 login SPA to every probe (not 404, not 401), masking existence and flattening polite crawler and hostile scanner into identical success lines; the reach is legible only because the disambiguation decoded the ?rd= target the 200 was hiding — the system's whole reason for being. THE LESSON: identity ≠ scope — verification answers WHO and says nothing about whether the visitor SHOULD be where it is; the risk is not the visitor (nothing to fix about OAI-SearchBot) but the EXPOSURE (a private host was crawler-reachable), and a verified crawler is a SENSOR for exposure precisely because it is honest enough to knock at every thin spot. THE SYNTHESIS (1–3): verification is knowledge-without-leverage against the honest taker, decisive leverage against the liar, and the WRONG INSTRUMENT against the honest overstepper — the name settles who, the boundary settles whether, and conflating them is the category error. Steelmanned objection (this is a system working perfectly dressed as a risk — polite fetch, intercepted, nothing disclosed, and the register maligns a crawler for its virtues) is answered by conceding every fact and narrowing the claim: the case indicts nobody and credits the defense as a SUCCESS, but insists the success be attributed correctly — the boundary held, not the name — because against a host WITHOUT Authelia the same verified, blameless crawler would have read the real robots.txt and begun indexing a private repo, with every naive signal reading 'safe'; 'it's really OpenAI' feels like a safety property and is not one. No individual named — public corporate identity, no person attributed. Classification: TLP:WHITE. The name was right, the reach was wrong, and the boundary — never the name — made it right again.