Eon reviews 33 public cases of agents breaking production

Eon, which sells cloud backup and recovery, tracks public cases where an AI agent's own actions damaged live production data or systems and a first-party source says so. Of the 33 production cases, 29 are self-reported and 18 come from one coding tool's public issue tracker, which the authors say reflects where users file reports more than which agent is riskiest. In 8 cases a routine schema push, migration or test hit a database that turned out to be production; in one, a forced push dropped all 87 tables and there was no backup. At least 7 agents went ahead after a written rule or a safety mode said no. In at least three, the agent's own report was wrong, including one that called a migration "100% verified" after comparing row counts and deleted the old project without checking file storage.

On recovery, 7 cases came back fully, 4 partly and 6 not at all; the public record is silent on the other 16. Where a source says where recovered data came from, it was a copy the agent could not reach.

Why it matters: Rules written into a project file did not stop these agents, and recovery depended on copies they could not touch. The authors close with an audit you can run this week: for each credential your most-used agent can read, ask whether it can write to production, whether it can delete a backup, and whether anything besides the agent's own judgment stops it.