Can an AI Agent Delete Your Files? Make Every Mistake Reversible

Continue Press · July 2026 · Pillar: safety and guardrails · how we publish · Topic hub: AI agent safety

Yes, an AI agent can delete your files, and the viral horror stories are real. The reliable protection is not blocking dangerous commands but making every change reversible: keep the agent's work under git, commit before any bulk operation, and push a backup hourly. We once had a script corrupt 14 files in a single run and restored every one of them from the commit made just before it.

The stories you have seen are not urban legends. Agents have run commands that wiped directories, overwrote working files, and mangled data at scale, and being honest about that is the starting point. An agent acts on a real machine with real permissions, so a wrong instruction produces real damage. Pretending otherwise is how people get hurt. The useful question is not whether it can happen but what makes the damage permanent, because that is the part you actually control.

Most advice reaches for a blacklist first: block rm -rf, forbid a list of scary commands, and feel safe. This fails on contact. A determined mistake can delete files a hundred other ways - a move to nowhere, a truncating redirect, a bad script, a wrong glob - and no blacklist enumerates them all. Blocking specific commands narrows one path while leaving the field wide open, which is why reversibility beats blacklists and why whether an AI agent is safe to run comes down to recovery, not restriction.

What makes a deletion unrecoverable?

A deletion is only permanent when there was no committed copy to restore. Files are not truly gone because an agent removed them; they are gone because nothing else was holding a copy at the moment they were removed. If the folder is under version control and you committed recently, a deletion is a nuisance you undo in seconds. If it is not, the same deletion is final.

So the thing that decides your outcome is not how the files disappeared but whether a saved version existed beforehand. Two identical mistakes, one inside a git repository with a fresh commit and one in a plain folder with no history, end completely differently: the first is a one-line revert, the second is a data-loss incident. The agent behaved the same way in both. The only variable was whether a copy was waiting.

This reframes the whole problem. Instead of trying to predict and forbid every dangerous action - an infinite list you will never finish - you make the recovery copy the constant. Version control turns deletion from an ending into an edit you can walk back. Once a committed copy always exists, no single command the agent runs can take anything from you for good, and the exact form of the mistake stops mattering.

It also changes how you feel while the agent runs. When recovery is guaranteed, you do not have to review every command in dread or second-guess whether a script is safe, because the cost of being wrong has already been capped. That confidence is not recklessness; it is the direct result of having a copy waiting. The agents that are genuinely safe to leave running are not the ones with the longest blacklist. They are the ones whose every action is trivial to undo.

What is the 2-rule insurance policy?

The policy is two rules that cost almost nothing and cover almost everything. Rule one: commit before every bulk operation, and verify the content after. Rule two: push a backup roughly every hour. That is the whole thing, and it is what saved our 14 files. Neither rule tries to guess what the agent might do wrong, which is exactly why they hold up where blacklists do not.

Here is exactly how the save happened. An agent ran a bulk-edit script across many files, and a subtle encoding bug corrupted 14 of them at once - the kind of quiet damage you do not notice until it is everywhere. Because a commit had been made immediately before the operation, the fix was to restore the previous version and recover all 14 files at 100 percent. Nothing was lost. The second half of rule one is what caught it: verify the content after, not just that the command exited without an error, because a script can finish cleanly and still have wrecked the text inside every file it touched.

Rule two exists for a different failure. A local commit protects you against edits and deletions, but it lives on the same disk as everything else, so it does nothing if the machine itself dies. Pushing to a remote roughly every hour means the worst case is losing about an hour of work rather than the entire history. The two rules stack: commit-before-and-verify-after makes any single operation reversible, and the hourly push makes the whole project survivable. Together they turn a file disaster into a two-minute revert. For the day-to-day version of this discipline, see the checkpoint habit that keeps an AI agent honest - that article is the routine, this one is the disaster it prevents.

FAQ

Does blocking rm -rf keep me safe?

Not really. Blocking one command narrows a single path, but a determined mistake can delete files another way - a bad move, a truncating redirect, a wrong glob, a broken script. You cannot enumerate every dangerous action in advance. Reversibility protects you far better than a blacklist: with the work under git and a backup pushed regularly, any deletion is something you undo rather than something you mourn.

What about files outside the repository?

Keep the agent's work inside a version-controlled folder, because only tracked files are trivially recoverable. Anything the agent must touch outside that folder should be backed up separately before it does, since a plain directory with no history gives you nothing to restore from. The simplest safe posture is to give the agent a repo to live in and treat everything beyond its walls as needing its own copy first.

Do I need cloud backup too?

Yes, as a second layer. A local commit protects against edits and deletes, but it sits on the same disk as your project, so it cannot help if the whole machine is lost or fails. An hourly push to a remote covers that gap, capping your worst case at about an hour of work. The commit and the push protect against different disasters, and you want both.

Make every mistake a two-minute fix

The free chapter shows the checkpoint-and-backup habit that turns a file disaster into a quick revert, so an AI agent can work on your machine without you holding your breath.