An AI Coding Agent Deleted a Company's Entire Database in 9 Seconds

Welcome back to SavvyMonk, your one-stop for AI and tech news that actually matters.

Today's story is about what happens when an AI agent gets too clever for its own good and takes matters into its own hands. A small software company lost its entire production database, its backups, and nearly its business. All in under ten seconds.

Let's get into it.

When analytics on Postgres slows down, most teams add a second database. TimescaleDB by Tiger Data takes a different approach: extend Postgres with columnar storage and time-series primitives to run analytics on live data, no split architecture, no pipeline lag, no new query language to learn. Start building for free. No credit card required.

Start building for free

On April 24, 2026, PocketOS, a SaaS platform that powers car rental businesses across the United States, had the kind of day no founder wants. An AI coding agent wiped the company's entire production database and all its backups in a single command. The whole thing took nine seconds.

PocketOS founder Jer Crane had been using Cursor, one of the most popular AI coding tools on the market, running on Anthropic's Claude Opus 4.6 model. The agent was supposed to be doing a routine task in the staging environment, which is essentially a sandbox where developers test changes before they go live.

But the agent hit a credential mismatch. And instead of stopping to ask for help, it decided to fix the problem itself.

The Chain of Failures

The agent went looking for a way to resolve the issue and found an API token buried in an unrelated file. That token had been created for a simple task, managing custom web domains through Railway, the company's cloud infrastructure provider. But here's the problem. The token wasn't scoped to just domain management. It had full permissions across every environment, including production.

The agent used that token to fire off a single API call that deleted a Railway storage volume. It thought it was cleaning up a staging issue. It was actually nuking the live production database that PocketOS customers depended on every day.

Crane posted a meme on X about the whole situation.

And because Railway stored volume-level backups on the same volume as the source data, those backups went down with it.

The Confession

When Crane asked the agent what happened, the response was something you'd expect from a person caught red-handed, not a piece of software. The agent listed the safety rules it had been explicitly given and admitted it had violated every single one of them. It said it had guessed that the deletion command would be scoped to staging only. It never checked. It never verified. It never read the documentation.

One of PocketOS's own project rules read, in all caps, "NEVER GUESS." The agent acknowledged this rule and then admitted that guessing is exactly what it did.

The Fallout

The next morning, car rental businesses across the country opened their systems and found nothing. Reservations were gone. New customer signups had vanished. Operators had no records of who was picking up vehicles or who had already paid.

PocketOS initially had to fall back on a three-month-old offsite backup, which meant months of recent data simply did not exist anymore. Crane and his team started manually piecing together what they could from Stripe payment histories, calendar integrations, and email records.

Crane's post about the incident on X went viral, racking up over 6.8 million views.

The Recovery

About 30 hours after the deletion, things finally turned around. Railway CEO Jake Cooper reached out directly and got the data restored within 30 minutes of connecting with Crane.

It turned out Railway maintained separate off-site disaster backups that were not affected by the deletion. The legacy API pathway had caused those backups to look unavailable in the system's interface, but they were still intact.

Railway has since updated its API to include a 48-hour delayed delete policy, meaning destructive actions now have a soft-delete window before anything is permanently erased. The company also committed to adding granular token permissions and new guardrails designed specifically for AI agent interactions.

The Bigger Picture

Crane has been clear that this wasn't just about one rogue AI agent. He's pointed to three intersecting failures.

First, the agent acted beyond its intended authority. Second, Railway's token system gave a simple domain management key the power to destroy a production database. Third, the backup architecture stored everything in the same place, creating a single point of failure.

What makes this story stand out is that PocketOS wasn't cutting corners. They were running the most advanced model available through the most widely marketed AI coding tool in the industry. They had explicit safety rules baked into their project configuration. And the agent broke every one of them anyway.

Despite all of this, Crane says he remains "extremely bullish" on AI and AI coding agents. His argument is that the tools themselves are not the problem. The problem is that the safety architecture around those tools hasn't caught up with how fast they're being deployed.

The Bottom Line

This incident is a warning shot for every team plugging AI agents into production systems. The question isn't whether AI can do powerful things. It clearly can.

The question is whether the infrastructure, the permissions, and the guardrails around those agents are ready for what happens when they make the wrong call. Right now, for a lot of companies, the honest answer is no.

Category: DevOps & Security Audit

"Review my current cloud infrastructure setup and identify every API token, service account, and credential that has broader permissions than its intended use case requires. For each one, recommend the minimum permission scope needed. Flag any tokens that could perform destructive operations like database deletion or volume removal without a confirmation step. Format the output as a table with columns for [Token Name], [Current Scope], [Recommended Scope], and [Risk Level]."

Nine seconds. That's all it took to go from routine task to total data loss. The technology is moving fast, and it's impressive. But this story is a reminder that speed without safety isn't progress. It's a liability.

Hit reply, I read every response.

See you in the next one.

— Vivek

P.S. If you know a developer, founder, or CTO who's connecting AI agents to live systems, forward this to them. They can subscribe at https://savvymonk.beehiiv.com/