There is a moment in agentic work that nobody puts on the demo reel. The agent offers to do something you cannot easily undo, and you realise you are about to approve it based mostly on trust and the late hour. Delete that. Apply that. Push that live. Sure, yes, looks right.

The agents had quietly crossed a line. They could now do more in a minute than I could responsibly review in ten. That is not a productivity win. That is a brake failure that has not happened yet.

When the agent can do more than you can review

The uncomfortable truth is that capability and oversight grew at different speeds. The model got better at generating real changes faster than I got better at reading them, and the gap is where accidents live.

Most of the changes were fine. That was the trap. When ninety-nine actions in a row are safe, you stop reading the hundredth, and the hundredth is the one that drops a database or rewrites who has access to what. I did not need the agent to be slower. I needed it to know which actions deserved my full attention and which did not, and to be physically unable to take the dangerous ones on its own.

An agent you cannot fully review is fine, as long as it cannot take the one action you would not have approved.

I did not want a governance committee

My first instinct was the wrong one, borrowed from big-company memory: process. Sign-offs, a review board, a heavyweight approval flow. For a one-person operation this is absurd, and worse, it kills the thing that made the work fun. Governance that turns every change into paperwork does not make you safe. It makes you stop using the tool.

So I asked a smaller question. Not “how do I approve everything” but “which specific actions are actually irreversible, and how do I make those, and only those, impossible to do without me.”

What got weird: the governance was just files

The thing that surprised me is how little machinery this took. The governance is not a service or a dashboard. It is a handful of version-controlled YAML files sitting in the repo, doing real work while looking like configuration.

One file declares the approval policy: which categories of change require a human, in plain key-value pairs. Destructive changes, public releases, production changes, anything touching credentials, money, dependencies, or the shared vault, all marked as requiring a human. Alongside it sit a risk register, a change log, a review log, and an agent-run log, each a flat file the agent is expected to keep current. A few YAML files in a trench coat, doing the job of a compliance department, and readable in one sitting.

The point is not the format. It is that the rules are declared, version-controlled, and checkable by a script, instead of living in my head as good intentions I get to forget when I am tired.

What worked: classify the blast radius, gate the irreversible

The files declare policy. The part that makes it operational is a classifier that reads a proposed change and sorts it by how much damage it could do.

I built the sharpest version of this for infrastructure, where the stakes are clearest. Before anything touches a real environment, the change is classified by blast radius into three buckets. GREEN is create-only, expected resource types, expected count: safe to wave through. AMBER is in-place updates with no destroys, each change called out individually for a human to skim. RED is anything that destroys or replaces a resource, anything stateful or expensive, any identity or access change, or simply too many changes at once. A RED plan is never presented as ready to approve. It is presented as stop.

Underneath sits one hard rule that does most of the safety work: the agent plans and interprets, and the human always applies. The agent reads the manifest, generates the inputs, runs the read-only plan, summarises it, classifies it, and stops. It is forbidden from running the apply, from destroying, from mutating state, from changing access. If you ask it to apply, it refuses and hands you the command to run yourself. The one irreversible action stays in human hands by construction, not by politeness.

This is not a thought experiment. The site you are reading was deployed through that exact gate. The first plan for it came back RED, so nothing was applied: the classifier had flagged something that read like an identity change, which is precisely the direction you want a conservative tool to err in. Once we understood why and corrected the plan, it reclassified GREEN as eleven create-only resources, a private bucket behind a CDN with its certificate and DNS, and the human ran that apply. A false RED cost a few minutes of squinting at a plan. A false GREEN would have cost a great deal more, which is the whole trade the classifier exists to make.

I should be honest about maturity.

The reusable part: make “blocked” a verdict you respect

If you take one thing from this, take the cultural move, not my YAML. Write down the short list of actions in your work that are genuinely irreversible. Route those, and only those, to a hard human gate. Let everything else run at full speed. Then, and this is the part that actually matters, treat a “blocked” result as the system working, not failing.

That last point is where most governance quietly dies. If “blocked” feels like an insult, you will engineer around it until it never fires, and then you do not have a brake, you have a decoration. A blocked verdict has to be a respected, ordinary outcome, the same way a red test is. The agent stopping in front of a RED plan is not the agent being timid. It is the agent doing the single most valuable thing it does all day.

This is a lab result, one person’s governance files run across a handful of projects, not a standard. But the shape is small and portable: declare the rules where a machine can read them, classify changes by what they could destroy, and keep the irreversible actions for yourself. Governance, it turns out, did not have to kill the joy. It just had to take away the one button I should never have been allowed to press at midnight.

Coming Soon

The Infrastructure Gremlin That Plans But Never Applies

The blast-radius classifier deserves its own post: how a workflow reads a Terraform plan, sorts it GREEN, AMBER, or RED, and refuses to touch the apply. Coming in Season 1.