The pull request looked finished. A network feature, a focused diff, a full suite of passing tests — and, because the feature fetched URLs, a security claim in the PR body: requests to internal network targets are refused. Attached was the evidence, a test with exactly the right name: test_internal_targets_refused. Green.
Most review processes end there. A claim, plus a passing test with a matching name, reads as a claim proven. The reviewer skims the diff, sees nothing alarming, approves. Everyone involved behaved reasonably, and the vulnerability ships.
Ours is not allowed to end there. We run every review under a standing rule: a containment claim — “X is refused,” “Y cannot reach Z,” anything asserting that something does not happen — must cite a test that exercises the control through the shipped entry point. Not a test that exists. Not a test with the right name. A test the product’s own code path actually runs through.
So the reviewer — a different agent from the one that wrote the code, with a charter that says rebuild the attack rather than read the diff — traced the claim from the outside in. Start at the shipped entry point, follow the request, find where the guard fires.
It never fired.
The test had constructed its own HTTP client, attached the guard to it, pointed it at an internal address, and observed the refusal. Everything the test claimed, it proved — about the client it had built. The shipped code constructed its client somewhere else, without the guard. On the real path, the request had already left the building before the guard ever saw a URL.
The verdict was block, and in our process a block is not an opinion — the merge gate reads verdicts mechanically, and a blocking verdict at the current commit means the merge is refused, no matter how persuasive the PR body is. The fix moved the guard onto the shipped path, the test was rewritten to enter through the product’s own front door, and the re-review happened at the new commit, because a review of an older version of the code counts for nothing.
Why this failure mode is the one that matters
Here is the uncomfortable part: this wasn’t sloppy work. The code was clean, the test was well-written, and the intention was sincere. The evidence was simply attached to the wrong thing — and evidence attached to the wrong thing looks identical to evidence that proves the claim, right up until someone tries to walk the real path.
This matters more, not less, when agents do the building. An agent engineering team produces code and evidence at a volume no human team matches, and the evidence is always well-formed: the test names are right, the assertions are plausible, the suite is green. Reviewers catch sloppy code at a glance. What they don’t catch by reading — what nobody catches by reading — is a proof that proves something adjacent to the claim. The only way to catch it is to distrust it: rebuild the attack, enter through the shipped entry point, and watch what actually happens.
That is what our review process is built to do, structurally rather than heroically. The reviewer is never the author. On security-relevant paths, the review is adversarial by charter — it starts from the assumption that the evidence is wrong. And containment claims are a named checklist item: every “X cannot happen” in a PR body gets traced from the shipped entry point before the review can conclude.
What we took from it
Three rules, all of which we now run on every engagement:
Tests verify the code they call, not the claim you staple to them. A test’s name is documentation; its call path is the truth. When a test is offered as proof of a security property, the first question is not “does it pass?” but “does the product route through what it tested?”
“Looks proven” and “is proven” diverge quietly. Nothing about the original PR would have flagged it for extra scrutiny. The discipline has to be unconditional — applied to every containment claim, not just the ones that smell wrong — because the ones that smell fine are the ones that ship.
Someone’s job must be to distrust the evidence. Not to spot-check it, not to sample it — to rebuild it. That role can’t be the author, and it can’t be optional. In our process it is a separate reviewer with a blocking verdict the merge gate enforces mechanically, and a person accountable at the end of the line.
The system shipped with the guard on the real path, and the rule that caught it now has a name in our review checklist. That’s the pattern behind most of what we write here: the lesson is rarely the bug. The lesson is the process change that makes the bug’s whole class unshippable.