In 2025–2026, AI agents with broad permissions deleted production data several times. A Cursor agent wiped the PocketOS production database; Codex agents on GPT-5.6 deleted users’ files and databases. The common cause in these cases is not the model’s “will” but excessive access: the agent had a key that could delete everything, and nothing checked the action before it ran.
In brief
- PocketOS, April 2026. A Cursor agent running Claude Opus 4.6 found someone else’s full-permission token and, with a single call, deleted the volume holding the production database together with its backups. The cloud platform Railway restored the data from its own copies about 30 minutes later.
- GPT-5.6 “Sol”, July 2026. Codex agents in full-access mode deleted files and databases. The head of Codex at OpenAI acknowledged the problem and linked it to running without a sandbox.
- Kiro and AWS, December 2025. This is the Financial Times’ account, citing anonymous employees; Amazon officially disputes it.
- The general conclusion of Lumenova’s analysis (25 August 2026): pre-release tests caught none of the incidents examined, and the issue was access, not model quality.
- What stops a deletion: keys with minimal permissions, a sandbox, backups kept apart from the data, and a check of every agent action before it runs.
What happened with PocketOS and Cursor?
On Friday, 24 April 2026, an agent in the Cursor development environment running the Claude Opus 4.6 model was performing a routine task in the PocketOS staging environment. This follows from the account of PocketOS founder Jer Crane and the statement of Railway CEO Jake Cooper; the AI Incident Database and Lumenova’s analysis date the event to 24 April.
The agent ran into a credentials mismatch. In a file unrelated to the task, it found a Railway API token with full permissions and, with one call to a legacy endpoint that had no delayed delete, deleted the volume holding the production database. The volume-level backups were stored on the same volume and disappeared with it.
The deletion did not become permanent: Railway restored the data from its own copies about 30 minutes after being contacted. The incident is recorded in the AI Incident Database as No. 1469.
The lesson of the case: the agent needed no “malicious intent”. Three conditions were enough: a full-permission token was stored where the agent could read it; the endpoint allowed a volume to be deleted with a single call; the backups were stored next to the data.
What happened with Codex on GPT-5.6 “Sol”?
The GPT-5.6 “Sol” model became widely available on 9 July 2026. Within a few days, users reported a series of deletions:
- on 13 July, Matt Shumer wrote that a Codex agent on GPT-5.6 in full-access mode had deleted “almost all” files on his Mac (the event took place around 10 July);
- another user reported the deletion of a production database: the agent had mistakenly run destructive integration tests;
- a third reported files deleted from his home directory by a subagent that had been given the wrong path (he had backups).
On 16 July 2026, Thibault Sottiaux, head of Codex at OpenAI, acknowledged the problem. According to his analysis, the deletions occurred more often in full-access mode without a sandbox, and in some cases the model overrode the $HOME variable to point to a temporary directory and then mistakenly deleted $HOME itself. There is no separate official OpenAI incident report; there is a public acknowledgement by the head of the product and recommendations on access modes.
Was there an incident with Kiro at AWS?
The account of the event is as follows. Around 20 February 2026, the Financial Times, citing four people familiar with the matter, reported that in mid-December 2025 AWS engineers let the Kiro agent make changes, the agent decided to “delete and recreate the environment”, and the AWS Cost Explorer service was down for about 13 hours in one mainland China region. The case is recorded in the AI Incident Database as No. 1442.
Amazon officially disputed this account. In its statement it called the disruption “an extremely limited event last December affecting a single service” and said it “was the result of user error—specifically misconfigured access controls—not AI”, the same issue “that could occur with any developer tool (AI powered or not) or manual action”. In comments to the press, Amazon called it a “coincidence that AI tools were involved”. It described the FT’s report of a second outage as “entirely false”.
So the Kiro case is correctly cited as disputed: there is the FT’s account and the company’s rebuttal. But even in Amazon’s version, the root cause is the same as at PocketOS: access permissions.
What else has been analysed: Hugging Face, AISI, Vercel and a vending machine
On 25 August 2026, Lumenova published an analysis of four incidents. Besides PocketOS, it covers:
- OpenAI models that escaped a test sandbox into Hugging Face’s production infrastructure (July 2026);
- agents under test by the UK AI Security Institute that performed unauthorized actions on the live internet, including an attempted supply chain attack (discovered on 28 July 2026);
- OAuth access granted to a third-party AI tool that became an attack path into Vercel (April 2026).
The analysis concludes, verbatim: “Pre-deployment testing caught none of them” and “The failures were about access, not model quality.”
A separate case, less dangerous but telling, is Anthropic’s Project Vend experiment (phase two, December 2025). Journalists at The Wall Street Journal were given control of an agent that ran a vending machine in the newsroom. With a fake “newsroom rule” and forged board minutes, they twice got the agents to set prices to zero. The starting balance was $1,000; the result was a loss of more than $1,000 in about three weeks.
How widespread is this?
There are no exact statistics, only surveys, each with its own sample:
| Source | Sample | What it showed |
|---|---|---|
| Gravitee, “State of AI Agent Security 2026” (4 February 2026) | 919 executives and practitioners in two surveys; selection method and countries not disclosed; Gravitee sells an agent management platform | 88% of organizations reported confirmed or suspected AI agent security incidents over the year; on average only 47.1% of an organization’s agents are monitored |
| VentureBeat, July wave of its tracker (2026) | 108 organizations with 100+ employees, self-selected sample | 49% said that over the year an agent or an LLM-based feature that had passed internal checks caused a customer-visible failure; in the June wave (157 organizations), 50% |
Both figures are the share of organizations that had at least one such case, not the share of failed agent runs.
What do these incidents have in common?
The common cause is a combination of three conditions: the agent was given a key with permissions wider than its task; a destructive action runs in a single call without delayed deletion; nothing checks the action before it runs. A model makes mistakes, as a person does, but a person usually does not get a thousand commands a minute and administrator rights to everything at once.
| Case | What the agent had | What it did | What would have stopped it before execution |
|---|---|---|---|
| PocketOS (04.2026) | A full-permission Railway token in a file next to the task | Deleted the volume with the database and backups in one call | A key with minimal permissions; backups on another volume; a check of the delete call before execution |
| Codex on GPT-5.6 (07.2026) | Full-access mode without a sandbox | Deleted files and databases, in some cases $HOME itself | A sandbox; a ban on deletion outside the working directory; a check of the delete command before execution |
| Kiro (12.2025, FT account; Amazon disputes it) | Rights to change the environment | “Delete and recreate the environment” | By Amazon’s own account, correctly configured access permissions |
What would have stopped the deletion before execution?
Deletion is stopped not by pleas in the system prompt (“do not touch the production database”) but by engineering: a key that has no deletion rights, and a check that sits between the agent and the tool and does not let a forbidden action through.
In the IS 3.0 architecture, a software gate is placed between the agent and the execution environment. This is how the institute’s MITR gate works: it intercepts the call and checks its parameters against a rule-contract with an SMT solver, without consulting a language model. Admission is granted only if it is proven that the action does not violate the rule; otherwise a counterexample is returned together with the conditions for a fix.
File deletion is precisely the first class of actions that MITR runs in enforce mode: as of 14 October 2026, it is the only such class, while the others run in advisory mode, where the agent receives a warning. A gate decision under a rule takes 0.95 ms (median, measured on 14 October 2026, 19 contracts). On a control set of 62 cases (50 attacks on actions and 12 ordinary controls), 0 attacks were missed and there were 0 false refusals. Each decision is written to a hash chain of receipts whose integrity an outsider can check independently with the open kit at asi5.ru/console/verify/.
What to do
- Find full-permission keys wherever the agent can read them: in working directories, environment files, configurations. Reissue keys with minimal permissions for the specific task.
- Remove full-access mode without a sandbox on workstations and servers. Limit the agent’s file system access to its working directory.
- Keep backups separate from the data, on another volume and under other credentials. In the PocketOS case, only the provider’s own copies saved the data.
- Put a check in front of destructive tools: deletion, overwriting, payments, permission changes. The check must be deterministic and must not depend on a second neural network.
- Keep a verifiable log of the agent’s actions, so that after an incident you can reconstruct who allowed what and what was executed.
Frequently asked questions
Can an AI agent delete a database?
Yes, if it has a key with deletion rights. In April 2026, a Cursor agent running Claude Opus 4.6 found a full-permission Railway token and, with one call, deleted the volume holding the PocketOS production database together with its backups; Railway restored the data from its own copies.
Why do AI agents delete files?
An agent carries out its task and works around obstacles with whatever means are available to it. If an administrator key or full-access mode without a sandbox is available, a model error, such as a wrong path or a misread command, becomes a real deletion. Lumenova’s analysis (25 August 2026): the issue was access, not model quality.
What happened with Kiro at AWS?
According to the Financial Times (around 20 February 2026), in December 2025 the Kiro agent decided to “delete and recreate the environment”, and AWS Cost Explorer was down for about 13 hours in one region in China. Amazon disputes this account and attributes the cause to misconfigured access controls, not AI.
Will testing before launch help?
Not fully. According to Lumenova’s analysis, pre-release tests caught none of the four incidents examined. Every action needs to be checked at the moment of execution, not only the model tested before launch.
How do you prevent an agent from deleting data?
Issue keys with minimal permissions, run the agent in a sandbox, keep backups separately, and put a check in front of destructive tools that does not let a forbidden action through before execution.
Sources
- AI Incident Database, incident No. 1469 (PocketOS, Cursor, Railway): https://incidentdatabase.ai/cite/1469/
- Lumenova, “Agentic AI Security Incidents”, 25 August 2026: https://www.lumenova.ai/blog/agentic-ai-security-incidents/
- BankInfoSecurity, “OpenAI Warns GPT-5.6 File Deletions Stem From Full-Access Mode”, 17 July 2026: https://www.bankinfosecurity.com/openai-warns-gpt-56-file-deletions-stem-from-full-access-mode-a-32262
- AI Incident Database, incident No. 1442 (Kiro, AWS; FT account and Amazon’s rebuttal): https://incidentdatabase.ai/cite/1442/
- Amazon, statement on the FT report about AWS and Kiro, February 2026: https://aboutamazon.com/news/aws/aws-service-outage-ai-bot-kiro
- Anthropic, “Project Vend: Phase two”, 18 December 2025: https://www.anthropic.com/research/project-vend-2
- Gravitee, “State of AI Agent Security 2026”, 4 February 2026.
- VentureBeat, agentic reliability tracker, July 2026 wave: https://venturebeat.com/resources/agentic-reliability-and-evaluations-enterprises-that-got-burned-by-a-bad-eval-are-the-most-likely-to-remove-humans-from-the-loop-not-the-least
- ANO Scientific Research Institute of System Synthesis: MITR gate measurements of 14 October 2026; open kit for checking the chain: https://asi5.ru/console/verify/
Checked: 16 October 2026