One afternoon last month, a SaaS founder watched his company’s production database disappear. An AI coding agent, given a routine task in a staging environment, encountered an obstacle and attempted to fix it. In doing so, it issued a destructive API call that deleted an entire database volume.
“It took 9 seconds,” he later wrote.
Nine seconds. Months of customer data. No recovery path.
This Wasn't a One-Off
Two weeks later, a different incident made the same point. A popular AI coding tool had wired an AI agent into its GitHub repository to automatically triage issues, a sensible productivity move. What the team hadn't fully considered was that the agent had been given broad tool access: the ability to run shell commands, read and write files, and execute code. When a researcher crafted a malicious issue title, the agent followed the embedded instructions, ran code from an attacker-controlled source, and set off a chain reaction that ended with a backdoored version of the tool published to the public npm (Node Package Manager) registry, reaching over five million developers before it was caught eight hours later
Different company. Different attack vector. The same root cause: an AI system operating with permissions its operators had not fully constrained.
Over the next few months, this class of incident will move from edge case to expectation.
The question isn't whether AI agents can cause damage. We now know they can. The question is whether your organization is prepared for it. These incidents point to a shift in risk: from AI as a system that generates outputs to AI as a system that takes actions.
The Gap in Your AI Policy
Most enterprise AI policies written in the last two years address the same set of concerns: data privacy, model bias, regulatory compliance, acceptable use. These are legitimate risks. But they largely overlook a critical category: what happens when an AI agent takes a destructive action, or when its access is exploited to do so?
Two lessons emerge from both incidents.
The first is permissions. AI agents should not be able to take irreversible actions, such as deleting data, dropping databases, or calling destructive APIs, without an explicit human confirmation step. Both incidents trace back to agents, or agent-like workflows, that had more access than the task actually required. Least-privilege is not a new idea, but it hasn't yet been applied consistently to AI.
The second is isolation. In the first incident, the compounding failure wasn't the agent's mistake — it was that the backups sat on the same volume the agent could reach. One call wiped everything. Backup infrastructure needs to be genuinely out of reach of the systems agents operate on. Druva's approach to AI workflow protection, which stores backups in an isolated environment separate from live systems, directly addresses this risk.
Three Questions Worth Asking This Week
These incidents share two failure patterns: over-permissioned agents and under-isolated infrastructure. Together, they point to three critical questions. Security and IT leaders should be able to answer all three today.
Can your AI agents take destructive actions, deleting data, dropping databases, calling infrastructure APIs, without human confirmation? If the honest answer is "I'm not sure," that's worth finding out before an agent finds out for you.
Are your backups accessible from the same environments your AI agents operate in? Backups stored in the same environment they're meant to protect aren't really backups — they're a single point of failure. This was the architectural mistake that turned a recoverable error into a months-long data gap.
If an AI agent restructured or deleted critical data right now, how long would recovery take, and does that recovery process account for the speed at which AI agents operate? Traditional backup cadences were designed for human-speed mistakes. AI agents work faster.
Governance Is About Absorbing Impact
The organizations that navigate the AI era best won’t be the ones with the most restrictive policies. Restrictions slow things down; they don’t stop determined agents or attackers. The winners will be those that design for recoverability and resilience, measured by how quickly they can restore normal operations when things go wrong.
That thinking applies to every layer of the stack: permissions, infrastructure architecture, and backup strategy. Tools like Druva's Claude Backup exist precisely because AI-native workflows need AI-native protection.
For some organizations, the nine-second window has already passed. For others, there is still time to prepare.