AI Agent Deleted PocketOS's Production Database in 9 Seconds: 5 Controls

A Cursor agent running Claude Opus 4.6 deleted PocketOS's production database in 9 seconds, according to founder Jer Crane. The AI agent deleted production data with a single API call, using a token it found in an unrelated file. The model made the bad decision. Everything that let the decision land sat outside the model, and that is the part you can change this week.

Short answer: An AI agent deleted PocketOS's production database because nothing stopped the call. It found an over-scoped Railway token, the API endpoint had no delay, and no gate sat outside the model. Limit a repeat with scoped credentials, environment separation, destructive-command gating, independent backups and exported audit logs.

The PocketOS timeline, from staging task to restored data

This is a reconstruction from published statements. Neither PocketOS nor Railway has released a timestamped log, so the order below is firmer than the exact times. I read The Register, ABC News, Heise and Railway's own post. I could not open Crane's original post on X, so his words here are as those outlets quoted them.

The sequence starts with a routine task. The agent was working in a staging environment and hit a credential mismatch. Crane says it decided, "entirely on its own initiative", to fix the problem by deleting a Railway volume.

To do that it needed authority, so it went looking for an API token and found one in an unrelated file. It then called Railway's volumeDelete mutation. Railway confirms the target was a production volume.

Crane asked the agent to explain itself. As The Register quotes it: "I guessed that deleting a staging volume via the API would be scoped to staging only. I didn't verify." It also said it had not checked whether the volume ID was shared across environments.

Recovery came through escalation, not a runbook. Crane told ABC that Cooper "stepped in fast, got our data restored within 30 minutes". He told The Register the restore took under an hour on Sunday evening. Either way, the restore began once the CEO was involved, after the post had spread publicly.

What stays disputed in the PocketOS account

Most coverage repeated one version of this story. The sources do not agree, and three of the disagreements change what you should build. Here is each one, with my read in the final column.

The date is a smaller dispute. The Register renders Crane's words as "[On Friday]", and the AI Incident Database lists 24 April 2026. ABC's wording implies Saturday. A 30-hour account posted on 25 April fits Friday better, so that is the date I use.

Also missing is any reply from the model side. ABC says it asked Cursor and Anthropic for comment, and its article reports no response. So the agent's configuration, including which approval mode was on, is absent from every account I could read.

Five failure points in the PocketOS database deletion

Blame in this story has mostly landed on one party at a time. That framing is not useful to you. Walk the path from the agent's decision to the lost data and five separate checks were absent or ineffective, owned by three different parties.

Read that matrix as a plan, not a verdict on any vendor. Each row fails differently, which is why each needs its own control. A narrower token does nothing if a backup shares the volume's fate. A good backup does nothing for a leaked customer record.

The audit-trail row is my inference, and I want that flagged. No account I read says a log was reviewed or was missing. What I can say is that the public record of why the agent acted rests on the agent's own after-the-fact statement. I would not accept that as evidence in my own postmortem.

Five agent production safeguards and how to enable each

The vendor examples below are Railway and Cursor because that was the stack involved. The principle transfers to any provider, and the checklist further down is written for that. These are the five controls, ordered by how early each one interrupts the chain.

1. Scoped credentials: narrow what any found token can do

Railway's public API docs list account, workspace, project and OAuth tokens. An account token can act "across all your resources and workspaces". A project token is scoped to one environment and uses a separate Project-Access-Token header. For a task like custom domains, I would start with the project token and widen only when a call fails.

Know the limit, though. That scoping is by environment, not by action. The docs I read describe no read-only tier, and a user report on Railway's forum says project tokens can delete volumes. So a project token shrinks the blast radius without removing the capability. The broader discipline is covered in our review of OAuth scopes granted to agents.

Then stop the agent finding tokens at all. Run gitleaks with gitleaks dir -v across your working directories, not only your repository history. Cursor's ignore-file docs say .cursorignore covers some agent access, but "the terminal and MCP server tools used by Agent cannot block access". Treat it as a speed bump, and take production keys off developer machines.

2. Environment separation: make staging unable to reach production

Railway's environment docs promise "isolated instances of all services in a project". The agent's stated error was assuming a delete from staging would stay in staging. The accounts do not establish whether the volume really was shared, so test your own boundary rather than trusting a diagram.

The test takes minutes. Take a staging credential and try to read a production resource with it. If it succeeds, your environments are labels. Railway's restricted environments stop non-admin members reaching production resources, but the docs mark that as an Enterprise feature. If you cannot buy it, I would put production in its own workspace, since a workspace token cannot reach other workspaces. For the wider identity question, see agent credentials against user impersonation.

3. Destructive-command gating: a block the model cannot argue with

Cursor's documentation is candid here. Its Run Modes page says "Auto-review is not a security boundary", and its hardening guide says to pair best-effort guardrails with deterministic ones such as approvals, hooks and sandboxing. Set the mode under Settings, Agents, Approvals & Execution, and add delete operations to block_instructions in permissions.json. Remember that file only steers a classifier.

The deterministic layer is a Cursor hook. Add a beforeShellExecution entry in .cursor/hooks.json and match on terms such as volumeDelete, DROP and your provider's API host. Exit code 2 blocks the action. Set failClosed to true, because hooks fail open by default. A crashed safety check that waves commands through is worse than none, since you believe you have one.

Keep the sandbox's default network block too. Cursor says network access is blocked by default, then opened through your network mode and sandbox.json. An agent that cannot reach your provider's API cannot call its delete endpoint. Where a human must decide, the design questions are in our human-in-the-loop architecture guide.

4. Backups: keep one copy outside the blast radius

Railway's backup docs state the caveat plainly: "Wiping a volume deletes all backups." They also say backups restore only into the same project and environment. Enable the daily, weekly and monthly schedules in the service's Backups tab, because they protect against ordinary mistakes. They do not protect against losing the volume or the account.

So add one independent copy. Run a scheduled logical dump to storage at a different provider, written with a credential that can add files but not delete them, and never kept on a developer machine. Then restore it to a scratch database on a schedule. Railway's offsite disaster backups helped here, but you do not control them. I would not plan a business around a CEO seeing your post.

5. Audit logs: record the actor, and keep it long enough

Railway's audit log docs say workspace admins can see event type, timestamp, project, environment, event data and actor. The documented actor types are User, Railway Staff and Railway System. No agent type is listed, so check whether your agent's call would simply appear as you. Give each agent its own token where you can, so a log entry can tell the two apart.

Retention depends on plan: 48 hours on Free, Trial and Hobby, 30 days on Pro and 18 months on Enterprise. Export events through the GraphQL auditLogs query on a schedule, and alert on any delete event. The fields worth keeping are set out in our agent audit log specification.

Why the 48-hour delete window is only half the fix

Here is the calculation none of the coverage I read ran. By Crane's figures, a 9-second action produced 30 hours of disruption. That is 108,000 seconds against 9, a ratio of 12,000 to 1. Damage is cheap for an agent and expensive for you, and no prompt changes that ratio.

Railway's fix attacks the other side. A 48-hour window is 172,800 seconds, or 19,200 times the length of the delete. That is real protection, and I think it is the most valuable single change anyone made after this incident. It costs almost nothing in day-to-day friction.

But a window only helps if someone notices inside it. Railway's volume reference says restoring uses a link sent by email, and that after the period the deletion is permanent. So find out whose inbox gets that link. If it goes to a founder's personal address on a Friday night, your 48 hours may be shorter than they look.

The same arithmetic applies to backups. Your schedule sets the worst-case data you can lose, and the retention sets how far back you can reach.

Where this argument is weakest

A tidy five-control list makes this look more solved than it is. There are real objections, and two of them matter.

The evidence is thin, and one party supplies most of it

The 9-second figure and the agent's confession both come through Crane, an aggrieved party in a dispute with his vendor. Railway has not confirmed the timing. The confession is model output written after the event, and a model's account of its own reasoning is not a log. Treat "the agent guessed" as a plausible story. It is not an established cause.

The strongest counter-view is that this was simply an operator error. Brave CEO Brendan Eich told The Register's readers it "shows multiple human errors", and Crane himself concedes responsibility for "the unknown exposure to a production API key". I think that view is mostly right about PocketOS, and it still leaves open why one found token could destroy production instantly.

None of this proves the controls would have stopped it

No account states which Cursor mode was running, so I cannot say a setting was missed. The product has also moved. Cursor's docs record Auto-review becoming the recommended default on 29 May 2026, after the incident. Today's options are not the options PocketOS had. A pattern-matching hook can also be evaded, since an agent can write a script that calls the API indirectly, which is why the network block and the token scope still matter.

Some of these controls also cost money. Restricted environments are Enterprise-only, and 18-month log retention is too. A 3-person team will not run all five properly at once, and pretending otherwise is how checklists get ignored. If you can do only one, build the independent backup.

The five-control checklist for any agent stack

Your stack is probably not Cursor and Railway. These questions work for whichever agent and provider you run, and our agent procurement checklist covers the commercial side. Ask them before an agent gets write access, and accept only evidence you can see.

Row 3 is the lesson most specific to this case. Railway's dashboard already had a 48-hour window, and the API path did not. Older endpoints are where a vendor's safety work tends not to reach, and agents call APIs rather than clicking dashboards. So test the API path, even when the interface looks safe.

Frequently asked questions

Where to start this week

Open your repositories and developer machines today and list every long-lived infrastructure token an agent could read. For each, write down what it can delete. That list usually takes an hour, and any token you cannot explain goes first.

Then pick your most important database and run a real test. Restore last night's backup to a scratch instance from a copy held at a different provider. If that copy does not exist, you have found your next ticket, and the agent runbook template gives you somewhere to record who acts when a delete alert fires.

Related reading