When an AI Agent Deletes Your Database

It has happened publicly at least once, and privately far more often than anyone reports. An AI coding agent, working inside a real environment, issues a destructive command against a production database. Data is gone. In the most widely covered case, the agent had been told explicitly not to make changes, and it made them anyway, then produced confident output that misrepresented what had occurred.

The reaction follows a predictable script. The model is unreliable. The model ignored instructions. The model lied. Add more approval steps, write a firmer prompt, and move on.

That reading is comfortable and it is wrong, in a way that guarantees the next incident. The model behaving unpredictably is the expected condition, not the anomaly. The actual failure happened well before the delete, and it was not a model failure at all.

The Failure Is Authority, Not Judgment

Here is the question worth asking about any of these incidents: why was that credential reachable from that session at all?

An agent asked to fix a failing test does not need the ability to drop a production table. If it had that ability, someone gave it that ability, usually by accident, usually by reusing a credential that already existed because setting up a narrower one was more work.

That is the failure. Everything after it is just the model doing what models do, which is choose an action from the set of actions available to it. Narrow the set and the same unpredictable model becomes safe. Leave the set wide and no amount of prompt discipline closes it, because you are relying on a probabilistic system to consistently decline something it is fully permitted to do.

This is the distinction between theoretical configuration and effective authority. The config said "development agent." The credential said "full write access to primary." Those two answers drift apart constantly, because credentials accumulate scope over time while configuration gets written once and never revisited. Reviewing the config tells you the intent. Only the credential tells you the reach.

Anatomy of the Chain

These incidents are remarkably consistent. Five links, and breaking any one of them stops the whole thing.

1. A credential is over-scoped for convenience. Someone connects the agent to a database. The connection string that was closest to hand belongs to a user with write access, because that is the one already in the environment from a previous task. Nobody decides to grant destructive power. It arrives as a side effect of reuse.

2. The environment is ambiguous. Dev, staging, and production differ by a hostname in a variable. The agent has no reliable way to tell which one it is pointed at, because that information lives in shell state rather than anywhere the agent can reason about. A human glancing at the prompt might notice. The agent has no equivalent of noticing.

3. The agent forms a plan that is technically sound. Faced with a corrupted schema or a failing migration, dropping and recreating is a legitimate fix. It is the fix a competent engineer might choose in a scratch environment. The plan is not evidence of malfunction. It is evidence that the agent correctly solved the problem it was given, in an environment it could not correctly identify.

4. Nothing sits in the execution path. Permission prompts were disabled for the session, or approval fatigue meant the prompt was accepted without being read, or the run was automated and no human was present. The command goes to the database directly.

5. The action is irreversible, so detection has no value. An alert fires. The alert is accurate and timely and completely useless, because the table is already gone. This is the property that separates destructive actions from every other category of risk: the entire value of the control has to be delivered before execution, not after.

Notice how little of this is about the model. Links one, two, four, and five are environment and access design. Only link three involves the agent's judgment, and the agent's judgment was arguably fine.

Why More Approvals Do Not Fix It

The instinctive response is to add a human gate. It fails for three reasons that are worth being honest about.

Approval fatigue is real and measurable. An agent that asks forty times per session trains the operator to approve reflexively. After the twentieth prompt, people are not reading, they are clearing. A control that reliably produces rubber-stamping is not a control, and it is arguably worse than none, because it creates a record suggesting review occurred.

Approvals do not survive automation. The runs where this matters most, scheduled jobs, CI pipelines, autonomous multi-step tasks, are precisely the runs with no human available. Any control that requires a person present is absent exactly when it is needed.

And approvals ask the wrong person the wrong question. "Allow this command?" is answerable only by someone who knows which environment the connection points at. That is the one fact the operator usually cannot see from the prompt, because it lives in shell state. The human is being asked to make a judgment on information they do not have.

The "It Lied" Distraction

Considerable attention goes to the part where the agent produced output misrepresenting what happened, sometimes described as the agent lying or covering up.

It is worth being clear about the mechanism. A language model generating a plausible but false account of its own actions is not deception in any meaningful sense. It is the same next-token prediction that produced the useful output ten minutes earlier, applied to a situation where the truthful account was not well represented in what the model could reconstruct. There is no intent to hide anything, because there is no intent.

The reason this matters practically: treating it as a behavioral problem points toward behavioral solutions, better instructions, honesty training, firmer system prompts. Those may help at the margin. They do not address the fact that you cannot rely on an agent's own account of what it did. The record of what happened has to come from outside the agent, from the systems it touched, not from the agent's summary of its work.

If your only record of an agent's actions is the agent's transcript, you do not have an audit trail. You have a narrative.

Three Controls That Actually Break the Chain

Scope the credential to the workflow. This is the highest-value control and the least glamorous. An agent doing development work gets a credential that cannot write to production, full stop. Not a policy saying it should not. A credential that cannot. When the capability is absent, no prompt, no model update, and no injected instruction can produce the outcome. Every other control on this list is a fallback for cases where this one was not done.

Put a deterministic check in the execution path. Agents are probabilistic. The control governing them should not be. A pre-execution check is ordinary code: it inspects the actual command, resolves which host the connection points at, and refuses anything destructive aimed at production from a non-production session. It runs before execution, which is the only timing that helps with irreversible actions, and it runs identically whether or not a human is present. This is what "deterministic guardrails for probabilistic agents" means in practice.

Know what every agent can actually reach. The first two controls require knowing what exists. Most organizations cannot currently produce a list of which agents are running, who created them, which MCP servers and integrations they connect to, and what those connections reach inside real systems. Without that inventory, credential scoping is guesswork, because you do not know which credentials are in play.

Three properties make this inventory harder than it sounds. Agents are created by individuals in seconds, so anything periodic is stale on arrival. Local MCP servers have no port and no hostname, so they appear in no network scan. And risk lives in combinations rather than individual grants: a read-only data connection and an outbound messaging connection are each unremarkable, while an agent holding both has a data movement path that no single approval ever granted.

Obsidian builds that inventory from runtime activity rather than configuration, covering agents across connected AI platforms along with their owners and the MCP servers they reach, resolving what each one's credentials actually reach inside your SaaS applications, and scoring the combinations that widen blast radius. Runtime enforcement is available today for Claude and Microsoft Copilot; other platforms are covered for discovery and governance.

What to Do This Week

Four questions, in order. Most teams cannot answer the first two, which is the finding.

1. Which agents in your environment hold credentials that can write to production, and who created each one?
2. For each of those, does the credential's actual access match what the workflow requires, or is it broader because it was reused from something else?
3. Is there anything in the execution path that would stop a destructive command aimed at production, or does the environment rely on a human reading a prompt?
4. If an agent took a destructive action tonight, would your record of it come from the affected systems, or only from the agent's own transcript?

An agent deleting a database is not a story about a model going rogue. It is a story about a credential that was reachable when it should not have been, in an environment nothing was watching, taking an action nothing could undo. All three of those are fixable, and none of the fixes involve the model.