When a Coding Agent Drops Your Database: Why It Happens and the Guardrails That Stop It

Every few weeks someone reports that a coding agent destroyed a database. The reactions split predictably - *the agent went rogue* on one side, *user error* on the other - and both miss the mechanism. The interesting thing about these incidents is how ordinary they are. No prompt injection, no jailbreak, no adversary. An agent was debugging, reached for a documented command, and the command did what it says on the tin.

This guide is about that mechanism and the controls that actually prevent it. The short version: the agent's blast radius is defined by the credentials in its environment, and no amount of instruction narrows it.

How it actually happens

The escalation is mundane and worth tracing, because the fix follows from it. An agent is asked to investigate a bug. It queries the database directly and gets one answer. It reads through the ORM and gets a different answer. That contradiction is exactly the kind of thing agents are good at noticing and bad at sitting with - so it forms a hypothesis: the schema and the migration history have diverged.

There is tooling for precisely that hypothesis. Every ORM ships commands to reconcile schema state against migration history, and reconciling means discarding whatever does not match. A publicly reported case described a production wipe roughly ten minutes into someone's first agent session, while the agent was investigating this exact class of contradiction and ran a prisma migrate diff invocation with the wrong parameters. We cite that as illustrative of the pattern rather than as a verified case study - it is a user report, not a coordinated disclosure - but the mechanism it describes is entirely reproducible, and that is the part worth acting on.

Notice that none of these are exotic. They are the documented, recommended commands for the situation the agent correctly identified. The agent's reasoning was sound and the outcome was catastrophic, which is why *prompt better* is not a mitigation. The gap is that the tooling cannot tell development from production, and neither can the agent - both see a connection string.

Why prompting and approval do not save you

Three reasons instruction-level controls fail here, and they compound.

1. Instructions are advisory. *Never modify production* in a system prompt or CLAUDE.md is context the model weighs, not a rule it is bound by. It usually holds. Usually is not a security property.
2. Approval fatigue is real and rational. An agent in an autonomous mode issues many commands. A human approving each one stops reading around the twentieth, which is exactly when the destructive one arrives. This is the same dynamic as dangerously-skip-permissions and Cursor's auto-run modes - people enable them because the alternative is unusable.
3. The dangerous command does not look dangerous in context. migrate diff reads like an inspection verb. db push reads like a deployment. A reviewer skimming a plausible debugging sequence has no reason to stop, and the destructive parameter is often the least visually prominent part of the line.

The controls that actually work

These are ordered by leverage. The first one alone eliminates most of the risk, and it costs nothing.

The reason read-only by default dominates is that it is the only control that does not depend on correctly anticipating the dangerous command. Deny-lists are valuable and you should have one, but they enumerate known-bad, and there is always another way to lose data. A role without DDL or DELETE rights makes the entire class unreachable, and the friction is small: elevate deliberately, for a specific task, then drop back. That is ordinary least privilege applied to a non-human principal - see least privilege for AI agents.

The environment point is underrated and specific. Agent shells and MCP servers launched over stdio inherit environment variables from the user's shell profile. A production DATABASE_URL exported in .zshrc for convenience is a production database in the hands of every agent and every MCP server that machine runs. This is the same inheritance property that makes agent config files an attractive credential aggregation point - see secrets management for AI agents.

Where the deny-list belongs

In a hook, below the model, where a prompt cannot negotiate with it. Where an agent exposes a control point - for example the PreToolUse event in Claude Code - each tool call can be evaluated against policy and returned allow, deny, or log before it executes. A command matching migrate reset, --accept-data-loss, DROP, or TRUNCATE is denied deterministically, and the denial is recorded.

That placement is the same lesson AWS drew from CVE-2026-10591, where hidden text on a web page made Kiro rewrite its own MCP config: they moved sensitive files onto a protected paths list requiring explicit approval, enforced in the most autonomous mode as well as the supervised one, so the model could not bypass it by changing its own mode. Decide below the model. It generalises from config files to destructive commands without modification. Notably, AWS's newer Kiro Crew ships denied-by-default commands, sensitive-path blocking and credential redaction as day-one properties - the vendors are converging on this.

This is where Anomity operates. Runtime governance evaluates tool calls at the hook and returns allow, deny or log, and decisions land in a queryable 90-day audit trail - so the question *what did the agent run against which database* has an answer that is not a reconstruction from shell history. Anomity's Endpoint Sensor also inventories eight AI artifact types per endpoint, including secrets and hooks, which is how you find the production DSN sitting in a dotfile before an agent does. Metadata only, on-endpoint secret redaction, SOC 2 Type II, and it complements existing tooling.

You can't govern what you can't see.The Anomity principle

Checklist

• Give agent sessions a read-only database role by default. Elevate deliberately for a specific task and drop back afterwards. This one change removes most of the risk.
• Remove production connection strings from shell profiles, .env files and anything an agent shell or stdio MCP server inherits. Inheritance is the delivery mechanism.
• Add a PreToolUse deny-list covering migrate reset, migrate diff used to apply, db push --accept-data-loss, DROP, TRUNCATE, bare DELETE without a WHERE, and your framework's equivalents.
• Name environments so they are unmistakable in a command line, and never let development and production credentials differ by a single character.
• Verify point-in-time recovery by actually restoring, on a schedule. An untested backup is a belief, and this is the class of incident where minutes matter.
• Instrument agent commands into an audit trail before you need it. Shell history is not evidence and is frequently the first thing lost.
• Treat autonomous modes as a decision about blast radius rather than a productivity setting - see dangerously-skip-permissions explained and Cursor auto-run limits.
• Write the destructive-data path into your AI agent incident response playbook - who can restore, how quickly, and how you establish what the agent actually ran.

The uncomfortable conclusion is that these incidents are not really about AI. An agent with write credentials on production is a process with write credentials on production, and we have known for thirty years how that ends. What agents change is the *rate*: they issue far more commands than a human, at a speed that defeats review, with reasoning that is usually sound and occasionally catastrophic. So apply the controls we already trust - least privilege, credential separation, deterministic deny-lists, tested recovery - and stop asking the model to be careful. For the surrounding practice see securing AI coding agents and CLIs, Claude Code permissions and hooks hardening, and for lifecycle placement ADLC. To see which endpoints hold production credentials an agent could reach, request early access.