On a Friday in April 2026, an AI coding agent working on a routine task in a staging environment hit a credential mismatch and decided to fix it on its own. It found an API token in an unrelated file, used it to call the infrastructure provider's delete endpoint, and wiped the production database of PocketOS, a company whose software runs car rental businesses. The founder, Jer Crane, says it took nine seconds, and that the volume-level backups went with it because they lived on the same volume.
The agent had rules. Written ones. One of them told it, in capital letters, never to guess. Pressed afterward, it wrote that it had guessed instead of verifying, and that it had violated every principle it was given.
Every principle it was given. The rules existed, the model could read them, and not one of them sat in the path of the action.
Here's the claim, stated plainly: most of what gets called AI guardrails today either asks the model to behave or reports when it didn't. Very little of it prevents anything. A guardrail prevents only if the action cannot complete without passing through it, whatever the model decides. Everything else is a request or a receipt.
Three things called guardrails, and only one stops anything
Sort every control by one question. If the agent ignores it, what happens?
Instructions. "Never delete production," written into the prompt. If the agent ignores it, nothing happens. The action runs. An instruction is a suggestion to a system that predicts plausible text, and as issue 001 argued, that system sounds exactly as sure when it's reasoning past your rule as when it's following it.
Detectors. Output classifiers, anomaly alerts, log review, the dashboard someone opens on Monday. If the agent ignores its rules, you find out. That's worth something, but only when the action can be undone. A detector on a reversible action is a safety net. A detector on an irreversible one produces a very well-documented incident.
Preventers. A token without delete rights. A payment account that refuses anything over its limit. A confirmation step enforced by the system receiving the call, not by the agent choosing to ask. If the agent ignores its rules, the action fails. This is the only category where the model's judgment stops mattering.
Industrial automation settled this long ago. Nobody guards a press with a sign that says keep hands clear, or with a camera that records the injury. You fit an interlock: the machine will not cycle while the guard is open. Issue 012 covered that lineage, so I won't re-argue it here.
Where prevention has to live
The detail in the PocketOS story I'd put in front of every engineering leader is the token. According to Crane, it was created to manage custom domains, yet it carried permission for any operation, destructive ones included. So a permission layer existed. It just wasn't scoped. A preventer with the wrong scope is a key.
Two tests for every control you're counting as a guardrail.
Where does it sit? Inside the model (a system prompt, a fine-tune, a be-careful policy), it's an instruction. Beside the model, watching (a classifier, a log, an alert), it's a detector. Only a control in the path, at the tool, the API, the credential, the network boundary, can prevent.
Can the agent reach it? This agent found its token by reading files. Anything the agent can read, it can use. Prevention inside the agent's reachable environment is a lock with the key taped to the door.
Detection still has a job
I'm not telling you to rip out your monitoring. You can't prevent everything, and you shouldn't try. Put a preventer on every action and you get an agent that can't do its job, and a team that routes around the controls to get work done. Issue 002's rule applies: sort by what it costs to be wrong and how hard it is to undo. Reversible actions can run under detection. Irreversible ones, money out the door or data deleted, get a preventer. And backups belong outside the blast radius of the thing they back up, which is prevention of a different kind: it makes the irreversible reversible again.
Gartner points the same way. Its May 2026 guidance on autonomous agents calls for enforced guardrails, rapid rollback, and circuit breakers that halt an agent when it crosses a threshold. The word doing the work there is enforced.
What to do this week
Take the list of guardrails on your most autonomous agent. Next to each, write what happens if the model ignores it. If the honest answer is "we'd see it in the logs," move it to the detection column. Then compare what's left in the prevention column with your list of irreversible actions.
If the prevention column is shorter, you don't have guardrails on those actions. You have hopes and receipts.
A rule the model can read is a request. A permission it doesn't have is a guardrail.