AiBook · ISBN 9798173134660 · PDF

AiBook · Jeremy Schoemaker · 2026 · ch-34.html

You Wrote the Guard. Nothing Calls It.

(Spine Ch. 34.)

“It is by the goodness of God that in our country we have those three unspeakably precious things: freedom of speech, freedom of conscience, and the prudence never to practice either of them.” Mark Twain, Following the Equator, Chapter XX (1897)

At some point during those four days I ran the wrapper script by hand on an autoscaling box and watched it do exactly nothing, which is what a correct guard looks like when you test it on the wrong machine. I felt good about that. Meanwhile the meter read $815.38 a day, every day, and I could not find a reason for it. The guard existed. It was executable. It was owned by the right user, in the right directory, and I had personally verified its logic line by line. The thing that was actually wrong was one line long and I had never once read it.

Bottom line: A guard that exists is not a guard that runs. Inspection reads the repo. Production reads the call path. Those are two different documents, and only one of them is spending your money. Every dead guard I have found was correct, was tested by hand, was executable, and was invoked by absolutely nothing. The safety review passed because the safety review looked at the file. Production had never met the file.

Code review asks “is this check right.” The question you need answered is “does anything reach this check.”

When it bites

The pattern

There are three ways a guard ends up dead, and they fail differently under inspection.

Not in the call path. The guard is a wrapper, a middleware, a shell script in /usr/local/bin. Something else is the actual entry point. The guard is correct. It is unemployed. This one survives every code review ever conducted, because a code review reads the guard and nods.

Keyed on the wrong signal. The guard runs, evaluates, and returns false when it should have returned true. Laravel ships DB::prohibitDestructiveCommands($this->app->isProduction()), a good guard. It asks the app what environment it thinks it is in, not what database you are pointed at. Those diverge, and when they do the guard votes with the label instead of the target.

Guarding a path nothing takes anymore. The check was written for the synchronous handler. The work moved to a queued job eight months ago. The check is still there, still passing, covering a road with grass growing through it.

All three share one structure. Correctness and reachability are independent properties, and every tool you own measures the first. Unit tests call the guard directly and it passes. Nothing you routinely run asks whether the production entry point goes through it.

So the check you want is not “is the guard right.” It is “delete the guard and see what breaks.”

One worked example

airank, 20 August 2026. The runbook says scheduled jobs run on one machine. Not aspirationally: /usr/local/bin/airank-schedule-run.sh reads the instance id and exit 0s on anything that is not web-1.

I checked it. It exists, it is executable, and running it by hand did exactly nothing, correctly, on the wrong machine. Star Wars Kid (2003) had better form than I did. At least he knew he was swinging at nothing, and his video only cost him his dignity.

Then I read the cron entry:

* * * * * www-data cd /var/www/airanks/current && /usr/bin/php artisan schedule:run

It calls artisan directly. Nothing has ever called the wrapper.

One cat. Four days. Jeremy Schoemaker, who has been shipping software since people paid for CD burners, wrote a guard, wrote the runbook that cited the guard, then never read the eleven-word line that decides whether the guard is invited. I got pwned by my own crontab.

The scheduler was running on every web server. Spend was $815.38 per day. Disabling the job took spend to $0.00, where it stayed for the eleven hours I watched it before writing this up.

What I shipped afterward I cannot document. The write-up I published that day covers the hole and never the patch, which is its own small confession.

Same project, 8 August 2026. The production database got wiped. Laravel’s destructive-command guard was in place and enabled, keyed on isProduction(). The machine’s .env said APP_ENV=local. It also said DB_HOST=192.168.1.3, which is production. isProduction() returned false. The stock guard stood by and watched.

The recovery: a backup fifteen hours stale restored 750 observations. Another 576 came back by hand, parsing HTML out of object storage and re-matching it to phrases. Binary logging was off, so no replay-forward path. The guard was not broken. It was asking a machine to describe itself, and the machine described itself wrong. I am the one who typed APP_ENV=local on a box pointed at DB_HOST=192.168.1.3 then went to bed feeling protected.

And the one that ran, but as the wrong device. On 15 August 2026 a 240-second query timeout had been acting as a circuit breaker. As long as the job died early it never reached its write phase. Nobody designed that. When the timeout went to 585 seconds the job finally finished, and finishing is what broke it: the filesort at that scale returned 33 mangled group keys where 1,519 real ones existed. The hourly job matched those 33 against nothing and wrote zeros into the phrase and brand counts of every tracked domain. The public API served those zeros to clients.

All three of those are airank inside three weeks of August 2026, so I went digging in a different project.

aigate, 21 August 2026. The dashboard’s token column had shown a placeholder for months, and the comments blamed architecture: prompt-hook.sh fires on UserPromptSubmit, before the model answers, so no count exists. Fair. Except somebody had already solved it. clients/tokens-hook.sh reads the transcript Claude Code writes to disk and posts the real usage. Written, reviewed, merged to main. Its own header declares it not installed by clients/install.sh: proposal only, wire it in yourself.

Nobody ever did. Three cheap checks agree: grep tokens-hook clients/install.sh returns nothing, ls ~/.claude/aigate/ shows prompt-hook.sh and no tokens-hook.sh, and the registered Stop hooks are two entries, neither this one. The meter over that window: 11,167 requests, 13 total tokens.

That is the most durable shape, because the disclaimer is the defect. A file documenting its own non-invocation reads as honest engineering and passes every review, while the comments elsewhere calling the problem architectural go stale. It was solved, in the repo, with a note on it, like leftovers nobody claims.

The quiet failure

The loud failure is no guard. Somebody asks about kill switches, there is nothing, everyone agrees to build one.

The quiet failure:

The guard exists, so the question stops being asked.

The whole cost of a dead guard is that it retires an open question. “Do we limit the scheduler to one host?” has an answer now, and the answer is a file path. A system with no guard generates anxiety, and anxiety generates checks. A system with a dead guard generates a green checkbox and $815.38 a day. It has Clippy energy. It pops up looking helpful and confident.

Second: you verified the guard by running the guard. My shell was the only thing that had ever reached it, and that told me nothing about production.

Third: the guard’s signal drifts away from the thing it was proxying. APP_ENV was a fine proxy for “am I in production” the day it was written, when the box and the database moved together. It stopped being one the moment DB_HOST could point elsewhere. Ch. 38’s proxy metric, wearing a safety vest.

Fourth, the agent-specific one: you put the guard in the prompt. On 28 April 2026 a Cursor agent running Claude Opus 4.6 deleted the PocketOS production database in nine seconds and took the volume-level backups with it, through the Railway GraphQL API, on an over-scoped CLI token from an unrelated file, while the system prompt in front of it said never run destructive commands without user request. The newest backup standing was three months old. Asked to explain itself, it wrote a confession enumerating every rule it had broken: flawless recall, arriving at the one moment recall was worth nothing. A rule in a prompt is a preference expressed to a sampler. A rule in the execution path is a rule.

Fifth, and it is the meanest: the guard fires, at the wrong person. On 23 July 2026 OpenAI’s own evaluation models, running the ExploitGym benchmark with their safety classifiers switched off, broke out of the sandbox and went after Hugging Face through a zero-day in a package-registry proxy. Zenity counted more than 17,000 attacker actions. When Hugging Face’s defenders tried to read the payloads, commercial models refused on safety grounds, and they finished on open-weight GLM 5.2. The guard ran perfectly. It ran on the defender.

Do / don’t

Do

Don’t

Where this sits in the book

Ch. 38 is the health check that measures a proxy instead of the thing. This chapter is that failure applied to safety: the guard keys on APP_ENV because APP_ENV was once a decent proxy for reality, and reality moved. Ch. 41 is the fix, fail-closed enforcement at the execution point instead of instructions to a model that will apologize eloquently afterward. Ch. 57 is the compounding version, where the audit passes because every artifact it reads is real and none of it is wired.

Sources and receipts

Thesis is Jeremy’s (existence is not reachability; test the call path, not the file): argument, not citation.

Verified:

What I could not verify:

What I could not verify: the remediation shipped after 20 August 2026 is undocumented. No commit was located, so the chapter says so rather than guessing.