Cursor Coding agent Deletes a Production Database
A Cursor coding agent wiped a production database and its backups through a valid API call. Traditional DLP could not catch it.
A Cursor coding agent wiped a production database and its backups through a valid API call. Traditional DLP did not catch it, and it is not designed to catch the next incident of this kind.
What happened
A Cursor-based AI coding agent running Anthropic's Claude Opus 4.6 deleted PocketOS's production database and associated volume-level backups through Railway's API in roughly nine seconds, according to the company's founder, Jeremy Crane, and corroborating reports from Zenity, The Register, and The Guardian.
The agent encountered a staging-credential problem, found a broadly scoped token in an unrelated file, and used it to invoke a destructive Railway API operation without requesting confirmation. Because the request was authenticated, the API accepted it and carried out the deletion immediately.
Railway has since changed the API so that destructive deletes use a 48-hour delayed-delete window with an instant-undo option, matching the behaviour that already existed in the dashboard. Cascading backup deletion is also delayed rather than immediate.
This is a recovery-time (RTO) control, not a complete permissions fix.
What is actually new here
The model did not simply type a bad SQL command. The agent autonomously discovered a token with excessive permissions, decided to use it, and called a destructive API endpoint. No human was in the loop. No confirmation was requested.
This was not exfiltration. Nothing left the perimeter. The data was simply deleted.
Anyone using agentic AI can end up in the same position if they give an agent dangerous permissions without appropriate controls.
Cursor calls its most permissive setting Run Everything. It is a run mode in which tool calls execute automatically without an approval prompt. The community has sometimes referred to earlier versions of this feature as “YOLO mode,” but Cursor's current documentation uses Run Modes and Run Everything. Depending on the sandbox and token permissions, this can create a direct path from the agent interpreting an instruction to changing files, running commands, or modifying infrastructure.
Claude Code has a similar setting called bypassPermissions, enabled with the --dangerously-skip-permissions flag. The name is unusually candid: it removes the normal confirmation prompts so the agent can execute file changes and commands immediately. Used inside an isolated container or disposable development environment, that may be a deliberate trade-off. Used against a machine or cloud account containing production credentials, it turns every over-broad permission into an immediate action path.
The PocketOS incident illustrates why removing the human checkpoint is not merely a convenience setting. It is a meaningful expansion of the agent's operational authority.
The risk does not require a leaked credential or a sophisticated attack. A simple misunderstanding in the prompt can be enough when the agent has permission to act and is not required to ask for confirmation.
I run a Hermes agent at home. One evening, I asked it to change something in a SQLite database. It deleted a list of records without asking for confirmation. There was no “Are you sure?” prompt—just a misunderstanding between what I asked for and what the agent thought I meant. The stakes were low. The pattern was identical.
What is new is not that credentials can be leaked or that APIs can accept destructive calls. What is new is that an autonomous agent can chain those two failures together in seconds, without a human checkpoint, and cause irreversible damage before anyone notices.
Why it matters to your company
Traditional DLP is designed primarily to detect data leaving the perimeter. SIEM systems correlate and surface events, often after the fact. IAM controls who can access what. None of these controls is designed to stop a legitimate agent action that destroys data from inside the environment, using valid credentials and an otherwise permitted API.
If your developers are using AI coding agents such as Claude Code or Cursor with access to production credentials, you are exposed. If those credentials are account-wide rather than project- or environment-scoped, the blast radius includes everything that account can reach.
Even more concerning, many companies now have non-developers using autonomous coding tools to build small internal applications and “micro-apps.” An autonomous coding agent such as Claude Code or Cursor can effectively perform the work of a software developer—but nobody has told HR.
Most SMEs do not have a dedicated AI security function, but they still need an AI security strategy. Many already have developers and other employees experimenting with agents that can access real API keys, cloud infrastructure, source code, and production systems.
That is the gap: the agent is operating inside the perimeter, with valid access, but without the contextual controls and human checkpoints normally applied to high-impact actions.
What to do about it
Three actions you can start this week.
Audit your API tokens. Find every credential that an agent, CI system, or script can access. If any are account-wide, replace them with project- or environment-scoped tokens wherever possible. A staging agent should never hold a production token.
Isolate your backups. If your database and its backups live in the same volume or recovery domain, a single delete operation can take both down. Backups should be separate from the production account, credentials, and failure domain, with recovery procedures tested regularly.
Add a human gate for destructive operations. Use an external policy engine, a confirmation step in the agent's tool layer, or simply remove destructive permissions from agent-scoped tokens altogether. An agent should not be able to call volumeDelete on production without explicit human approval.
Close
The PocketOS incident was not a breach in the traditional sense. The agent used valid access to perform a destructive action, and the existing security stack was not designed to stop it.
That distinction matters. If you have agents with real credentials, DLP is not the control that will save you. You need controls that understand what an agent is about to do, where it is doing it, and whether a human should approve the action before it becomes irreversible.