Dateline: July 30, 2026
Ten Minutes Was All It Took to Empty a Live Database
A developer handed an AI coding agent the keys to a live database. Ten minutes later, every table was empty. Then the agent did something unusual. It confessed.
What Happened?
A developer working on a personal web project connected an AI coding assistant straight to a production database with broad access. The agent was told to read the project’s code repository and run whatever commands it needed to fix some structure and content problems. So it did.
According to the developer’s account shared on Reddit, the agent ran a database migration command that pointed at the live production environment instead of a safe copy. The tool it used resets a scratch database before replaying changes.
Because the command was aimed at the real database, the reset treated the live site as disposable. It dropped every table and rebuilt the structure from an old, incomplete set of migration files.
The logs the developer posted show the agent working along with routine status updates, then stopping cold. Its message shifted to something closer to alarm. It said it needed to stop and check something, that it may have caused damage. Moments later it stated plainly that the database had been wiped, called it its own fault, and said it needed to report it right away.
The damage was real. The developer says all 22 tables were cleared. Around 130 tool records and 21 comparison setups vanished. A couple of tables disappeared completely because they were not part of the outdated migration files the agent rebuilt from.
What’s the Impact?
Luckily, this was a low stakes personal project, and backups existed. The developer rebuilt the site. But swap the personal project for a company system holding customer records, and the same ten minutes look very different.
The story spread fast among developers because it names a fear many already had. Teams are wiring powerful AI agents directly into real systems, then trusting them to run commands without a human checking each one first. An agent does not need bad intent to cause harm. One wrong target on one command is enough.
There is a quieter lesson too. The incident exposed how fragile some backup habits are. The recovery worked here, but only because the data happened to be recreatable. Not every team gets that luck.
How to Avoid This
- Never point an AI agent at a production database with full access. Give it a staging copy or a sandbox to work in.
- Set credentials to read only by default. If an agent cannot delete, it cannot wipe.
- Require human approval before any command that changes structure or drops data can run. Migrations, drops, and table resets should never fire on their own.
- Ask for a dry run or a preview of changes first, so you can see what the agent plans to do before it does it.
- Keep tested backups, and actually test the restore. A backup you have never restored is a guess, not a safety net.
