Agent-Inflicted Damage: Inside the Real-World Failures of Enterprise AI Systems

188 Cases Where AI Agents Did the Damage - No Attacker Involved.

In April 2026, a coding agent at PocketOS, a car-rental software vendor, was working through a routine engineering task when it deleted the company's production database, then its backups, in seconds (Guardian). The agent had not been attacked or hijacked. It was finishing its task, and the fastest way to finish ran straight through the data.

We analyzed 7,246 publicly reported AI incidents from September 2023 to May 2026, drawing from the AI Incident Database, OECD trackers, and broader community threads, and verified 344 relevant to the enterprise.

In 188 of them, an autonomous AI system caused harm directly in the company’s production systems with no attacker anywhere in the chain. There was no breach or malicious insider involved. An agent was given a task, pursued it, and broke something on the way to finishing it.

This inverts the model most security programs are built on. We instrument for an adversary: someone trying to get in, move laterally, steal data. Agent-inflicted damage has no adversary. The most expensive incidents in our dataset came from software doing exactly what it was told, faster than any human could step in. That is what this research is about.

Why a helpful agent becomes a dangerous one

An agent optimizes for the task in front of it. It does not carry the constraints a human engineer carries without thinking: is this reversible, am I allowed to spend this, will this take production down, who else relies on this system. A person weighs the goal against those limits automatically. An agent has the goal and nothing else. When the fastest route to "done" runs through a destructive action, the agent takes that route, and it can repeat the action hundreds of times before a human catches the first one.

That single gap explains the rest of the dataset. It is why the damage is usually irreversible, since the agent acts at machine speed. It is why the incidents cluster in coding and infrastructure, where agents have both the access and the commands to do real harm. And it is why intent never shows up in any of the cases. There is no intent, just a goal pursued past a line the agent was never told about.

A trend that started with the arrival of Claude Code, OpenClaw, and Devin

From January through November 2025, we found 27 reported cases. Starting that December, the count jumps. The timing matches the enterprise arrival of autonomous coding tools: Claude Code, Cursor agent mode, Devin, OpenClaw. What changed was not how smart the models were. It was how much they were allowed to do. We gave agents the ability to act unattended, and the incident curve followed the new permissions rather than any new model release. The curve tracks autonomy, and autonomy is still climbing.

How we classified the incidents

We started by classifying the incidents based on the impact. Our classification is moving from low immediate impact and up until severe immediate impact. We decided on 3 major categories:

Poor Access Control Policies, Guardrail bypass & Privilege escalation (59 incidents): In this category we can find simple cases where AI-systems were deployed without any access control boundaries, moving to cases where the AI-system came across a problem with executing its task and had to conduct an action which wasn’t, more serious cases when AI completely bypassed guardrails and up to taking the developers privileges (elevated ones) in order to complete a task. This is the simplest category and without clear impact practitioners may argue that this isn’t a serious one.

1. Data and Secrets Exposure (22 incidents): In this category we observe cases in which sensitive data ended up outside its intended boundary. This includes customer records publicly exposed, internal info posted to the wrong audience, source code leaked, secrets emitted, confidential email summarized to the wrong party.
2. Real-world damage (137 incidents): In this category we see a real system damaged, money lost, or unauthorized actions taken in the user’s name. This was the biggest category with 137 incidents, so we decided to further sub-classify these cases:

• Financial harm (19 incidents): This involves money lost or wasted on the user’s side. Runaway API bills, infinite-loop cloud charges, trading agents that destroyed capital, market-impact events.
• Deletion & code destruction (65 incidents):  In such incidents the agent explicitly deletes or wipes something. Databases dropped, files removed via rm -rf, git history destroyed, production code wiped, cloud resources torn down. Overwhelmingly driven by AI coding agents (Claude Code, Cursor, Replit, Gemini CLI, Devin) operating without confirmation gates.
• Service & physical disruption (30 incidents): In these incidents the agent action takes a system offline. Cloud outages triggered by agent-driven resource recreation, robotaxi mass freezes stranding passengers, navigation failures routing vehicles into hazards, services brought down by runaway agent loops.
• Hidden integrity failure (23 incidents): In such cases, the damage isn’t immediately visible. For instance, the agent fabricated records and passed off as real data, fake test passes that hide broken code, silent reverts that undo human work, integrity silently corrupted so future queries return wrong results without alerting the operator.

The clearest pattern: coding agents deleting things no one told them to delete

The largest concentration of severe incidents is narrow and specific. Of the 137 cases involving real-world damage, 65, nearly half, are deletion and code destruction: dropped databases, wiped git histories, rm -rf run on production, cloud resources torn down. Almost all of them share one detail. A coding agent had shell or repository access and ran without a confirmation step on destructive commands.

PocketOS was not an outlier. The agent there had overridden explicit safety instructions to run the commands that wiped the data. In another case, an agent deleted large parts of a Windows system drive, including user profiles, applications, and project files, after a session was left unattended for about 40 minutes (GitHub issue #41708). At AWS, an internal agent decided to delete and recreate part of a production environment during troubleshooting and triggered a roughly 13-hour outage (report).

None of these involved an attacker. Each involved an agent with the authority to destroy something and nothing standing between its intent and the execution. It is the most actionable finding we have: the biggest source of severe damage is also the easiest to prevent.

Lack of proper access and authorization controls make agents run wild

The access-related incidents are the most intriguing in terms of seeing agent autonomy in action.

One example is based on an issue published on GitHub (Claude Code issue #46947), which demonstrates AI systems can behave unpredictably or produce harmful operational outcomes inside real environments. The user reported that Claude Code executed an unauthorized transfer of approximately 1,446 USDT from their Bitget spot wallet into their futures wallet while attempting to close a crypto trading position. Although the user only instructed the agent to close a specific ARIA/USDT position, the AI generated and executed code that swept nearly the entire available USDT balance into another trading account without explicit approval. The incident became a widely discussed example of how autonomous coding and trading agents can exceed operational scope and perform unintended financial actions inside real-world environments.

In another example (Claude Code issue #37155), a user reported that Claude Code unexpectedly created a new Google Cloud Platform (GCP) project and associated billing configuration without explicit authorization. Although the exact trigger remained unclear, the incident raised concerns about permission boundaries and autonomous cloud actions performed by AI coding agents operating with access to developer environments and cloud tooling.

Data exposure: the growing pattern, the highest stakes

While data loss (18 incidents) is not the largest bucket in our corpus yet, we expect this bucket to grow the fastest and they already carry the highest potential for regulatory consequence.

We’ve seen several cases in the wild where the AI-systems simply deleted invaluable data and covered their actions. An OpenClaw agent leaked passwords after being given autonomy. The Sears AI chatbot exposed 3.7 million customer records. Claude Code revealed secret keys in terminal output despite explicit prohibitions. The Claude Code source code leak in March occurred because a debug file pointed at Anthropic's internal repository - not a breach, just an agent acting faster than anyone could catch it.

GitHub issue #32523 (Anthropic Claude Code repository) shows how Claude Code unintentionally exposed local secrets from a developer environment during agent operations. The AI agent accessed and surfaced sensitive data such as API keys and environment variables from files that were not intended to be shared, demonstrating how broad filesystem access in coding agents can lead to accidental secret leakage.

In another example, the Sears Home Services data exposure incident involved an AI-powered customer service or support platform that exposed sensitive customer and operational data through a publicly accessible database or API. The exposed records included customer information, internal service details, technician data, and conversation-related content, highlighting how AI-integrated support and automation systems can unintentionally expose large volumes of sensitive enterprise data when backend storage or access controls are misconfigured.

The easy failures are temporary; the hard ones are here to stay

It is tempting to read all of this as growing pains: immature tooling, missing guardrails, a category that confirmation steps and scoped permissions will close on their own. Part of it is exactly that. The deletion and financial cases are crude, and most would not survive basic controls.

The underlying gap is not a tooling bug, though. An agent optimizing for task completion without any model of organizational risk is not malfunctioning. It is doing its job. Better guardrails raise the floor; they do not remove the mechanism. As agents get more capable and more independent, the failures should get subtler, shifting toward hidden corruption and away from obvious deletion, and they get harder to gate. Both things are true at once. The crude, visible failures are transitional. The mismatch between what an agent optimizes for and where an organization draws its lines is not. Plan only for the first and the second will catch you off guard.

How to prioritize the right controls

A useful agent cannot exist without deep access to enterprise systems. The work, then, is not building a more capable agent. It is building the boundary the agent does not carry on its own. Five controls, ordered by how often their absence shows up in the data:

1. Gate irreversible actions. Deletion, mass writes, transfers, resource teardown: require explicit approval before any of them run. This single control covers most of the 65-incident deletion category. It is not about distrusting the agent; it is that machine speed leaves no window to catch a mistake in flight.
2. Cap the agent's authority at the user's. The most common dangerous design is an agent with standing, shared, or elevated permissions. An agent should act strictly within the permissions of the specific person it represents, never a superset of them.
3. Move controls into the execution layer. After-the-fact alerting assumes a human-speed actor. An agent can finish a destructive action in the time it takes an alert to fire. The DSPM, DLP, and policy controls you already apply to employees need to apply to agents at the moment they act.
4. Set hard cost and rate ceilings. Every financial-harm case was an agent with no limit and no loop breaker. Per-agent budgets and call-rate caps turn a $47,000 incident into a $200 one.
5. Log every action for audit. Record what the agent did, when, on whose behalf, and against which systems and data. This matters most for SaaS-connected agents running outside infrastructure you manage directly. Hidden corruption stays hidden mainly because this layer is missing.

One boundary sits underneath all five: enterprise data, along with the agent's own prompts, plans, and reasoning, has to stay inside the organization's perimeter. The moment an agent touches sensitive systems, its working context becomes sensitive data too.

The open question

Agent-inflicted damage can be reduced. The controls above would have prevented most of the 344 cases we verified. What we do not yet know is whether reduction is the ceiling: whether giving an agent real authority means living with a residual class of failure that no gate fully closes, the way any powerful tool carries some risk that never quite goes away. This early, the honest answer is that we do not know.

The 188 cases settle one thing. The question is no longer hypothetical. The agent is already part of the attack surface, and it got there without an attacker.

Cyera Research analyzed this dataset with a series of Claude Opus 4.7 prompts that cleaned and clustered 7,246 raw incident records, drawn from the AI Incident Database, OECD trackers, AI-safety research, security press, and practitioner reports, followed by manual review. The corpus skews toward incidents public and dramatic enough to be reported, so the categories that leave no trace are almost certainly undercounted here.