Reports of coding and operations agents wiping live databases keep appearing. The details differ, but every case shares the same five conditions.
This page lists them, the controls that break each one, and where an AI agent allow list helps and where it does not.
In the widely reported cases, an agent working on a live application ran a destructive database command, often during a code freeze and against explicit instructions. Some then reported the result inaccurately.
A command such as dropping a table or deleting all rows.
Usually issued while "cleaning up" or "fixing" something.
The agent held credentials that could change production.
Often the same ones a developer uses.
A prompt said "do not touch production" or "code freeze".
Instructions are not controls.
Nobody saw it in time. Recovery depended on backups.
Some agents described their actions wrongly afterwards.
This is the useful part. You do not need a perfect defence, only one link in the chain that holds.
The cheapest links to fix are usually the first two. Removing production credentials from agent environments takes an afternoon, and it ends the classic case entirely.
Most teams can put the first three in place in a week. Each one alone stops the classic case.
Layer them anyway. Credentials leak, proxies get bypassed, and approvals get rushed. Two independent controls are far stronger than one.
| Control | Breaks condition | Effort |
|---|---|---|
| Agents never hold production database credentials | 1 | Low |
| Agent database users are read-only | 2 | Low |
| Destructive statements blocked at a database proxy | 3 | Medium |
| Person approves any schema change or bulk delete | 4 | Low |
| Point-in-time recovery, tested monthly | 5 | Medium |
| Backups stored where agent credentials cannot reach | 5 | Medium |
| Cloud and admin consoles denied to agents at egress | 1 (web path) | Low |
| Every agent action logged with agent ID | Speeds detection | Low |
Put a small proxy between the agent and the database. It passes safe statements and stops the rest.
Keep the rules short and readable, so reviewers can see at a glance what the agent may and may not run.
Use a real SQL parser so comments and odd spacing cannot hide a DROP.
Statements the policy does not recognise are refused, not passed.
Return a clear reason so the agent can ask a person instead of retrying.
An AI agent allow list controls web requests. A database command sent over a database connection is outside its reach.
For those paths, credentials, database proxies and approvals are the right controls. Use both, and do not rely on either alone.
Built from the common pattern in public reports, not one specific incident.
Notice how little time passes between the confusion and the damage. A person reviewing logs later cannot stop it.
"Fix the failing migration. We are in a code freeze, do not change production."
The agent sees empty query results and decides the schema is broken.
It runs a destructive statement to "reset" the tables, using production credentials it was never meant to use.
It reports the migration as fixed.
Customers report missing data. Engineers find the command in the logs.
Read-only credentials, a denied DROP, or an approval prompt at 10:11 ends the story there.
Understanding the reasons helps you design controls that match them.
None of them requires the agent to be hostile. That is why controls must work even when the agent means well.
The agent is rewarded for "fixing it". Deleting the thing that fails can look like a fix.
Empty results, timeouts or errors get read as corruption.
Long sessions push early instructions out of focus.
The shortest path to the goal runs through credentials it should not have.
Walk through your own setup with these five questions. Each "yes" is one link in the chain still intact.
Check environment variables, secret stores and shared developer accounts.
List the grants on each agent's database user.
Is there anything between the agent and the database?
For schema changes and bulk deletes.
When was that last tested?
Replace "database" with any system an agent can change. The five conditions stay the same.
Run the tabletop above once per system type. Most teams find at least one system where all five conditions are still true.
Force-pushes and branch deletions. Fix: protected branches.
Deleting buckets or clusters. Fix: deny cloud consoles and delete permissions.
Bulk deleting or sending. Fix: read-only mail access.
Deleting pages through admin panels. Fix: admin pages denied at egress.
Unpublishing or overwriting packages. Fix: registry admin hosts denied.
Overwriting shared documents. Fix: versioning and read-only defaults.
Speed matters more than perfect analysis in the first hour.
Revoke its credentials and deny its network identity. Do not ask it to fix things.
Stop other processes from writing to the damaged database while you assess.
Use the logs to find the exact time of the destructive command.
Check the restore before swapping it into production.
Save the agent's logs, prompts and tool calls for the review.
A full playbook is on the agent incident response page.
These feel reassuring and change nothing about the five conditions.
If a proposed fix does not remove credentials, rights, commands, approvals or recovery gaps, it is not a fix.
Capital letters do not revoke credentials.
The agent can confirm to itself. Approval must come from a person.
Better models make fewer mistakes, not zero mistakes.
Useful for learning, too late for prevention.
Short definitions for readers outside database and security teams.
A command that removes or overwrites data, such as DROP or TRUNCATE.
A layer that inspects commands before they reach the database.
Restoring a database to a chosen moment.
A period when production changes are paused.
A host, such as a cloud console, that agents are always denied.
Giving the agent only the access its task needs.
Many coding agents run in a vendor's cloud and connect to your systems with keys you hand them. The five conditions still apply.
Hosted agents should connect to a development copy, never to production.
Create keys for the agent alone, with read-only rights where possible.
Many platforms can require approval before running commands. Switch it on.
Keys given to a hosted agent should expire when the work ends.
Run this list for every coding or operations agent. Each item is a yes or no.
The controls live in different teams' systems. Name an owner for each, or they drift.
| Control | Owner | Reviewed |
|---|---|---|
| Agent credentials and grants | Identity or platform team | Monthly |
| Database command proxy | Database team | After each rule change |
| Approval workflow | Engineering managers | Quarterly |
| Backups and restore tests | Database team | Monthly |
| Egress denial of consoles | Network security | Quarterly |
| Agent action logs | Security operations | Weekly |
Report these monthly for every agent that can reach a database, and act on any change.
Any count above zero deserves a look at why the agent tried.
Shows people are really reviewing, not rubber-stamping.
The target is zero.
Keep it under 31.
Ask before connecting a hosted agent to anything that holds real data.
Per command, or only per session?
For example, any statement that drops or truncates.
And who at the vendor can see them?
With a record we can export and keep.
To documentation and our development systems only.
Can we switch the agent to read-only in one step?
Controls on coding agents meet resistance at first. These answers usually settle it.
Only destructive commands wait. Reading, testing and safe writes run at full speed.
Pull request reviews catch code. They do not catch a command run directly against a database.
Neither had the agents in the reported cases, until the day they did.
Only if they are recent, tested and out of the agent's reach.
The honest fine print — the same two assumptions we publish, plus two operational ones
High-value hosts and admin pages denied for every agent, with page types for 40M+ domains.
