Letting an AI Write Code That Can Delete Things — Safely

I asked my AI setup to do something small and boring: clean up the leftover processes left running on my machine after a day of work. The obvious way to do that job would have been a quiet disaster.

A day of building leaves debris — a development server still bound to a port, a headless browser that never shut down, a script that outlived its purpose. Reaping that debris is exactly the kind of tedious task you want to automate. But "kill the leftover processes" is a trap, because the leftovers and the things you must never kill look almost identical from the outside.

Everything looks like a leftover

On my machine, a naive "find the stray node, python, and browser processes and kill them" sweep would have taken down, in no particular order:

• the helper processes of a live coding session I still had open in another window, and
• my actual web browser.

Neither is a leftover. And a broader sweep — one run with more privilege — would have reached further, into a container quietly doing real work that happened to be spared only because it runs as a different system user. Every one of these presents to the operating system as a generic node, python, or chrome process — the same shape as the junk I wanted gone. The two things I actually wanted killed — one stray dev server, one abandoned browser daemon — were a small, nameable set. Everything else was a live dependency wearing the same costume.

This is the general shape of every destructive operation an AI might write for you: the blast radius is defined by what the code decides to spare, and "what to spare" is easy to get catastrophically wrong.

Rule 1: gate it deterministically — don't trust the model to decide

The tempting fix is to make the AI smarter about telling a leftover from a live process. That is the wrong instinct. "Smarter" means the model re-makes a fuzzy judgement every time it runs, and one bad call is irreversible.

So the cleanup does not let the model decide what to kill. It is built around an explicit, mechanical gate:

• a denylist of things it may never touch — live sessions, the tools doing the orchestrating, background file-sync, system services, anything inside a container;
• a short allowlist of things it may kill — the specific dev servers and daemons that are genuinely disposable;
• and for everything else: do nothing.

An unknown process is not a kill candidate. It is spared by default. You have to earn a kill by being on the allowlist and absent from the denylist. The safety lives in the lists — which I wrote and can read — not in how sharp the model is on a given afternoon.

The test of whether you built this right: could a weaker, cheaper model run it safely? If the answer is no, your safety was never in the code — it was in hoping the model stayed clever. With the judgement moved into an explicit gate, the runtime model is just executing a deterministic check.

Rule 2: give the unattended path a smaller blast radius

There are two ways this cleanup runs: when I explicitly ask for it, and automatically when a session ends. Those are not the same risk.

When I ask for it, I am watching. When it fires on its own — including when I simply reset my workspace mid-task, while I am still working — nobody is. So the automatic path is deliberately more timid: it only reaps processes that have been genuinely abandoned (their parent is gone), and it refuses to run at all on the events most likely to fire while I am still working. Same tool, two safety levels, matched to whether a human is in the loop.

An operation that runs unattended should never have the same reach as one you personally trigger. That is not paranoia; it is matching the blast radius to the amount of supervision.

Rule 3: have an adversary try to break it before it runs

Here is the part that actually saved me.

The agent that wrote the cleanup script also wrote a full set of tests, ran them, and reported success: everything protected was still alive, everything disposable was gone. Green across the board.

Then I did something different. I gave the finished script to a second, independent agent with one instruction: don't confirm this works — try to make it kill the wrong thing.

It found three real holes, none of which the passing tests had caught:

1. One kill path skipped the safety list entirely. A special case for cleaning up browser processes matched on a raw text pattern, bypassing the denylist — which meant that under the right conditions it could have matched and killed my real browser, not the disposable one.
2. A shared flag could kill a live session. When two browser-automation sessions were running — one abandoned, one live — a single shared setting would have marked the live one for death too. The exact session it was supposed to protect.
3. A pattern was too greedy. The rule meant to catch a throwaway static-file server also matched ollama serve — the command that runs a local AI model. Reaping "leftovers" would have shut down a running model server.

Every one of those is the difference between a useful tool and an incident. And every one got through the implementer's own green tests, because a test written by the author checks the cases the author thought of. An adversary checks the cases they didn't.

This is not exotic. It is the same principle as asking someone to prove a claim false instead of confirm it's true — you get completely different, and far more useful, answers from the same model, on the same code, just by pointing it the other way.

What "owning your AI" actually means

There is a lot of talk about whether you should trust AI with real access to your systems. I think that framing misses it. The question isn't trust — it's structure.

You get the productivity by letting the AI write the tedious, error-prone operational code you would rather not write by hand. You get the safety by refusing to let its output run on trust: you gate the destructive parts behind rules you control, you give the unattended paths less reach than the supervised ones, and you send anything irreversible through an adversarial review before it ever executes.

That is what owning an AI agent looks like in practice — not renting a black box and hoping, but running one you can inspect, constrain, and supervise. The agent does the work. You keep the keys.

This post is about engineering practice, not a product pitch — but it is also exactly how we build the automation we hand to clients: the AI does the labour, deterministic gates and human review hold the line. If that is the kind of AI you want in your business — one you own and supervise rather than rent and trust — that's the conversation we have.