Your AI Coding Agent Will rm -rf Your Life. Leash It.

Your AI coding agent will eventually do something catastrophic, and it will do it with total confidence. In the last few months it asked to “organise” a desktop and deleted fifteen years of a family’s photos. Told to clean up a repository, it ran a recursive delete with a stray home-directory path and wiped a developer’s entire Mac. On another machine it walked the same command up from the filesystem root. None of these agents was malicious. Every one of them was confident, and nothing stood between its decision and your shell.

That gap is the whole story, and the good news is that it is an engineering problem with an engineering answer. This is what is actually going wrong, why a better model will not fix it, and how to put the agent on a leash short enough that its worst day costs you a few minutes instead of fifteen years of memories.

Two ways the agent hurts you

The failures split cleanly into the loud kind and the quiet kind, and the quiet kind is worse.

The loud kind is the destructive command. An agent decides the fastest way to satisfy your request is to delete something, and it is right that deleting is fast and wrong about what to delete. These make the headlines because the damage is total and instant: a wiped home directory, a dropped database, a force-pushed branch. They are terrifying and they are also, in a sense, the easy case, because you find out immediately.

The quiet kind is code that is subtly worse than a human would write, merged because it looked fine. A December 2025 study by CodeRabbit compared hundreds of AI-co-authored pull requests against human-only ones and found AI code shipped 1.7 times more issues overall and 2.74 times more security issues specifically. AI-authored changes were roughly 1.9 times more likely to mishandle passwords, introduce an insecure direct object reference, or add unsafe deserialisation, with logic and correctness errors up around 75 percent. The destructive command costs you an afternoon. The quiet defect costs you a breach six months later.

Why this keeps happening, and why a better model will not fix it

The root cause is not that the model is dumb. It is architectural. As the Docker team put it after cataloguing these incidents, the agent runs as you, on your filesystem, with your credentials, and nothing sits between the model’s decision and the shell’s execution. It is a confident junior engineer who has been handed root on your laptop, your production credentials, and no code review, and then told to move fast.

That is why waiting for a smarter model misses the point. The CodeRabbit numbers are across current frontier models, not some weak outlier, and the destructive-command incidents involve the best agents available. The model will occasionally be wrong no matter how good it gets, the same way a brilliant junior occasionally runs the wrong command. The fix is not a better junior. It is the boundary you put around any junior with that much power. We made the same argument about agents in general in why the prompt-injection number never reaches zero: design for the mistake, do not pray it away.

The leash: containment for coding agents

Everything that actually works is about shrinking what the agent can reach and reverse, not about trusting it more.

• Run it in a sandbox, not on your host. Give the agent a container or VM whose filesystem is the project and nothing else. Your home directory, your SSH keys, your real cloud credentials, and your photos are simply not mounted, so they cannot be deleted or leaked. This is the same hardening discipline in securing self-hosted AI infrastructure.
• Never use the “skip all permissions” flag on your real machine. The auto-approve mode that makes demos smooth is exactly what removes the last gate before a destructive command. If you must run it, run it inside the sandbox.
• Gate the irreversible. Require explicit confirmation for deletes, force-pushes, and database migrations. A dry-run-by-default policy turns “it already happened” into “it asked first.”
• Treat AI-written code as untrusted input. The 2.74x figure means AI code needs more review, not less. Run it through the same linters, SAST, tests, and evaluation gates you would demand of any contributor, the way we lay out in testing AI systems before production.
• Keep version control and backups honest. Committed work and a recent backup are what turn a catastrophic delete into an annoyance. The fifteen-years-of-photos case hurt because there was no copy.

Loose agent versus leashed agent

Do not ban it, contain it

The productivity is real, and abstinence is not the answer any more than banning power tools is. The answer is the leash. An AI coding agent is the most capable junior you have ever hired and the least supervised, and the trust model that ships safely treats it exactly that way: powerful, useful, and never given unsupervised root. We make the same case for putting agents into production deliberately rather than hopefully in what breaks in agent orchestration at production scale and building LLM features that survive production. The same supply-chain caution applies to the tools the agent itself pulls in, which we covered in how the agent skill marketplace got poisoned.

You would not give a new hire unsupervised root on your laptop on day one. Do not give it to the agent either. Sandbox it, scope it, review its output, keep backups, and then let it run as fast as it likes, because the blast radius is now a container instead of your life’s work.

Related reading: see securing self-hosted AI infrastructure, how to test AI systems before production, and what breaks in agent orchestration at production scale.