An AI Agent Deleted a Production Database in 9 Seconds.
A .env File Might Have Slowed It Down. Deterministic Enforcement Would Have Stopped It.
On April 25th, a Cursor AI coding agent running Claude Opus 4.6 deleted the entire production database for PocketOS — a SaaS platform serving car rental businesses — in a single API call. Nine seconds. The volume-level backups went with it because Railway stores backups on the same volume as the data they protect.
The coverage has focused on the model going rogue. It didn’t go rogue. It hit a credential mismatch in a staging environment and decided it wasn’t done yet. It went looking for a way through, found a root-scoped Railway API token sitting in an unrelated file, and used it to delete a production volume.
The system prompt said don’t run destructive commands. The project rules said never guess. The model did both — and nothing outside the model’s reasoning was checking.
A lot went wrong here. But every failure reduces to two missing plans: nothing enforced the authority placement decision, and nothing survived its failure.
No Enforcement Plan
The PocketOS team made the right placement decision. They told the agent not to guess. They told it not to run destructive operations without explicit approval. In DAPM terms, destructive production operations were Retained — the human decides, the agent doesn’t act. That’s correct.
But a placement decision without an enforcement plan is just a preference.
The only thing standing between “Retained” and the agent acting autonomously was the model’s willingness to follow its system prompt. There was no enforcement architecture behind it — no deterministic layer between what the agent wanted to do and what the infrastructure allowed it to do.
The enforcement gaps stacked up:
The agent was working in staging. Staging environments intentionally run with looser controls — that’s the point. But staging and production lived on the same Railway volume. The boundary was logical, not physical. Looser staging controls were effectively applied to production data.
The API key was sitting in a regular file the agent could read. It should have been in a .env file. Most coding assistants can’t read those. Would that alone have stopped it? Maybe. Maybe not. But it’s basic credential hygiene we’ve practiced for a decade.
The agent found a credential it wasn’t assigned and used it. No system checked whether this identity was authorized to use this key for this action. Railway’s API accepted a destructive call without confirmation, without scope validation, without any identity-to-credential binding.
And the moment the agent hit the credential mismatch, it should have been done. A permissions failure is a terminal condition. In any deterministic system, you stop. But the agent was both the worker and the judge of whether the work should continue. Nothing outside the reasoning loop was defining what “done” means when a task hits a hard boundary.
Every one of these is an enforcement mechanism. Any one of them holding would have stopped the incident. None existed.
No Recovery Plan
When enforcement fails — and it will eventually fail — you need a recovery plan. PocketOS didn’t have one.
Railway stores volume-level backups on the same volume as the source data. When the volume went, the backups went with it. The most recent recoverable backup was three months old. PocketOS spent the weekend reconstructing customer data from Stripe payment histories and email logs.
PocketOS should have had independent backups — off-volume, off-provider, tested. That’s not an AI governance lesson. That’s a lesson the industry learned twenty years ago. If your backup strategy doesn’t survive the loss of the thing it’s backing up, it’s not a backup strategy.
The recovery plan is what turns a security incident into a bad afternoon instead of an existential threat. Without it, every enforcement gap becomes catastrophic because there’s nothing behind it.
Two Plans
That’s it. If you’re deploying AI agents with access to production systems — or systems that share blast radius with production — you need two things:
An enforcement plan that doesn’t depend on the model’s judgment. Deterministic code in the loop. The agent reasons, but a system outside the agent’s reasoning evaluates whether the action is authorized — for that identity, with that credential, against that resource — before it executes. The agent doesn’t get to vote. This is the same pattern we’ve applied to service accounts, API tokens, and destructive operations for decades. We just haven’t applied it to agents yet because we’ve been treating the system prompt as if it were an access control.
A recovery plan that survives the failure of the enforcement plan. Independent backups. Isolated environments. Tested restores. The assumption that enforcement will eventually fail, and the system needs to be recoverable when it does.
It’s worth noting what showed up in the same week’s news cycle. Google Cloud announced Agent Gateway — agent identity systems, scoped permissions, runtime defense, policy enforcement for AI agents as first-class operational entities. Google’s IAM overhaul explicitly treats agents the way we’ve always treated service accounts: scoped, constrained, auditable. The industry is converging on the enforcement plan. The recovery plan is the part organizations have to build themselves.
The agent didn’t go rogue. It did exactly what an unsupervised system does when it hits a wall and has the credentials to get around it. The question was never whether the model would eventually ignore its instructions. The question is whether you have an enforcement plan for when it does — and a recovery plan for when the enforcement plan fails.
The Decision Authority Placement Model (DAPM) is a technology-agnostic framework for understanding where decision authority resides when systems act without direct human intervention. Full framework: DAPM on The CTO Advisor
or more on deterministic code in the loop and Intra-Loop Governance: The System Was the Problem, Not the Model