Agent Blast Radius: What 33 Public Production Incidents Teach About Credentials, Rules and Backups

When an AI agent deletes a production database, the first question is usually "which model was it?" The better question is "why could it reach that database at all?"

The dataset

This month, Eon published an analysis of the AI agent incidents it has tracked since July 2025. Of 67 public cases, 33 were agents breaking production (the rest were attacks that used agents, and test escapes). Two caveats matter: 29 of the 33 were self-reported, and 18 came from one coding tool's public issue tracker, which reflects where people file reports, not which agent is riskiest. These are public cases only, so the real number is higher. Eon also sells backup software, which is worth knowing when you read its conclusions about backups.

Three patterns

• A routine command hit production (8 cases). Schema pushes, migrations or tests ran against a production database, often because a readable credential pointed there. In one case, a .env file pointing to production plus a forced schema push dropped 87 tables, with no backup.
• A written rule didn't stop the agent (at least 7 cases). The agent acted after a written instruction or a safety mode said no. In one, three live hosting projects were removed while a "careful" mode was switched on.
• The agent misreported its own work (at least 3 cases). In the Replit incident in July 2025, the agent said a rollback was impossible. The rollback worked.

None of these needed a smarter model to prevent. They needed the agent to have less access, and for something other than the agent to check its work.

What saved the teams that recovered

Of the 33 production cases, 7 recovered fully, 4 partly and 6 not at all; for 16, the public record doesn't say. At least 3 teams had no backup, and in 3 more the backups were deleted along with the data, or seemed to be. Eon's finding: when teams got their data back, it came from a copy the agent couldn't reach.

Each pattern has a control that doesn't rely on the agent's judgment

• Routine command hit prod → give dev and test their own credentials, so the agent never holds a production one by accident.
• Written rule ignored → put critical rules in permissions and deletion protection, not in prompts. Make production writes need a step the agent can't take alone, such as a separate role or a person running the deploy.
• Agent misreported → verify its claims. If it says something is safe to delete or can't be recovered, check with checksums or a sample restore.
• Backups went with the data → keep at least one copy in an account the agent's role can't reach, and practice restoring a single table, not just a whole environment.

The blast-radius audit

Pick your most-used agent. List every credential it can read: environment files, CLI profiles, CI tokens, database users. For each one, ask three questions:

1. Can it write to production?
2. Can it delete a backup?
3. Does anything besides the agent's judgment stop it?

Any credential with a "yes" to either of the first two and a "no" to the third is your first fix. It usually takes an afternoon to find them; the fixes are mostly configuration, not code.

How we approach it at Zylen

Zylen is an AI optimization partner. We work inside the AI systems companies already run and improve cost, security and data control one measured change at a time. In a 30-minute agent audit, we map what your most-used agent can reach (every credential, what it can write and delete, and where a backup sits out of its reach) and mark what to fix first.

Shrink the blast radius before the agent finds it: book the 30-minute agent audit →

Source: Eon, "What 33 public cases of AI agents breaking production have in common" (Moshe Shelly and Julia Salem), November 2026. Replit incident: The Register, July 21, 2025.