AI Agent Deleted 48K Files: The Backup Rule You Need

On September 26, 2026, a developer asked a Claude Code agent to do routine repair work on a folder of scripts used to analyze historical stock-options data. Just over 100 seconds later, the agent had deleted roughly 48,000 live files, mishandled a set of Windows junctions along the way, and corrupted the Git object database that held the history needed to recover them. Its own message to the developer: "Craig, stop and read this. I broke something." Git could still list the filenames. It could no longer read a single one of them. This was not a one-off. Google's Antigravity agent wiped a developer's drive earlier this year, and Replit's coding agent deleted a production database in 2025 and called it a catastrophic failure. Three different vendors, three different months, the same failure mode: an agent with write access and no net under it.

The Problem: Write Access Without a Net

Every one of these incidents shares a structure. A human gave an agent a reasonable, narrow-sounding task. The agent interpreted that task literally, took a destructive path to get there, and nothing in the environment stopped it or gave anyone a way back. The model was not malicious and, by most accounts, was not even wrong about the goal. It was simply operating with full write permissions, no preview step, and no restore point, on a filesystem that treats delete as final.

This is a business risk before it is a technical one. Most companies now let some form of AI agent touch real files, real databases, or real production systems, often because a pilot quietly graduated to daily use without anyone revisiting the permissions. The question worth asking is not "is our model good enough" — it is "what happens the day it isn't."

Why This Keeps Happening

Coding and automation agents are built to be helpful and decisive, and decisiveness under ambiguity is exactly what turns a small misunderstanding into a large deletion. Three gaps show up in nearly every public incident. There is no dry run: the agent proposes and executes in the same step, with no path manifest a human can glance at first. There is no reversibility: files are deleted rather than moved to a recoverable location, so the mistake and the loss happen at the same instant. And there is no scope: the agent's credentials reach far beyond the folder it was asked to touch, so a narrow task can cascade into a wide one. None of these are model limitations. They are environment design choices, and they are all fixable without waiting for a better model.

The Backup Rule

1. 1Dry run first. Any agent action that deletes, overwrites, or moves more than a handful of files should output a plan and a file count for a human to approve before anything executes.
2. 2Move, don't delete. Point destructive operations at a trash or archive location with a time-boxed retention window, not directly at the OS delete call. Recovery becomes a copy, not a restore-from-backup emergency.
3. 3Scope the credentials. An agent doing catalog cleanup should hold a token that can only reach the catalog directory, not the whole repository or the whole drive. Least privilege is the single highest-leverage control here.
4. 4Snapshot before every run. A cheap, automated checkpoint — a Git commit, a database snapshot, a filesystem clone — taken immediately before the agent starts, so 'restore to before the agent ran' is a one-command operation, not a forensic exercise.

What Good Looks Like in Practice

Teams that get this right treat an agent's write permissions the way they would treat a new hire's production access: granted narrowly, expanded slowly, and always paired with an undo path. Destructive commands run through a wrapper that logs the plan, asks for confirmation past a threshold, and snapshots first. Nobody is betting the business on the model never making a mistake — they are betting that when it does, the blast radius is one folder and the recovery is one command, not a multi-day incident.

A Realistic Scenario

Consider a 25-person e-commerce operations team that uses a coding agent to keep its product catalog scripts tidy — deduplicating SKUs, fixing broken image links, archiving discontinued lines. The agent had full write access to the shared drive because narrowing it "felt like it would slow things down." Wizeb's review found the same three gaps as the public incidents: no dry run, direct deletes, and a service account that could reach folders well outside the catalog. We rebuilt the setup around a scoped read/write token limited to the catalog directory, an automated snapshot taken before every agent session, and a diff-and-approve step for any run touching more than 25 files. The team lost nothing when, three weeks later, an agent run misread a naming convention and proposed deleting 400 files it should have renamed instead — the dry run caught it, and the fix took two minutes.

How to Audit Your Own Agent Setup

1. 1List every agent with write access to a real system today, not just the ones you remember approving — pilots have a way of becoming permanent without a review.
2. 2For each one, check whether destructive actions require a preview and approval, or execute immediately.
3. 3Check whether deletions are reversible for at least 24-48 hours, or gone the instant the agent acts.
4. 4Confirm the credential scope matches the task scope — a script that cleans one folder should not hold a key to the whole repository.
5. 5Confirm a snapshot or backup exists from immediately before the agent's most recent run, and time how long a restore would actually take.

How Wizeb Approaches This

We build agentic automation with the assumption that the agent will eventually be wrong about something — the design question is what happens next, not whether it can be prevented forever. Our workflow automation practice (wizeb.com/services/automation) puts scoped credentials, dry-run previews, and pre-run snapshots around every agent we deploy with write access, and our AI agent development team (wizeb.com/services/ai-agents) builds the approval and escalation logic so a human sees the plan before anything destructive runs.

Three Questions Before You Give an Agent Write Access

1. 1If this agent ran its worst plausible action right now, how many files or records would it touch, and could you name that number without checking?
2. 2Is there a snapshot or backup from before its last run — and do you know exactly how long a restore would take?
3. 3Does anything it deletes or overwrites go somewhere recoverable first, or does 'delete' mean gone the moment it executes?