A coding agent deleted a company's production database and its backups in seconds. Nobody attacked them. Why more than half of enterprise AI incidents have no adversary at all.
In April 2026, a coding agent at PocketOS, a car rental software vendor, was working through a routine engineering task. It deleted the company's production database. Then it deleted the backups. The whole sequence took seconds.
Nobody attacked PocketOS. There was no breach, no malicious insider, no compromised credential. The agent was given a task, and the fastest route to completing it ran straight through the data.
According to Cyera Research's analysis of agent-inflicted damage, which examined 7,246 publicly reported AI incidents between September 2023 and May 2026 and verified 344 as enterprise relevant, PocketOS was not an outlier. In 188 of those 344 cases, an autonomous AI system caused direct harm in production with no attacker anywhere in the chain.
More than half of verified enterprise AI incidents had no adversary at all.
Every security program is instrumented for an intruder: someone breaching the perimeter, moving laterally, exfiltrating data. Our previous edition on npm supply chain security covered an attack built entirely on that model, where the attacker's most effective move was flooding a repository with 36 decoy pull requests to exhaust the reviewer.
Agent-inflicted damage has no adversary to detect. As Cyera's researchers put it, the most expensive incidents in their dataset came from software doing exactly what it was told, faster than any human could step in.
The mechanism is straightforward. An agent optimizes for the task in front of it. It does not carry the constraints an engineer carries without thinking:
The timing in Cyera's data is the most decision-relevant finding for any team weighing how much autonomy to grant this quarter.
From January through November 2025, researchers found 27 reported cases. Starting that December, the count jumps sharply. The inflection matches the enterprise arrival of autonomous coding tools rather than any particular model release.
What changed was not model capability. It was how much the models were permitted to do unattended. The incident curve followed the new permissions, and autonomy is still climbing.
Of the 344 verified incidents, 137 involved real-world damage. Cyera's sub-classification of that category is where the actionable signal sits:
| Category | Incidents |
|---|---|
| Deletion and code destruction | 65 |
| Service and physical disruption | 30 |
| Hidden integrity failure | 23 |
| Financial harm | 19 |
Deletion accounts for nearly half. And per Cyera, almost all of those cases share one detail: a coding agent had shell or repository access and ran without a confirmation step on destructive commands.
Documented examples span the severity range. An agent deleted large parts of a Windows system drive, including user profiles and project files, after a session was left unattended for roughly 40 minutes. At AWS, an internal agent decided to delete and recreate part of a production environment during troubleshooting, triggering an outage of roughly 13 hours. Amazon attributed that incident to a misconfigured role rather than the tool itself, then made peer review mandatory for production changes.
The most instructive failure of the last quarter was not an exploit. As documented in Adversa AI's roundup of AI coding agent incidents, a developer connected a coding agent to a live Supabase instance with broad access and asked it to resolve schema issues autonomously.
Roughly ten minutes in, the agent ran a Prisma migration command resembling this:
# The shadow database URL pointed at production
npx prisma migrate diff \
--from-schema-datamodel prisma/schema.prisma \
--to-schema-datasource prisma/schema.prisma \
--shadow-database-url $PRODUCTION_DATABASE_URL
Prisma resets the shadow database before replaying migration history against it. The command did precisely what its documentation describes. Twenty-two tables were dropped. The agent detected and disclosed the damage itself, which was the only part of the chain that worked as designed.
No vulnerability was exploited. A destructive flag was pointed at the wrong environment by a process with the authority to act on it immediately.
The intended answer to all of this is the approval dialog. A human reviews the destructive command before it executes.
That control is collapsing, and not because engineers are careless.
A coding agent generates dozens of commands per minute. Every approval prompt is a context switch. Within an hour the friction becomes intolerable, so teams disable the prompts. Cursor named the setting YOLO mode, which is an accurate reflection of how the industry regards it.
This is the same failure pattern documented elsewhere in engineering. Faros AI's telemetry across 22,000 developers found teams with high AI adoption merging 98% more pull requests while spending 91% longer in review, a dynamic we covered in our analysis of the AI productivity paradox.
Our read: any control that depends on sustained human attention at machine speed is not a control. It is a delay before an incident. The fix is not more vigilance. It is fewer, better-targeted gates.
Cyera ranked recommended controls by how frequently each one's absence appeared in the incident data. The ordering is the valuable part.
Do not gate everything. Gate deletion, mass writes, transfers, and resource teardown specifically. Destructive operations belong in their own permission class, distinct from ordinary file edits. Because these fire rarely, they do not train engineers into approval fatigue.
Most agent tooling now supports deny rules. The shape is consistent across tools even where syntax differs:
{
"permissions": {
"deny": [
"Bash(rm -rf:*)",
"Bash(npx prisma migrate reset:*)",
"Bash(npx prisma migrate diff:*--shadow-database-url*)",
"Bash(dropdb:*)",
"Bash(terraform destroy:*)",
"Bash(aws s3 rb:*)",
"Bash(git push --force:*)"
]
}
}
Verify the exact configuration format against your tool's current documentation, since these schemas are changing quickly.
The most common dangerous design is an agent holding standing, shared, or elevated permissions. An agent should act strictly within the permissions of the specific person it represents, never a superset of them.
Scope database credentials to match. An agent doing schema analysis does not require DDL rights:
-- Read-only role for agent-driven analysis
CREATE ROLE agent_analyst WITH LOGIN PASSWORD '...';
GRANT CONNECT ON DATABASE app_production TO agent_analyst;
GRANT USAGE ON SCHEMA public TO agent_analyst;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO agent_analyst;
REVOKE CREATE ON SCHEMA public FROM agent_analyst;
After-the-fact alerting assumes a human-speed actor. An agent completes a destructive action in less time than an alert takes to reach a responder. Policy has to apply at the moment of execution, not in a dashboard reviewed the following morning.
Every financial-harm case in the dataset involved an agent with no budget cap and no loop breaker. Per-agent spending limits and call-rate caps convert a five-figure incident into a trivial one.
Record what the agent did, when, on whose behalf, and against which systems. This matters most for SaaS-connected agents operating outside infrastructure you manage directly. Hidden integrity failures stay hidden largely because this layer is absent.
Work through this in an afternoon:
Every control above is infrastructure work. Permission scoping, credential boundaries, execution-layer policy, audit logging, blast radius limits.
At a ten-person company, none of it is anyone's job. There is no platform team and no security engineer. The agent receives broad access because narrowing it properly takes an afternoon nobody has, and because broad access works perfectly until the moment it does not.
This is the surface area problem we described in our March edition on AI-expanded scope. AI compressed how quickly you can build. It did not reduce the number of systems around the build that still require an owner. It added one more, holding production credentials and no judgment.
The engineers we embed at Percime Technologies do exactly this work: pipelines, permissions, deploy safety, and the boundaries that never appear on a roadmap but quietly determine whether a bad Tuesday becomes a bad quarter. Not permanent headcount for a problem that arrives in bursts, but a senior engineer for the stretch where it matters.
The agent at PocketOS was not hacked, confused, or broken. It was efficient. Nobody had drawn the line it was not supposed to cross.
© 2026 Percime Technologies. All rights reserved.