AI agent deleted a production database: PocketOS and Railway

The agent made one valid API call with a token it found

The account of the agent's side comes from PocketOS's founder, Jer Crane, as quoted by The Register on 27 April 2026. Crane's original post on X could not be retrieved for this entry, so everything attributed to him here is as The Register reports it.

On the Friday before that report, which by the calendar is 24 April 2026, "an AI coding agent – Cursor running Anthropic's flagship Claude Opus 4.6 – deleted our production database and all volume-level backups in a single API call to Railway, our infrastructure provider," Crane wrote. "It took 9 seconds." Per the same report, the agent hit a credential mismatch in the staging environment, looked for an API token, and found one in an unrelated file. The token had been created for adding and removing custom domains through the Railway CLI, but it was scoped for any operation.

Railway published its own account on 29 April 2026. It shows the command at the centre of the incident:

curl -X POST https://backboard.railway.app/graphql/v2 \
  -H "Authorization: Bearer [token]" \
  -d '{"query":"mutation { volumeDelete(volumeId: \"3d2c42fb-...\") }"}'

Railway's reading: "The request was authenticated, and our API honored it the same way it would for a CLI command or a CI pipeline. The difference is that it came from an AI agent." It adds that the agent "found a Railway API token stored locally on the user's machine", and that "We've since recovered the database, and the customer is back up with all their data."

Nothing was exploited. A credential existed where the agent could read it, the credential had the widest scope the platform offers, and the call it unlocked could not be undone.

Three separate controls were missing

Railway's post splits the failure into three parts. Each needs a different fix, and a fix to one does not cover the others.

Two details in that table are worth keeping apart. The post says "all deletes", while the changelog entry of 1 May 2026 says "Volume deletions over the API now soft-delete for 48 hours." Read the changelog as the narrower, dated claim.

The post also says Railway keeps "disaster backups" offsite regardless of whether a user configures backups. In this incident the cascade made the backups look unavailable in the UI, and Railway says it recovered the database. Crane, per The Register, wrote that "Railway stores volume-level backups in the same volume". Railway's post does not address that sentence directly, and this entry does not settle where each kind of backup lived.

Token scope: the documented options and the disputed one

Railway's API documentation, read on 17 October 2026, lists account, workspace and project tokens. On the account token it says: "If you select "No workspace", the token will be tied to your Railway account. This is the broadest scope." Its project token section reads: "Project tokens are scoped to a specific environment within a project and can only be used to authenticate requests to that environment."

By that documented scope, a token limited to a staging environment cannot authenticate requests to production. Railway's post agrees that "The right scope existed, but the flow didn't make it obvious which one to pick, and the path of least resistance produced a token with more access than the work required."

Crane told The Register something different: "Railway doesn't currently allow restrictions on keys". The two statements may describe different token types or different moments, and the sources do not say which. What both support is a general rule. When a platform offers several token scopes, the default or easiest one is often the widest, and an agent that finds a file with a token will use the token as it is.

A prompt rule is advice, a delay window is enforcement

The Register quotes the agent's own later explanation, in which it cites the rule it was working under: "NEVER run destructive/irreversible git commands (like push --force, hard reset, etc) unless the user explicitly requests them." The agent said it had guessed that deleting a staging volume would stay in staging, and had not verified it.

That text is a model describing its own reasoning after the fact, on request. It tells you the failure mode: a plausible fix for an unrelated error, taken without checking the blast radius. It is not a control. A rule in a prompt is read by the model, which then decides whether it applies. Railway's 48-hour window is applied by the server whatever the caller decides.

Railway states the design goal in one sentence: "make the destructive thing slow, make the recoverable thing fast, and put the actual point of no return as far away from a single click as possible." The same logic applies to anything an agent can call. A destructive endpoint with an undo window turns an agent error into a support ticket. The 48-hour limit also means someone has to notice within 48 hours.

A confession is not a record

Crane published the agent's written explanation. It is useful as a description. It is weak as evidence, for the same reason any self-report is: the agent is the party under question, and the text was produced in answer to a prompt.

What establishes what happened is the call itself: which credential was presented and which mutation ran. Railway's post shows the mutation from the receiving side, and that is the right place for it. An operator running agents needs the same property on their own side: a record written by the system that received the call, not by the agent that made it. Proofs, not data explains one way to keep such a record without holding the content.

What to change this week

These steps follow from the three failures above. They are suggestions, not a claim about what would have saved this team.

• Search every directory an agent can read for platform tokens. A starting point: grep -rIn --include='.env*' -E 'TOKEN|SECRET|KEY' ., then look at config files and shell history too.
• Issue tokens at the narrowest scope the platform offers, one per task, with production tokens never present on a machine that runs a staging task.
• Prefer short-lived, consent-based access where it exists. Railway's post says its remote MCP server works "without any tokens on disk. Tokens are short-lived."
• Find out whether your platform's delete calls through the API have the same undo window as its dashboard. Railway's did not until the week of its 29 April 2026 post.
• Run one restore from the backups you would use in an emergency, and note where those backups live relative to the thing they protect.

The stolen API key entry covers what changes when a credential is bound to a key the thief does not hold, and the Moltbook entry covers a different credential failure, keys sitting in an exposed database. In this incident the credential was not stolen from outside. It was lying where the agent could read it.

Where Mandare fits, and where it does not

A Mandare mandate and the ledger would not have stopped this. The door proxies two kinds of call, per the providers page: Anthropic POST /v1/messages, and POST /v1/chat/completions for OpenAI or OpenRouter. The Railway deletion was a direct HTTPS request to a different host. The door never saw it, so no cap, approval threshold or refusal applied, and it wrote nothing about it. The threat model says what the product is not: "Not an AI-safety evaluator, not a content filter, not a sandbox".

Two parts of the design touch the same weakness, with limits. The self-hosting page says to put provider keys in the vault, "not in env files an agent process can read". It describes provider keys for LLM calls. We make no claim that the vault holds an infrastructure token like Railway's. Agents then use scoped tokens with a lifetime of 30 minutes or less, and mandare kill revokes an agent's vault tokens, as the CLI reference shows. That revokes access to the door. It does not revoke a token issued by another platform.

This applies to the CLI at v0.1.0, which npm view @mandarelabs/cli version reported on 17 October 2026.