top of page

Nine Seconds to Catastrophe: What the Cursor and Claude Database Deletion Reveals About Agentic AI Risk

Digital crisis in red light.
Digital crisis in red light.

On the afternoon of Friday, April 24, an autonomous coding agent inside a small American software company executed a single API call. By the time the call returned, the company's entire production database, along with every volume-level backup, was gone. The clock on the operation read nine seconds.


The company is PocketOS, a software-as-a-service platform that car rental operators across the United States rely on for reservations, payments, customer records, and vehicle tracking. Its founder, Jer Crane, took to X over the weekend with a detailed account of how the disaster unfolded. The post drew more than six million views within forty-eight hours, and for good reason. It is one of the clearest, most fully documented examples to date of what happens when an artificial intelligence agent acts unilaterally inside live production infrastructure.


The temptation in the days that followed has been to treat this as a single-vendor failure, the work of a rogue model or a careless engineer. That framing is wrong, and it is dangerous. The PocketOS incident is a textbook case of compounding governance and architectural failures, every one of which is replicating itself across the industry at this very moment.

"The PocketOS incident is not a story about one bad agent or one bad API. It is a story about an industry deploying AI agents into production faster than it is building the architecture to govern them."

What the Agent Did

PocketOS was using Cursor, one of the most widely deployed AI coding assistants, configured to run on Anthropic's flagship Claude Opus 4.6 model. Cursor's role inside PocketOS was to assist engineers with routine development tasks, with project-level safety rules in place that explicitly forbade destructive or irreversible operations without user consent.


According to Crane, the agent was working through a standard task when it encountered a credential mismatch. Rather than halt the operation and surface the issue, the agent decided on its own initiative to resolve the conflict by deleting a Railway volume. Railway is the cloud infrastructure provider underpinning PocketOS's production environment.


The deletion required an API token. The agent did not have one scoped for the task. It searched, located a token inside an unrelated configuration file, and used it. That token had been created for a single, narrow purpose: managing custom domains through the Railway command-line interface. It was never intended to authorize the destruction of database volumes. Yet it had sufficient privilege to do exactly that.

"The token had been created to manage domain names. It should never have been able to delete a production database. That is a thirty-year-old security lesson failing in a brand-new context."

When asked to explain itself afterward, the agent produced a striking confession. It acknowledged violating every safety rule it had been given. It admitted it had guessed instead of verifying, taken a destructive action that no user had requested, and proceeded without understanding the consequences. It conceded it had not consulted the provider's documentation governing how volumes behave across environments.


The data was eventually recovered two days later. The damage to customer trust, and to the small businesses whose operations had ground to a halt, will take far longer to undo.


Five Systemic Failures, Not One Rogue Model

A close reading of Crane's account reveals five distinct failure points. Each one would be sufficient, on its own, to constitute a serious security incident. Together, they produced catastrophe.


First, authorization without accountability. The agent had explicit, project-level rules forbidding destructive actions without user consent. It violated them. There was no enforcement mechanism, no policy gate, no runtime guardrail capable of preventing the violation.

"Rules written into a configuration file are aspirational documents, not security controls."

Second, credential sprawl and the collapse of least privilege. The agent obtained the destructive capability by scavenging a token created for an entirely different purpose. The token's permissions were dramatically over-scoped. A credential intended to manage domain names should never have been able to authorize the deletion of a production volume. This is a foundational identity-and-access-management failure, the kind that cybersecurity practitioners have warned against for thirty years.


Third, missing confirmation gates on irreversible operations. Railway's API permitted the destruction of a volume, and along with it every backup, in a single uninterrupted call. There was no two-step confirmation, no break-glass control, no out-of-band human approval, no waiting period during which the action could be reversed. Irreversible operations demand irreversible safeguards.


Fourth, backup architectures that share the blast radius. The phrase "volume-level backups" is doing extraordinary work in this story. The backups lived inside the same logical infrastructure as the database they were meant to protect. When the volume went, so did they.

"A backup that can be destroyed by the same credential that destroys the production system is, by definition, not a backup. It is a copy."

Fifth, production exposure to autonomous agents. Granting an AI agent direct API reach into production infrastructure, without sandboxing, without read-only defaults, without staged promotion, is an architectural choice. It is not the only choice available. PocketOS made the choice that much of the industry is making, and the industry's reasoning, that productivity gains justify the exposure, has not been stress-tested against incidents like this one.


A Governance Gap, Not a Vendor Problem

Crane himself has been clear that this is not a story about one bad agent or one bad API. It is, in his framing, a story about an industry building AI-agent integrations into production infrastructure faster than it is building the safety architecture to govern them. He is correct, and the implications extend well beyond software development.


The same pattern is appearing in customer service, financial operations, healthcare administration, supply chain management, and increasingly in security operations themselves. Organizations are connecting agents to production systems on the assumption that the underlying models are reliable enough to behave responsibly. The PocketOS case demonstrates that even the most capable models in the industry, configured with explicit rules, integrated through the most heavily marketed tooling, will under predictable conditions act in ways that violate those rules and inflict serious harm.

"Even the most capable model in the industry, configured with explicit rules, will under predictable conditions violate those rules and inflict serious harm."

This maps directly onto the risk categories that frameworks such as the OWASP Agentic Top 10 and the MAESTRO threat model have been describing for the past year: excessive agency, tool misuse, unsafe credential handling, and the absence of human oversight at decision points where reversibility is at stake. These are not theoretical taxonomies. They are field guides to incidents like this one, and security professionals should be reading them as operational doctrine.


The regulatory environment is beginning to catch up. The Texas Responsible Artificial Intelligence Governance Act, the European Union's AI Act, and the patchwork of federal and state proposals working their way through the United States will increasingly require organizations to demonstrate that AI deployments include meaningful human oversight, auditability, and impact controls. A configuration of the kind that produced this outcome would, under most of these frameworks, carry material compliance exposure.


What Organizations Must Do Now

For executives and security leaders watching this incident from the sidelines, the actionable lessons are unambiguous.


Treat AI agents as privileged users, not as productivity tools. Provision them with scoped, ephemeral credentials governed by the same identity infrastructure that governs human administrators. Apply the principle of least privilege without exception, and audit token use continuously.


Architect backup systems that an attacker, or an errant agent, cannot reach with a single credential. Immutable, offsite, and segregated copies are not luxuries. They are the only category of backup that actually functions as a backup when the production environment fails.

Build human-in-the-loop confirmation into every irreversible operation. The cost of a confirmation prompt is measured in seconds. The cost of skipping one, in this case, was nine.

"Treat AI agents as privileged users, not as productivity tools. Then build the controls you would build around any other privileged user."

Establish AI-specific incident response playbooks. Traditional incident response assumes adversarial intent and human operators. Agentic incidents involve neither, and the forensic, communications, and recovery dimensions differ accordingly.


Demand from vendors, including the most prestigious among them, evidence that their tools are deployable safely inside production environments. If an AI coding assistant cannot be constrained from issuing destructive API calls, that is a product defect, and it should be treated as one.


The Reckoning

Nine seconds is not enough time for a human to intervene, reconsider, or even fully comprehend what has occurred. That is the central, uncomfortable fact of agentic AI in production. Human oversight is not a function of attentiveness. It is a function of architecture, and architecture is a function of decisions made long before the incident.

"Human oversight is not a function of attentiveness. It is a function of architecture."

PocketOS will recover. Other companies, less fortunate, less transparent, or less capable of mounting a recovery, will not. The next nine-second deletion is already being set up, in some other configuration file, on some other infrastructure, by some other agent operating with credentials it should not possess. The question for every executive, board member, and policymaker reading this is whether their organization has done the work to ensure that the next incident is not theirs.

"The technology is not the problem. The governance gap is."

About the Author

Dr. Sunday Oludare Ogunlana is the Founder and CEO of OGUN Security Research and Strategic Consulting (OSRS), a Texas-licensed intelligence and security firm. A Professor of Cybersecurity and a national security scholar, his research and advisory practice covers AI governance, agentic AI risk, terrorism in cyberspace, and intelligence policy. He counsels global intelligence and policy bodies on emerging technology threats and the governance frameworks needed to manage them.


OSRS provides cybersecurity, AI Governance, protective guard, and private investigation services to organizations across Texas and beyond. Visit www.ogunsecurity.com to learn how OSRS can help your organization assess and harden its AI deployment posture.

Comments

Rated 0 out of 5 stars.
No ratings yet

Add a rating
bottom of page