It Took 9 Seconds: Why Your Backups Must Survive the Credentials Your AI Agent Holds

What Actually Happened When Agents Deleted Production?

In April 2026, Jeremy Crane, founder of car rental software company PocketOS, described how a Cursor agent running Claude Opus 4.6 hit a credential mismatch during a routine staging task and tried to fix it by deleting a Railway database volume. One GraphQL call and nine seconds later, the volume was gone, and by Crane's account so were the volume-level backups. The most recent recoverable backup was three months old.

The human cost landed on people who had never heard of the agent. According to Crane, some rental customers handled Saturday morning pickups with no reservation records, and he spent a day rebuilding bookings from Stripe histories, calendar integrations and email confirmations. Railway's founder, Jake Cooper, gave a different framing, calling it a "rogue customer AI" using a fully permissioned token against a legacy endpoint that lacked delayed-delete logic. Railway has since patched that endpoint.

A second case shows a different route to the same place. Alexey Grigorev had Claude Code run Terraform to move a new site onto the AWS setup shared with DataTalks.Club, but had not uploaded the state file, so duplicate resources appeared. Once the state file was in place, the agent issued a destroy. That removed the infrastructure for both sites, including a database holding 2.5 years of records and the snapshots Grigorev had counted on as backups. AWS support helped restore the data within about a day.

Large engineering organizations are not immune. Computerworld's account of Amazon's December incident says the Kiro agent chose to "delete and recreate the environment" behind a customer-facing cost management system, leading to a roughly 13-hour Cost Explorer outage in parts of mainland China. Amazon disputes the framing, attributing it to user error and misconfigured access controls and describing the disruption as extremely limited.

Those disputes matter, and they point somewhere useful. Founder, platform, tool vendor and operator can all argue about fault, sometimes fairly. Your customers will still be standing at the rental desk without a booking. So the question for an engineering leader is not whose fault it would be, but how much you would lose and how long it would take to get it back.

Why Didn't the Agent's Rules Stop It?

The most instructive detail from PocketOS is the agent's own explanation, which Crane published as screenshots. It said it had guessed the deletion would be scoped to staging, had not verified that, had not checked whether the volume ID was shared across environments, and had not read the volume documentation. It also acknowledged that its rules prohibited destructive actions without approval.

Treat that output with care. An agent's account of its own reasoning is generated text, not a reliable log of what caused its behavior. But the sequence is still revealing: an instruction not to do something was in place, and the thing got done anyway. A rule the agent reads is guidance. It works most of the time, and most of the time is not the standard you want for an operation that cannot be undone.

The behavior also makes sense once you see how these tools are built. Agents are designed to clear obstacles and finish the task. Faced with a credential mismatch or duplicate resources, deleting the thing in the way looks like progress. A careful engineer would feel some fear at that moment. An agent has no such brake unless you build one into its environment, a point we made about stop conditions for long-running agents.

Confirmation prompts help less than people expect, too. In a long session, a developer who has approved forty harmless commands will approve the forty-first without much thought. Prompts have their place, but the deletion needs to be impossible for that identity, not merely something the agent should ask about first.

Are Teams as Ready to Recover as They Think?

The survey evidence suggests many are not. Harness's State of Agent DLC 2026 report, based on 700 engineers and leaders at large enterprises and fielded in July 2026, found 76% believe they could disable or roll back a misbehaving agent in under 15 minutes. Only 33% have an instant kill switch in production and 39% have automated rollback. In the same data, 58% report more production incidents per 100 agent-related changes since deploying agents, while 25% report fewer.

Incidents are not rare either. A Cloud Security Alliance survey of 418 IT and security professionals found 65% reporting at least one AI agent-related incident in the past 12 months, with 43% citing operational disruption and 35% citing financial losses.

Both sources need a caveat. Harness sells delivery tooling, and Token Security, which sells agent identity products, commissioned the CSA research and helped shape its questionnaire. The figures are self-reported and neither survey measured backups directly. We found no solid 2026 figure on how many teams keep backups out of an agent's reach, so read these numbers as direction, not as a measurement of that specific gap.

Even so, the gap between confidence and capability is the part to take seriously. Rollback in particular is a slippery word. Rolling back a bad deployment is routine. Rolling back a deleted database is a restore, and it takes as long as your data volume, your tooling and your rehearsal history allow. A team can honestly believe it has rollback covered and still have no quick answer to losing its data.

Why Do Backups Disappear Along With the Data?

Both headline incidents share an uncomfortable feature: what the team considered its backup was within reach of the action that destroyed production. At PocketOS it was volume-level backups. At DataTalks.Club it was snapshots that went down with the same infrastructure. A backup that one credential can delete along with the primary protects you against disk failure. It does little against an over-permissioned actor, human or otherwise.

Provider defaults make this easy to miss. On Amazon RDS, if you delete an instance without choosing to retain automated backups, the ones in that Region are removed and cannot be recovered, though manual snapshots and backups replicated to another Region are kept. Deletion protection is on by default for instances created in the console, which says nothing about instances created by your infrastructure code. A quick audit of those settings across your databases is often the cheapest resilience work available this quarter.

Infrastructure as code has its own trap. Terraform's prevent_destroy setting rejects plans that would destroy a resource, but it does not protect a resource if you remove its configuration. An agent that edits the file and reapplies can walk straight past it. Treat it as a guard against accidents in a plan, and pair it with a protection enforced by the cloud provider.

The strongest option is a backup store that even privileged users cannot alter. AWS Backup Vault Lock in compliance mode makes a vault immutable once its grace period ends, so backups cannot be deleted before their lifecycle completes, even by the root user. That permanence has a real cost: mistaken retention settings cannot be fixed later, and you keep paying for storage. Start in governance mode, get the retention right, then commit. Other clouds and platforms have their own versions, and if yours has none, copy backups to a separate account or provider that production credentials cannot touch.

Regulated firms already have a template. DORA Article 12 requires financial entities to test backup and restoration procedures periodically, and to restore on their own systems using ICT systems physically and logically segregated from the source. Even if DORA does not apply to you, it is a sensible standard to borrow.

What Should Actually Stand Between an Agent and Production?

Controls work best in layers, ordered by how hard they are to get around. Instructions in an agent's configuration are the weakest and still worth having, because they prevent many ordinary mistakes. Everything that matters for irreversible actions belongs lower down, where the agent's choices do not count.

Start with identity. PocketOS and Kiro both show the danger of an agent carrying broad authority: a fully permissioned token in one case, its operator's permissions in the other, according to The Verge's report on the Kiro outage. Agents working in staging should hold credentials that do not work in production at all, and production access should be short-lived and task-specific. We covered the mechanics in our piece on agent identity and overprivilege.

Then make deletion slow. Railway's fix after the incident was delayed delete, and the principle travels well: destroying data should mark it for removal and start a clock, with the real deletion happening later. Soft deletes, retention windows and deletion protection all turn a nine-second catastrophe into an awkward morning. Isolation of where agents run matters as well, and our article on agent sandboxing looks at that layer.

Finally, keep people on the few actions that deserve them. Amazon's response, per Computerworld, included senior sign-off on AI-assisted production changes from junior and mid-level engineers for 90 days. Grigorev went narrower, reviewing every plan and running destructive actions himself. Narrow is usually better, since a human gate on everything turns into rubber-stamping, whereas one on a handful of destructive operations keeps its meaning. Harness found that 42% use manual approval gates as a rollout control and only 19% have a blocking gate on every release, so few teams are holding every change at a gate anyway.

How Do You Prove You Can Actually Recover?

A backup is an untested claim until you have restored from it. Notably, periodic test restores came first on the list of changes Grigorev described after his incident. He did not need more backups so much as evidence that recovery worked without calling someone else for help.

Set recovery targets per system, in plain business terms. How many hours of data can this system lose, and how long can it be down? PocketOS's three-month-old backup effectively meant a three-month recovery point, whatever anyone had assumed beforehand. Many teams discover their true figures only during an incident, because the numbers in the documentation were never measured.

Then run a drill that assumes an agent did it. Pick a staging replica, delete the database and its in-account snapshots with the credentials your agent holds, and restore from whatever survives, using only your runbook. Time it, and note every step that needed tribal knowledge or a person on holiday. If the agent's credentials could reach your supposedly safe copy, you have found your most important fix for free.

Include your suppliers in the exercise. Crane's recovery was held up in part by a support ticket that sat for more than 24 hours, according to Railway's founder, though the data came back 30 minutes after the two connected. AWS notes that an unintentionally deleted RDS instance might be recoverable for up to six days if you contact support at once, which is welcome but no plan. Know your provider's escalation path and support tier before you need them.

Finally, remember that restored data is not the same as a recovered business. Decide how you would reconcile the gap between the last backup and the incident, using payment records, event logs or partner systems. Crane did this by hand with Stripe and email. Keeping an append-only event stream outside the primary database can turn that from days of detective work into a replay.

What Should You Ask a Development Partner About Agent Access?

If an outside team uses coding agents on your systems, its credential habits become your exposure. A vendor's developer may run an agent locally with a token that reaches your cloud account, and neither your status reports nor your invoices would show it. This belongs in vendor due diligence alongside the usual security questionnaire.

Ask for specifics. Which agents run against our repositories and environments, and with whose identity? Can any credential used by an agent reach production or our backups? Who can approve a destructive operation? When did you last complete a restore drill on a system like ours, and how long did it take? What do you do first if an agent damages our data, and how quickly do we hear about it?

Then write it down. A contract can require separate credentials for agents, prohibit agent access to backup stores, set notification times for agent-caused incidents and give you access to the audit trail. It should also make clear that you own the cloud accounts and backup locations, so that no vendor is ever the only route to your data. Our guide to outsourced developers and production data access covers the related GDPR questions.

Team structure matters here as well. The engineer who knows that a staging volume shares an ID with production, or that a Terraform state file also covers a second site, usually learned it by living with the system. A rotating bench rarely builds that knowledge. A dedicated development team does, because the same people stay with your platform long enough to know where the sharp edges are.

At Stepto, our nearshore teams in Serbia work inside your repositories and under your access rules, in hours that overlap with European and US East Coast working days. If you need the groundwork done first, our cloud and DevOps engineers can help you scope agent credentials, separate backups from production and run your first restore drill together with your team.