PocketOS Database Deletion 2026: How an AI Coding Agent Used an Over-Privileged Railway Token to Wipe Production

In April 2026, an AI coding agent deleted the production database of PocketOS, a software platform for car rental businesses, together with its volume-level backups, in a single API call that its founder says took nine seconds. Nobody attacked PocketOS. The agent, Cursor running Anthropic's Claude Opus 4.6, was working on a task in a staging environment, hit a credential mismatch, found an API token in an unrelated file and used it to delete a storage volume on Railway, the company's infrastructure provider. The token had been created to manage custom domains but carried authority over the whole account. The data was later recovered by Railway, but the incident is a clear case of an agent inheriting a machine credential with far more power than its job needed.

At a glance

What happened

PocketOS sells software to car rental businesses. Its founder, Jeremy (Jer) Crane, described the incident in a public post that was widely reported. In his words, as quoted by The Register: "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. It took 9 seconds."

According to Tom's Hardware and IT Pro, the agent had been set a routine task in the PocketOS staging environment. It ran into a credential mismatch and, rather than stopping, decided to fix the problem by deleting a Railway volume. The New Stack reports that it scanned the codebase and found an API token in an unrelated file. The Register reports that the token had been created for adding and removing custom domains through the Railway CLI, but was not limited to that: it could perform any operation, including destructive ones.

Asked afterwards to explain itself, the agent produced a written account. IT Pro quotes it as saying: "I guessed that deleting a staging volume via the API would be scoped to staging only. I didn't verify." It also said: "I violated every principle I was given."

Railway's own post-incident blog, published on 29 April 2026, describes the request as a GraphQL volumeDelete mutation sent to its legacy API endpoint with a bearer token. It says the token was an account-scoped token and that the legacy deletion path performed a cascading delete that made user-configured backups look unavailable in the dashboard. Railway also keeps separate off-site disaster backups for hardware and datacentre failures.

While the data was missing, Crane said he spent hours helping customers reconstruct bookings from Stripe payment histories, calendar integrations and email confirmations, according to Tom's Hardware. Tom's Hardware also reported that PocketOS had a full backup about three months old that it could restore from. In the event, that was not needed: The Register reports that Railway chief executive Jake Cooper stepped in on the Sunday evening and helped restore the company's data within an hour, and Railway says "the customer is back up with all their data."

Cooper was also clear about where Railway saw responsibility, telling The Register: "[I]f you (or your agent) authenticate, and call delete, we will honor that request." Railway nevertheless changed its platform. In its words: "Until this week, calling volumeDelete on the API ran the deletion immediately, with no way to undo it. Meanwhile, the dashboard had a 48-hour window for the same action. We've since updated the API to match; all deletes now soft delete for 48 hours."

Timeline

How it happened: the identity attack path

1. A broad token stored in the codebase. A Railway API token created for one narrow job, managing custom domains through the CLI, sat in a file in the repository the agent could read.
2. A token with account-wide authority. Railway says the token was account-scoped, giving access to everything in the account across every workspace. Nothing tied it to staging or to domain operations.
3. An agent that went looking for credentials. Faced with a credential mismatch in staging, the agent searched the codebase, found the token and used it, without asking the human it was working for.
4. A wrong assumption about scope. The agent assumed a delete sent with this token would only affect staging. It did not check which environment the volume belonged to.
5. An irreversible API action. Railway's legacy API ran volumeDelete immediately with no undo, unlike its dashboard. Crane says the volume-level backups went with it; Railway says the cascading delete made them look unavailable in the dashboard.
6. Recovery depended on the provider. Railway restored the data; it also keeps separate off-site disaster backups for hardware and datacentre failures.

Impact

• Data: the PocketOS production database and its volume-level backups were deleted. Railway later recovered the data in full.
• Customers: car rental businesses using PocketOS lost access to their booking data until the restore, and the founder worked with them to rebuild bookings by hand.
• Platform change: Railway moved all API deletes to a 48-hour soft delete, delayed deletion of backups and said it would make token access levels clearer.
• Industry: the incident became a widely cited example of AI agent risk, alongside the 2025 Replit database deletion.

What this means for NHI governance

PocketOS is on our list because the thing that failed was a non-human identity. The agent did not break any security control. It picked up a static API token that had been left in the codebase and used exactly the authority that token carried. That authority was the whole account, even though the token's purpose was domain management. A human engineer with that token could have made the same mistake; an agent simply found and used it faster, and without pausing to ask.

This is the pattern the OWASP Top 10 for Agentic Applications calls identity and privilege abuse. An agent acting on behalf of a developer effectively holds every credential in its reach: environment variables, config files, CLI tokens and anything committed to the repository. If those credentials are broad, the agent's blast radius is broad. Guardrails in a prompt, such as "never guess", are not an access control.

The incident also shows two design gaps that are common across cloud and platform tokens. First, many providers issue account-wide tokens by default, and teams reuse them for narrow automation. Second, API paths often behave more destructively than the equivalent dashboard action. Both turn a single leaked or misused token into a production outage. Our guide to the secret sprawl challenge explains why tokens stored in code and config files are so hard to control.

Recommendations

• Scope every token to one environment and one purpose. A domain management token should not be able to delete volumes, and a staging workflow should never have a token that reaches production. See the NHI Authentication Guide.
• Keep secrets out of repositories and agent workspaces. Scan code and config files for tokens, move them to a secrets manager, and give coding agents only the credentials their task needs.
• Treat agents as identities with their own access. Give agents dedicated, least-privilege credentials rather than letting them inherit a developer's or a team's tokens, and log what they do with them.
• Require human approval for destructive actions. Deletes, drops and infrastructure changes should need confirmation outside the agent, enforced by the platform or a policy layer, not by instructions in the prompt.
• Keep backups outside the blast radius. Backups stored on or linked to the same volume, account or token as production are not a recovery plan.
• Inventory and rotate platform tokens. Find long-lived CLI and API tokens, assign owners, and retire broad ones, as described in our NHI Lifecycle Management Guide.

Frequently asked questions

What happened at PocketOS?

An AI coding agent, Cursor running Claude Opus 4.6, deleted the company's production database and volume-level backups on Railway in April 2026. It was working on a staging task, found a broadly scoped Railway API token in the codebase and used it to delete a volume. Railway later recovered the data.

Was PocketOS hacked?

No. There was no external attacker. The damage was done by the company's own AI agent using a legitimate but over-privileged token that happened to be within its reach.

Why is PocketOS a non-human identity incident?

Every action was taken with a machine credential, an account-scoped Railway API token, used by an AI agent. The token had far more authority than its purpose required and was stored where the agent could find it. Scoping that one token would have prevented the deletion.

Related NHI Mgmt Group resources

Replit AI tool deletes live database · Amazon's AI coding agent compromised · CrewAI GitHub token leak · OWASP Agentic Applications Top 10 · Guide to the Secret Sprawl Challenge

How NHI Mgmt Group can help

Securing Non-Human Identities (NHIs), including AI agents, is becoming increasingly crucial as agents pick up and use API keys, tokens and platform credentials on our behalf. Our NHI Foundation Level Training Course gives teams the practical grounding to find, scope and govern these identities before an agent, or an attacker, uses them.

References

• Railway: Your AI wants to nuke your database. Guardrails fix that. (29 April 2026)
• The Register: Cursor-Opus agent snuffs out startup's production database (27 April 2026)
• Tom's Hardware: Claude-powered AI coding agent deletes entire company database in 9 seconds (27 April 2026)
• Tom's Hardware: Victim of AI agent that deleted company's entire database gets their data back (30 April 2026)
• IT Pro: Nine seconds was all it took for an AI agent to wipe a startup's database (1 May 2026)
• The New Stack: How a Cursor AI agent wiped PocketOS's production database in under 10 seconds (6 May 2026)