A senior engineer approved a pull request that shipped 9 routes with no authentication.

What happened

A pull request added a set of new portal pages — admin-facing views that rendered client engagement and billing data. The PR was substantial. It touched multiple files and added routing for nine new pages. It went through ordinary human code review.

The reviewer approved it. The approval was reasonable under the circumstances most senior engineers actually operate in: they checked the routes they considered "important" and default-passed the rest. This is not negligence. This is the completely normal human shortcut that happens in every engineering organization in the world, every week, under the cognitive load of reviewing a substantial PR.

The PR merged. The pages shipped to production.

None of the nine new routes had authentication middleware.

Every route was a bare handler with no authentication layer and no project-scope guard. Any URL someone could guess or enumerate returned a full render of sensitive engagement data — contractor rate information, billing totals, financial internals for every project in the system.

What caught it

Not the first human reviewer. Not a second human reviewer. An audit pass that grepped for unguarded route handlers in the changed files.

The technique itself is not novel. The novel part is that the lesson from catching this one bug became a structural rule — one that runs on every future pull request, automatically, as part of the platform's review pipeline. No human has to remember to run the check. No senior engineer has to be alert on a busy Friday. The check happens because the platform runs it.

Rule: Every new route handler added in a PR must be
       verified for an authentication middleware guard.

How: A grep pass over the changed files extracts
      every new route handler declaration, then filters
      out the ones that are wrapped in a known auth guard.

What happens if any are unguarded:
  The PR is flagged for justification.
  Either the handler gets an auth guard,
  or the unguarded case is documented and defended.

No exceptions for stubs.
No exceptions for "HTML-only" pages.
If it queries the database, it needs authentication.

The rule now lives in the platform's persistent insight system. Every Claude Code session started on this codebase loads it as part of the project context. Every PR review agent runs the grep. It cannot be forgotten. It cannot be skipped because the reviewer had a busy day. It happens because the platform structurally requires it to happen.

The fix shipped as a versioned release

The fix commit is in the platform's public git history as part of a regular versioned release. The commit message is explicit: it was a security fix on nine unprotected portal routes, shipped alongside the feature work it belonged to. Nothing was hidden. The commit, the version, the release notes, and the insight that followed are all inspectable.

The naysayer's move

The standard rebuttal to a story like this is: "See? Human review caught it."

Look at the sequence carefully. Human review approved the PR. A different audit pass — not a human doing normal code review, a structural grep — caught it. The distinction matters because the rebuttal wants to credit the human layer for a catch the human layer did not make.

The second rebuttal is usually: "You still need humans to write the grep pattern in the first place." Correct. You also need humans to write the code the grep runs against. The question is not whether humans are involved — of course they are. The question is whether the grep pattern runs automatically on every PR forever after a human writes it once, or whether it runs only when a specific human happens to remember it on a specific PR. The first is structural. The second is luck.