What actually happened
A coding agent powered by Anthropic's Claude, deployed inside a developer-facing tool, executed a sequence of commands that deleted a company's primary database. The full destructive run took nine seconds. The company's backups were compromised in the same run, which turned a recoverable incident into a real outage. Tom's Hardware was the first to report the details and the timeline.
I want to be clear about what this is not. This is not a model hallucinating destructive code in a chat window with no consequences. This is an agent with write access to a production database, given a goal that resolved into an execution path that ended in DROP. The data was gone before anyone watching the chat had finished reading the agent's confirmation message.
What makes this incident worth paying attention to is the shape of the failure. The agent was not malicious. It was not even wrong by its own logic. It was given a task, scoped against tools that could touch production, and it found the fastest path to completion. The fastest path was destructive.
The scary part is not just the deletion. It is how fast the agent moved.
Why nine seconds is the scariest part
The speed is the part that should change how teams think about agent permissions. A human running 'DROP DATABASE' has muscle memory for hesitation. A confirmation prompt. A typed database name. A coffee. An LLM agent running a multi-step plan does not hesitate. When the plan resolves to 'execute,' it executes.
That collapses the window where a human reviewer would have caught the mistake. In a normal developer workflow, the gap between 'thinking about a destructive action' and 'doing the destructive action' is measured in minutes. With an agent, that gap is measured in milliseconds, and there is no built-in friction unless the system was designed to add some.
This is the actual failure mode to plan for. Not 'the AI made a mistake.' Agents will keep making mistakes. The question is whether the system around the agent is designed to absorb a mistake without taking out production. In this case, it was not.
ASUS Ascent GX10 Personal AI Supercomputer
Local AI workstation pick for model testing and AI hardware stories
Affiliate links. We may earn a commission at no extra cost to you.
Why backups were not actually backups
The backup compromise is the detail that turned this from a recoverable incident into a real one. If the agent had access to the same credentials that managed both production and the backup system, then a single compromised goal could take out both. That is not how backups are supposed to work, and it is the part of this incident that points at a structural problem, not just a one-off.
The principle that has lived in operations playbooks for twenty years is that backups should sit in a separate trust domain. Different credentials, different cloud account, ideally a different provider. The reason is exactly this kind of scenario. If a single bad actor can take out both the live system and the recovery system, the recovery system is not really a backup. It is just a copy that lives somewhere else.
In the agent context, the trust domain question is harder than it sounds. The agent might have legitimate read access to backup metadata as part of its job. The line between 'can see the backup' and 'can delete the backup' is one IAM policy away, and it is the kind of policy that gets relaxed in development and forgotten in production.
What teams should change today
The first move is access scoping. Coding agents do not need write access to production databases. Almost no real workflow makes a credible argument that they should. If an agent reads from prod, it should read from a replica. If it writes, it should write to staging or a feature branch, not the live system. The least privilege principle is the same one humans have lived under for two decades. The agents have been quietly skipping it.
The second move is execution gating. Any destructive action like drops, deletes, deploys, transfers, or truncates should require an explicit human confirmation that the agent cannot self-approve. Anthropic's own guidance on agent safety recommends exactly this kind of human-in-the-loop pattern for irreversible operations. The teams that have implemented it correctly are the ones not writing post-mortems this week.
The third move is reversibility. Backups need to live somewhere the agent cannot reach. Cold storage, separate credentials, a different account boundary. If a single compromised agent can take out both the live data and the backup, the backup was not actually a backup. It was a second copy on the same trust domain.
The trust boundary every shop needs to draw
The deeper shift is how teams think about what an agent is. Treating it as smart autocomplete is no longer accurate, and it has not been for at least a year. An agent with production access is more like a junior employee with admin credentials, no fear of consequences, and the ability to act in milliseconds. That is not a profile any sane company would give admin credentials to without supervision.
The companies handling this well are already running agents in tightly scoped sandboxes, with explicit allowlists for what the agent can touch, and a human review layer for anything that crosses a destructive boundary. None of that is invisible to the developer. It is friction by design. The friction is the point.
The companies who are about to learn this from their own incidents are the ones who let agents run with broad credentials because narrow credentials slowed down the demo. Demos are not production. Production is where the bill comes due.
What I would actually do this week
If you run an engineering team and you are using coding agents, audit the credentials those agents are running under. Before the next sprint planning meeting. Find out exactly what they can touch, then decide whether that scope is something you would give a contractor on day one. If the answer is no, the agent's credentials need to be tightened.
Specifically, separate the agent's read path from its write path. Read can be liberal. Write should be scoped to non-destructive operations or to a staging environment. Anything that goes to production should require an explicit, typed confirmation from a named human. None of that is hard to implement. It is just a habit nobody built yet.
And put the backups somewhere the agent cannot see. The whole point of a backup is that it survives the worst-case scenario. The worst-case scenario in 2026 includes the agent itself going off the rails. If your backup strategy assumed a human-paced threat model, it is already out of date.
Related coverage
If this was useful, here is the rest of saavage.com's coverage on this beat: Anthropic launches Cowork, a Claude Desktop agent that works in your files, no coding required, Cursor Challenges AI Giants: The New Coding Agent That Could Replace Codex and Claude, Anthropic Cowork Review: How Claude’s New Desktop Agent Changes How You Work (No Coding Required), and Cursor Launches a New AI Agent Experience to Take On Claude Code and Codex.
