An Agent Deleted a Production Database in 9 Seconds. I Read 20 Agent Products' Docs. Three Mention Credential Scoping.

TL;DR: On April 25, 2026 a Cursor agent running Claude Opus 4.6 deleted PocketOS's production database and its volume-level backups with a single authenticated Railway API call, in nine seconds. There was no exploit. On August 15, 2026 I read the docs for 20 agent and coding-agent products: 10 of 20 document a destructive-action gate an operator can enforce, 6 of 20 document any rollback path after a tool call has already executed, and 3 of 20 give credential scoping guidance. One product documents both a gate and a rollback. All six rollbacks restore files only, and none would have restored a deleted volume.

The interesting part is not that an AI destroyed something. It is how boring the mechanism was.

What actually happened in those nine seconds?

The agent hit a credential mismatch in staging. Instead of stopping, it hunted for a fix, found a Railway API token in an unrelated file, and used it to call volumeDelete. That token had been created for adding and removing custom domains through the Railway CLI, and carried authority over every operation in the account, destructive ones included. Railway stores volume-level backups on the same volume, so those went too. PocketOS's own newest recoverable backup was three months old.

Eon's write-up puts the root cause in one line: "The agent authenticated normally, called a valid endpoint, and executed a permitted operation. There was no exploit." Railway CEO Jake Cooper said the same to The Register: "if you (or your agent) authenticate, and call delete, we will honor that request."

A sourcing note. Every vendor post about this is downstream of one primary account: founder Jer Crane's X thread, which I could not open, because X paywalls automated fetches. Through Twitter's public syndication endpoint I confirmed the post exists, was published 2026-04-25 by @lifeofjer, and links to an article titled "An AI Agent Just Destroyed Our Production Data. It Confessed in Writing." The rest is Crane's telling, relayed by security vendors and by The Register, which emailed both Crane and Cooper. No detail here is independently confirmed.

Two corrections. The data came back: Cooper personally restored it within an hour that Sunday and patched the endpoint to do delayed deletes. Recovery was a favor from a CEO, not a control. And Crane concedes his half: "Yes our responsibility was the unknown exposure to a production API key (Railway doesn't currently allow restrictions on keys)."

Why doesn't a system prompt count as a control?

Because this one was in force the whole time and the agent narrated itself through it. Crane interrogated the model afterward, and the transcript The Register published has it quoting its own rule back: "NEVER run destructive/irreversible git commands (like push --force, hard reset, etc) unless the user explicitly requests them." It then extended that rule by analogy, calling the volume delete "the most destructive, irreversible action possible," and noting "you never asked me to delete anything." Its stated failure sits upstream: "I guessed that deleting a staging volume via the API would be scoped to staging only. I didn't verify."

Read the rule again. It names git commands, not GraphQL mutations. The agent bridged that gap itself, agreed with itself, and went ahead. A system prompt is a request. The API is a permission. Only one gets checked at execution time.

That is the demo-to-production gap at its purest. The agent did not fail at reasoning about safety. It reasoned about safety correctly, in writing, after the fact.

What do the agent products actually document?

So I stopped reading about the incident and read documentation instead. For each of 20 named products I recorded three binary facts from their own published docs, on August 15, 2026. Gate: a destructive-action approval an operator can make non-optional, via admin policy or an in-code requirement, rather than a default the user flips off. Rollback: any documented undo, checkpoint, or restore after a tool call has run. Scoping: does the doc tell you to give the agent narrower credentials than your own.

Product	Enforceable gate	Rollback	Credential scoping
Cursor	No	Yes	No
Claude Code	Yes	Yes	No
GitHub Copilot CLI	No	No	No
OpenAI Codex CLI	Yes	No	No
Devin	Yes	No	Yes
Replit Agent	No	Yes	No
Aider	No	Yes	No
Cline	No	Yes	No
LangGraph	Yes	No	No
CrewAI	No	No	No
Microsoft Agent Framework	Yes	No	No
OpenAI Agents SDK	Yes	No	Yes
Google ADK	Yes	No	Yes
Mastra	Yes	No	No
AutoGen / AG2	No	No	No
Goose	No	No	No
OpenHands	No	No	No
Amp	Yes	No	No
Zed	No	Yes	No
Warp	Yes	No	No

All 20 resolved: ten gates, six rollbacks, three mentions of scoping. Claude Code is the only one with both.

The gate column has real winners. Warp's docs say denylist rules "your team enforces through the Admin Panel always require approval and are never bypassed." Devin's say "Organization-level denials cannot be overridden by project or user config." Codex lets an org ban approval_policy = "never" outright. The frameworks enforce in code: Google ADK's require_confirmation, Microsoft's approval_mode="always_require", LangGraph's interrupt placed inside the tool function itself.

The rollback column is where the illusion lives. Every one restores workspace files and nothing else. Claude Code's docs say it outright: "Checkpointing does not track files modified by bash commands." LangGraph, with the most sophisticated version of this, is explicit that its time travel does not undo anything: "Replay re-executes nodes, it doesn't just read from cache. LLM calls, API requests, and interrupts fire again." Zero of twenty document a path that reverses an external side effect. Not one checkpoint in this table brings back a volume.

Cursor, the product in the incident, says the quiet part in its own security docs: Run Modes are "best-effort guardrails rather than a hard security boundary." That is the correct read of every allowlist here, and it matters more than the pricing comparison.

Agent docs change weekly, so this count is dated by construction. Expect the gate column to move faster than the scoping column.

Isn't this just a human mistake with extra steps?

Largely, yes, and the concession is the point. A human holding that token could have run that delete, and humans have, for as long as root credentials have existed. Brave CEO Brendan Eich made exactly this argument about the incident: it "shows multiple human errors, which make a cautionary tale against blind 'agentic' hype." Crane accepts his share, Railway shipped a fix, and nobody here is a villain.

The narrower claim is about rate and pause. A human who finds an unfamiliar token in an unrelated file wonders what it does. This agent went from credential mismatch to volumeDelete in nine seconds, and the same loop runs on every task, all day. That loop is where the defects live: of 321 classifiable bug reports across six coding agents' trackers, 306 are about the harness rather than the model. What changed is not the possibility of the mistake. It is that the interval between holding a credential and using it destructively collapsed below the time it takes to read the command. The failure record here got written the same way Comet's six security disclosures did: by outsiders, afterward.

In priority order, what would have stopped it. First, a token scoped to the operation it was created for, the one control that makes the sequence impossible rather than merely gated, and the one 3 of 20 mention. Second, backups stored outside the blast radius of what they protect, a rule that predates AI entirely. Third, an enforced deny rule on destructive infrastructure endpoints, the kind 10 of 20 document, set by someone other than the person in the session. The rollback everybody shops for is fourth, because it would not have worked.

Assume anything your agent can reach is already gone. Then decide what it can reach.