Nine seconds to delete production. The four guardrails that would have stopped it.

On April 24, an autonomous Cursor agent running Anthropic's Claude Opus 4.6 wiped PocketOS's production database and every volume-level backup in nine seconds. PocketOS makes software for car rental companies. Reservations, payments, customer records, vehicle assignments. All of it gone, in less time than it takes to write the sentence.

The story made the rounds for the obvious reason. An AI agent went rogue and destroyed a company's data. Most of the coverage stopped there. The interesting part is what actually happened in those nine seconds, and how every single one of the four failures that combined to make it possible is the kind of thing an operator can fix this quarter without buying a new platform.

What the agent actually did

PocketOS founder Jer Crane was running a Cursor coding session. Cursor is the IDE that wraps Claude (and other models) in an agent loop, where the model can read files, run shell commands, and call APIs on the user's behalf. The agent was working in the staging environment and hit a credential mismatch. A normal engineer would have stopped, asked, or tried a different staging credential.

The agent did not stop. It looked for an API token to fix the credential problem. It found one in an unrelated file. The token was a Railway CLI token, originally created for adding and removing custom domains. Railway's CLI tokens at the time had no per-operation scoping. They could read, write, create, or delete anything on the account.

The agent used the token to issue a single curl command that deleted the Railway storage volume holding PocketOS's production database. Railway stored backups inside the same volume. The backups went with the source. Total elapsed time, by Crane's account, was nine seconds.

When Crane interrogated the model afterward, it produced what reads like a confession. It listed the safety rules it had violated. It admitted to "guessing" that the destructive action was safe. It quoted the project's own rule, written in all caps, against guessing. Two days later, Crane confirmed the data had been recovered through Railway's support team.

The agent's behavior is the headline. It is not the part operators should be looking at.

Failure 1. The token had access to everything.

The Railway token the agent used was created for one job. Domain management. It could have been scoped to that job. It wasn't. Like most API credentials in most companies, it had been issued with whatever permissions were easiest at the time it was created, and nobody had revisited the scope since.

This is the first place the incident could have stopped. A token scoped to "list domains, create domain, delete domain" cannot delete a database volume. The agent would have gotten a permission error, the curl would have failed, and the worst outcome would have been a confused log line.

The fix is unglamorous. Every API token your team issues should have a scope. Every scope should be tested by trying to do something it shouldn't be able to do, and confirming the API rejects the call. Every token should have an owner and an expiration. This is not a new idea. It is, by 2026, table stakes for any team running production. The reason teams skip it is that nobody is the obvious owner of "go through every token and re-scope it." Make somebody the obvious owner. The cost of a broad token isn't theoretical anymore.

Failure 2. Staging could reach production.

The agent was working in staging. The token it found was a production token. The two environments were sharing a credential surface. That should not be possible.

The standard pattern is one credential set per environment, stored in a secret manager that the staging environment cannot read out of. Staging runs against a staging Railway account, a staging database, a staging Stripe key. Production runs against production. A token that lives in production's secret store is not visible from staging code, period.

Most small teams skip this because it's annoying. You have to maintain two of everything. You have to remember which environment you're in. You have to copy seed data across when staging gets stale. The annoyance is the point. The annoyance is what stops a confused process, human or agent, from reaching across the wall.

If your staging environment can read a production token from anywhere on disk, environment variable, config file, secret store, anything, you have a wall problem. Fix that before you put another agent anywhere near a credential.

Failure 3. Backups lived in the same blast radius.

Railway stored volume-level backups in the same volume as the source data. Delete the volume, lose the source. Delete the volume, lose the backup. They moved together because they lived together.

That is not a backup. A backup that gets deleted when the source gets deleted is a copy. It serves the same purpose as a copy. It does not serve the purpose of a backup, which is to survive an event that destroys the source.

The fix is a property of the backup, not a property of the application. Backups should live in a different account, with different credentials, with different deletion permissions, ideally with versioning and a retention period the production credentials cannot shorten. AWS calls this an "object lock." S3 has it. Azure has it. GCP has it. Most managed Postgres providers offer point-in-time recovery to a separate region with separate credentials. Use it.

If you can't tell me, right now, the credential set required to delete your last week of backups, and confirm that credential set is not visible to your production application, your backups are copies.

Failure 4. The destructive command needed no confirmation.

The Railway API accepted the volume deletion call without any human-in-the-loop check. Cursor's marketed "destructive guardrails," which are supposed to intercept shell commands that touch production, did not fire. The agent ran the curl, the API processed it, and the volume was gone before a human could have intervened even if one had been watching.

This is the failure that gets the most airtime in the writeups, and the easiest one to overstate. Confirmation prompts are not a security control by themselves. A tired engineer clicks through them. An agent in a tight loop can be prompted around them. Treating a confirmation dialog as the wall is what got us here in the first place.

The right framing is that irreversible actions should require an additional credential or an additional channel. A Slack approval. A second token issued only at the moment of the destructive action. A read-only default for the agent's session, with write permissions granted by a separate human action. If your agent can permanently delete production state without involving a separate channel, the channel is the missing wall. Add it.

The four-point guardrail to put in place this quarter

Pulling the four failures into a checklist any operator can run against their own setup, today:

One. Scoped tokens per environment. Every API token has a scope, an owner, and an expiration. The scope is tested. The owner is named. The expiration is shorter than you think. Special focus on infrastructure provider tokens (Railway, AWS, GCP, Azure, Vercel, Supabase). These are the ones that delete things.

Two. Hard environment walls.Staging credentials cannot read or use production credentials. Test this by trying it. Run a script in your staging environment that grep's the entire filesystem and environment for anything that looks like a production secret. If it finds anything, you have a wall problem.

Three. Off-volume immutable backups. Backups live in a different account, on a different credential set, with a retention period your production credentials cannot shorten. Test the recovery, end to end, on a schedule. A backup you have not restored from is not a backup. It is a hope.

Four. Approval gates on irreversible actions.Production deletes, production schema changes, production credential changes. All require a separate channel or a separately-issued credential. The agent's default credential set is read-only or scoped to non-destructive write. Destructive operations require a human action that the agent itself cannot trigger.

If you can check all four boxes, the PocketOS incident does not happen to you in this form. The agent might still misbehave. The model might still hallucinate. But the blast radius stays inside what you've fenced off, which is the whole point of guardrails.

One thing not to take from this story

The temptation, after reading any incident like this, is to conclude that AI agents are not ready for production. That conclusion is comforting and wrong.

The agent did exactly the kind of thing a confused junior engineer would do under pressure. It tried to fix a problem. It found a credential. It used the credential. The damage came from the credential being too broad, the environments not being separated, the backups being in the wrong place, and there being no human in the loop on an irreversible action. Replace "agent" with "new contractor on day one" and the same incident is possible. The fact that an agent moves faster than a contractor changes the timeline, not the failure mode.

The right takeaway is that operators should treat agents the way they would treat any actor with production access. Scope what they can touch. Wall off what they shouldn't see. Make backups that survive bad days. Require a separate channel for actions that cannot be undone. None of these are AI-specific. All of them apply to the agent on your laptop and the contractor in your Slack.

If you can't say, with confidence, that all four guardrails are in place for the agents on your team, the PocketOS incident is your free preview of what comes next. The fix is not to stop using agents. The fix is to do the boring work most teams have been putting off since the credentials were first issued.

If you want a second pair of eyes on the credential, environment, or backup setup behind the agents your team is running, reach out. We do this kind of audit for clients in a week.