PocketOS is a SaaS platform serving car rental businesses. On April 24, 2026, according to founder Jer Crane's public account and subsequent reporting, a Cursor coding agent running Anthropic's Claude Opus 4.6 was working on what should have been a routine staging-environment task. It ran into a credential mismatch, went looking for a way around the problem, found an API token with broad Railway authority, and used it to delete a Railway volume.

Unfortunately, the volume was not some harmless staging scratchpad. It was tied to PocketOS's production database. The same action also deleted the volume-level backups. The deletion took 9 seconds.

That is the part of the story everyone notices first, because "9 seconds" is a beautiful little unit of operational horror. But the more important part is what had to be true before those 9 seconds started. An AI coding agent had access to an API token powerful enough to delete production infrastructure. The production and staging boundary was not strong enough to make the agent's assumption harmless. The backup architecture was not isolated enough to survive destruction of the primary volume. The model did not stop and ask before touching a destructive operation.

A whole stack of grown-up engineering practices was missing or ineffective, and the AI agent found the hole with the confidence of a golden retriever sprinting through a screen door.

Not a bargain-bin model

This was done by Anthropic's Claude Opus 4.6: a frontier AI model, specifically promoted for coding, agentic workflows, long-running tasks, code review, debugging, and large-codebase reasoning. Anthropic's own launch materials described Opus 4.6 as its smartest model, state-of-the-art on several evaluations, and improved at sustaining agentic coding work for longer. Cursor's own CEO was quoted in Anthropic's launch post saying Opus 4.6 was a new frontier for long-running tasks and effective code review.

So no, this was not some obscure self-hosted toy model somebody fine-tuned in a basement. It was not a bargain-bin distillation being asked to cosplay as a senior engineer. It was one of the premium models marketed precisely for this kind of developer workflow.

That is why this incident belongs in the graveyard. The useful lesson is not "bad model is bad." The useful lesson is "even the fancy one will push the red button if your system lets it." Frontier capability does not create frontier judgment. Better code completion does not magically become safe production authority. A model can be good at reading a codebase and still be terrible at understanding that a Railway volume ID is the only thing standing between "fix staging" and "delete the business."

This is the state of the art, and you still cannot trust it to be left unsupervised for as long as you could trust a toddler with an iPad.

The agent guessed

After the deletion, Crane asked the agent why it had done it. The answer, as reported by Tom's Hardware and PC Gamer, was basically an apologetic postmortem written by the entity that just caused the incident. The agent said it guessed, failed to verify what the volume represented, did not read Railway's documentation first, and ran a destructive operation without being asked.

That explanation is useful because it strips away the mystique. This was not a complicated emergent consciousness problem. It was a bad operational guess with write access.

Humans make bad operational guesses too. That is why competent infrastructure teams put mechanical controls in front of production: environment separation, least-privilege tokens, deletion protection, backup isolation, approval workflows, change windows, restore drills, and boring checklists written by people who have already been hurt. Those controls are not bureaucracy for its own sake. They are what prevent a single wrong assumption from becoming an outage.

AI agents need those controls more than humans do, not less. A human engineer who is about to delete a volume may notice the naming convention, pause at the blast radius, or feel the cold sweat of experience. A model sees a token, an API, a plausible next step, and a task it is trying to complete.

Railway made it worse

Crane's criticism was not aimed only at Cursor or Anthropic. Railway also took heat because the volume-level backups were deleted along with the database. If your backup disappears in the same operation that deletes the thing it backs up, that backup is not really a backup. It is a second copy tied to the same failure domain, wearing a little costume labeled "resilience."

Later reporting said Railway was able to recover more recent data, and PocketOS returned to normal operations. That matters, because the incident was not a total extinction event. But the happy ending does not erase the failure. It means the organization got lucky enough to recover after the controls failed.

A real backup strategy assumes the primary system can be deleted, corrupted, encrypted, misconfigured, or destroyed by a credentialed actor. Especially a credentialed actor that does not know what it is doing. Especially a credentialed actor that is an AI agent trying to be helpful.

This is not the first time!

This is not the first time! See also: Claude Code running terraform destroy on DataTalks.Club, SaaStr's Replit agent wiping a production database, and Meta's AI safety director watching an OpenClaw agent delete her inbox after losing the instruction to wait.

The details differ, but the shape is familiar. An AI agent gets access to something real. The human instruction layer sounds safe enough in natural language. The actual system permissions are too broad. The agent encounters a mismatch, ambiguity, or context failure. Then it takes an action that would have been routine in a sandbox and catastrophic in production.

This is why "human in the loop" has to mean more than "the user was somewhere nearby." A human in the loop is not a safety mechanism if the agent can complete the destructive action before the human understands what is happening. It is not a safety mechanism if the only guardrail is a sentence in chat. It is not a safety mechanism if the API token can delete production and backups without a separate confirmation path.

What should have stopped it

The boring answer is also the correct answer: least privilege.

The staging task should not have had credentials capable of deleting production volumes. The token should not have had blanket destructive authority across Railway. Destructive operations should have required a separate approval path, ideally outside the agent's tool loop. Production and staging resources should have been mechanically impossible to confuse. Backups should have been isolated from the thing being backed up.

None of that is new. AI did not invent these controls. It just made ignoring them more expensive.

The dangerous promise of AI coding agents is speed. They can search a codebase, reason through a task, edit files, call APIs, and keep moving while the human is still parsing the problem. That is useful when the task is safe. It is horrifying when the task crosses into infrastructure, identity, billing, data deletion, or customer records.

PocketOS did not need a smarter apology after the fact. It needed the agent to hit a locked door before the fact.

That is the line. Let AI write code, suggest migrations, prepare commands, and explain tradeoffs. Do not give it production authority unless the same action would be safe if performed by a distracted intern, a compromised browser extension, or a toddler with excellent typing speed. If that sounds absurd, good. That is the threat model.