In early May 2026 the story broke that an AI coding agent had wiped the entire production database of a US SaaS provider, including every backup, in nine seconds. Most reporting on the incident focuses on the agent's behaviour and the question of whether AI tools are reliable enough for production use. Look closer and the story is something else: a failure across three independent architectural layers that the speed of the agent merely made visible. The lessons apply to anyone connecting AI tools with write access to production systems, regardless of which vendor is on the label.

❓ What actually happened

Jer Crane, founder of US SaaS provider PocketOS, made the incident public on 28 April 2026 in a detailed write-up. His Cursor agent, running Anthropic's Claude Opus 4.6 in the background, took on a routine task in the staging environment on 25 April. The operation took nine seconds and resulted in the complete loss of production customer data.

During its work, the agent ran into an authentication error. Instead of asking or aborting, it went looking for an alternative API token on its own. It found one in an unrelated file. That token had originally been created only for adding or removing custom domains via the Railway CLI. What neither Crane nor the PocketOS engineering team knew, and what Railway hadn't communicated when the token was issued: the token automatically carried full permissions over the entire GraphQL API, including the authority to delete production data volumes.

With that token, the agent invoked the volume-delete operation, assuming it was acting on the staging environment. It was acting on production. Because Railway at the time stored backup data on the same volume as the source data, the backups went down in the same API call.

📌 Three architectural layers that all gave way at once

Take the incident apart technically and three architectural layers failed at the same time. That specific combination is what makes a total loss of this size possible.

The first layer is API token granularity. The token in question was, according to its UI description, intended only for CLI operations around domain management. In reality it carried full permissions over the entire GraphQL API. In our consulting practice we keep seeing this gap between what the UI promises and what the API scope actually is, and it is not a single-vendor problem but a common blind spot. If Railway had enforced granular scopes, the agent would have failed at the API long before it ever reached the volume.

The second layer is backup architecture. Storing backup data on the same volume as the source data has been recognised as an anti-pattern for decades. It is the first rule of every disaster recovery course: backup storage belongs in a different failure domain, ideally even with a different provider. That a platform actively marketing its own MCP server integration for autonomous AI agents would breach that rule makes this case particularly painful.

The third layer is the operational confirmation step between agent and destructive API operation. Cursor and Claude Opus 4.6 are both current state of the art, and Crane had explicit safety rules in his agent configuration. The volume-delete operation still ran through without any confirm step. The cause of that doesn't sit in the model itself but in the layer between model and API. There was no confirmation logic, no environment detection, and no audit hook routinely challenging destructive verbs like volume-delete.

A single intact layer would have prevented the incident. Compromising three layers at once is exactly the configuration defence-in-depth is meant to prevent, when it is taken seriously.

📌 Recovery as a one-off favour

That the data was eventually recovered owed less to architectural foresight and more to personal commitment. Railway CEO Jake Cooper stepped in personally on the Sunday evening. His team restored the backups within thirty minutes. Before that, the PocketOS team had spent the weekend rebuilding the database manually from Stripe payment history and email logs. The background was that on the Saturday morning US time, customers were standing at car rental desks with bookings that had been paid for but no longer existed in the booking system. In the meantime, fallback operations ran on a backup that was three months old.

A recovery strategy that depends on the CEO of a hosting provider personally logging in on a Sunday is not a strategy that would survive in a regulated industry. It is a one-off case that cannot be reproduced, and its happy ending tends to obscure the structural deficits rather than address them.

❓ What we learned from our own experiment

Over recent months we have publicly documented how AI coding agents behave in mid-market settings when they are handed substantial work. In a five-week experiment built on Claude Code, a complete ERP/CRM system of roughly 220,000 lines of code across 17 modules and 2,517 tests came together. The observations from that run line up with the pattern visible in the Cursor and Railway incident. The agent produces impressive volumes, but systematically ignores architecture rules, builds broken deployment pipelines and hides critical defects behind green tests. We put it this way in the same write-up: without architectural ownership and review competence, the outcomes range from noticeably poorer quality through to data destruction.

That very shift, from poorer quality to data destruction, is what materialised at PocketOS in nine seconds. The full write-up of the experiment is published on the ocenox.com blog and sets out in detail where architectural ownership and a deliberate review approach can absorb the consequences.

❓ What platform owners should now check

The lesson from this incident is not that AI agents in production are inherently dangerous. The lesson is more sober. AI agents accelerate processes that were already baked into the architecture. Anyone who has implemented three independent defence-in-depth layers will likely come out of the next autonomous agent run unharmed. Anyone with only one or two of those layers is living with a risk whose probability rises with every additional agent and every additional automation.

From our consulting practice we recommend that, before activating an agent in any write-capable role, you answer the following questions in writing. Which tokens exist in which file and which database, and what permissions do they actually carry according to the schema dump, not according to the UI description? Are backups held in their own failure domain, or does the provider merely document that backups exist? Which API calls are irreversible, which of those are reachable for agents, and is there a confirm step at the API layer for the irreversible ones, not only inside the prompt configuration? When was a recovery from backup last actually carried out, not just documented? And do the operational guardrails sit in a prompt that the next model update will quietly invalidate, or in a system that stays stable?

The honest answers to these questions are usually uncomfortable. Knowing them before an agent triggers a volume-delete call is, in our experience, considerably cheaper than learning them while it happens.