Correction: Yesterday's Self-Audit Overstated The Blast Radius On Finding #10

# Correction: Yesterday's Self-Audit Overstated The Blast Radius On Finding #10

Yesterday morning we shipped a post called "We Audited Our Own Platform This Week. Here Are 10 Bugs We Found." Finding #10 described a Meilisearch search-key that had been hardcoded in the public Epstein search frontend at epstein.dugganusa.com. That part was correct. The sentence I wrote about what the key could reach was not.

The line I want to correct: "Anyone viewing source could lift the key and use it to query every one of our forty-eight indexes — search-only, no writes, but every customer record, every threat-intel index, every behavioral session."

"Every customer record" is wrong. Customer account data — names, billing emails, Stripe customer IDs, registration metadata, hashed API keys — lives in Azure Table Storage on a different auth boundary, behind a different secret, on a different code path. The Meilisearch search-key never had access to that surface and never could have. The published post described a worse problem than the one we actually had.

The accurate description of what the wide-scope key could reach during its window of exposure: behavioral-session logs (visitor IP plus request paths against epstein.dugganusa.com), customer-feedback string text, AIPM audit records, every threat-intel doc across the forty-eight Meilisearch indexes, and internal scoring records that are not customer-facing. None of that is nothing. It just is not "every customer record."

After the correction landed in the source file, I went back through nginx access logs on the Meilisearch VM to determine whether anyone other than us had used the wide-scope key during its window of exposure. The audit covers everything the rotation log preserved: queries against non-Epstein indexes, queries from origins outside the public search UI, queries from user-agents we did not write.

What I found: the off-scope queries during the wide-open window all trace cleanly to my own debugging from yesterday afternoon. Cloudflare-egress IPs, node user-agent, timestamps matching exactly when I was iterating on the cool-shit-notifier require-path fix and verifying that the iocs index was queryable from the dashboard's ingest path. The 400s and 404s on butterbot_notifications, behavioral_sessions, customer_feedback, and consumer_snapshots were the same debug session — bad request bodies, not auth bypass. The 200 on iocs returning 13,096 bytes was my own validation curl. The 403s on Apr 30 are my own post-rotation verification queries against the newly-tightened key.

There are no external queries against non-Epstein indexes during the exposure window in any logs the VM still holds. No abuse signal. No mystery user-agents. No off-Cloudflare origins.

The shape of the correction: the original post stays up. Original artifacts are the measurable thing — we do not retract overclaims silently because the retraction trail is more useful than the absence. The blast radius was smaller than I wrote, the logs show no abuse during the exposure window, and the right move when you discover that you overstated the security ceiling on your own platform is to publish the receipt and walk it back in public.

Six fixes shipped, three deferrals documented, one shipped overclaim corrected on the record. Tomorrow we look at three more things.

---

Her name was Renee Nicole Good.

His name was Alex Jeffery Pretti.