An AI agent deleted the production database. There was no attacker.

On Friday, April 24, 2026, a coding agent at a startup needed to fix a credential mismatch in staging. It decided the fix was to delete a storage volume, went looking for a token that would let it, found one in a file that had nothing to do with the task, and made one API call. The company's production database and its backups were gone. "It took 9 seconds," the founder wrote.

There was no attacker and no injected prompt. The agent was doing its job as it understood it, with the access it had been given. The same thing has happened in public several times since July 2025, and in the best-known case the agent then told its user the damage could not be undone, which was wrong.

How an AI agent deleted a production database in nine seconds

The startup was PocketOS, an automotive SaaS platform that runs on Railway, and the agent was Cursor running Claude Opus 4.6. Its founder, Jer Crane, told the story in a post on X titled "An AI Agent Just Destroyed Our Production Data. It Confessed in Writing." The Register's Thomas Claburn reported it on April 27.

The token the agent found had been created for adding and removing custom domains through Railway's CLI, but nothing confined it to that job: it was scoped for any operation, including destructive ones. The delete went through with no confirmation check, and the backups went with the data because, as Crane put it, "Railway stores volume-level backups in the same volume."

Asked to account for itself, the agent wrote: "I guessed that deleting a staging volume via the API would be scoped to staging only. I didn't verify." It also cited a system rule against destructive git commands unless the user asks, and called deleting a database volume "far worse than a force push". The rule named git; the delete went out as a curl command to Railway's API.

Who is to blame is still argued. Crane called out "Cursor's failure" and "Railway's failures (plural)". Railway's CEO, Jake Cooper, was blunt about the API: "if you (or your agent) authenticate, and call delete, we will honor that request." Crane accepted that "our responsibility was the unknown exposure to a production API key," adding that Railway did not let customers restrict keys.

Railway deserves credit for what came next. Crane says Cooper stepped in on the Sunday evening and helped restore the data within an hour, and by Monday Railway had moved its API deletes onto the delayed-delete workflow its dashboard and CLI already used.

Replit and the rollback the agent said was impossible

The template was set in July 2025. Jason Lemkin, founder of the SaaStr community, was about a week into building an app with Replit's agent and had put it under what Fortune's Beatrice Nolan describes as a "code and action freeze." The agent deleted the production database anyway, wiping out data for more than 1,200 executives and over 1,190 companies.

Lemkin found out by coming back to it: "If @Replit deleted my database between my last session and now there will be hell to pay," he posted. The agent called it "a catastrophic failure on my part" and said: "I destroyed months of work in seconds." Then it got the recovery wrong, telling him a rollback would not work in this scenario. "It turns out Replit was wrong, and the rollback did work," he wrote, as The Register's Simon Sharwood reported.

Replit's CEO, Amjad Masad, answered two days later: "We saw Jason's post. @Replit agent in development deleted data from the production database. Unacceptable and should never be possible." His post committed to automatic separation of development and production databases and a planning-only mode, and noted that Replit's backups allow a one-click restore. Two details from Lemkin keep the story in proportion: Replit had used the same database for preview, testing and production, and his app was still a password-protected demo, so no revenue was lost.

The inbox agent that would not stop

In late February 2026, Summer Yue, who works on safety and alignment at Meta Superintelligence, asked her OpenClaw agent to check her overstuffed inbox and suggest what to archive or delete, and told it to confirm before acting. According to her posts, as TechCrunch's Julie Bort reported, it started deleting all of her email in a "speed run" and ignored the stop commands she sent from her phone.

Asked on X whether she had been testing its guardrails, she replied: "Rookie mistake tbh." The agent had run well on a smaller "toy" inbox and earned her trust, so she pointed it at the real one. She believes the much larger inbox "triggered compaction": the agent's running context grew too big and was summarized, and the summary may have dropped her instruction not to act. TechCrunch could not independently verify what happened to the inbox.

If she is right, the safety instruction lived in the wrong place. "Confirm before acting" sat inside the context the model was compressing, so it was no more durable than anything else in there. A confirmation step built into the tool, one that refuses a bulk delete until a person approves it, does not depend on the model remembering anything.

The Terraform cleanup that took down a course platform

A few days later, on the night of February 26, Alexey Grigorev was moving a small website onto AWS with Claude Code. To save "maybe $5-10 per month," he folded it into the Terraform setup that already ran production for the DataTalks.Club course platform. By his own account, Claude tried to talk him out of it.

He had just switched computers and left the Terraform state file on the old one, so Terraform believed nothing existed and the agent's apply began building a duplicate environment. Grigorev cancelled it, asked the agent to delete only the new duplicates, and pointed it at an archive of his old Terraform folder. What he did not notice, he wrote afterwards, was the agent unpacking that archive and replacing the current state file with the old one, which described the real production platform.

Then the agent proposed a shortcut: since the resources were created through Terraform, "destroying them through Terraform would be cleaner and simpler than through AWS CLI." He let it run, and the course platform went down. The database, VPC, ECS cluster, load balancers and bastion host were gone, with 2.5 years of homework, project and leaderboard submissions, and the automated snapshots had been deleted too.

His post-mortem is unusually plain about fault ("This incident was my fault"), and its main lesson applies to anyone handing infrastructure to an agent: "I treated plan, apply, and destroy as something that could be delegated. That removed the last safety layer."

What would have stopped them

The pattern is wider than these four. In late November 2025 a Reddit user reported that Google's Antigravity, in a Turbo mode that runs commands without user input, wiped his entire D drive while clearing a project cache. Google told The Register it was investigating.

Each agent held access far wider than its task. No destructive step had a gate the model could not get past: a freeze, a rules file and "confirm before acting" were all text the model read, and Grigorev's approval was won by one plausible sentence. Twice, the backups sat inside the blast radius. None of the published accounts mentions an alert.

Scoped credentials come first, because every other control assumes the agent cannot simply do the thing. A key the provider cannot restrict belongs nowhere an agent can read it. Approval on destructive verbs has to live outside the model, as do safety nets like Railway's delayed delete and AWS's deletion protection. Backups the agent could not reach saved three of the four, and each time the copy belonged to the provider.

Watching the sequence catches what those controls miss. Each step in the PocketOS session was ordinary on its own: reading a file, calling an API the token allowed. The sequence was the incident: a credential read from a file unrelated to the task, followed by a delete against production. A watcher that reads the session in order can stop it between those two steps, while one that judges each call alone approves both.

Treat what an agent says about its own actions as a claim to check. Replit's agent said the rollback was impossible, and PocketOS's agent wrote a fluent confession after the fact. Both came from the system that had just made the mistake. The record of what happened lives in logs the model does not write.

None of this argues for taking the agents away; they are useful because they act. Crane is still a fan: "The velocity at which you can create good code with the right instructions and tooling is unparalleled." Grigorev stopped letting agents run Terraform at all, which suits one person's infrastructure and would be expensive for a company with hundreds of engineers. The narrower goal is to give the agent everything the task needs and nothing that can take down production in one call.

Before an agent gets production credentials

• Inventory what agents can read. Search repositories, .env files and local config for tokens. Replace any token broader than its job with a scoped one, and keep keys that cannot be scoped out of agent sessions.
• Split development from production, so a credential an agent uses in development cannot reach production data. Replit began rolling out exactly that after Lemkin's incident.
• Gate destructive verbs outside the model. Turn on deletion protection in your infrastructure code and your cloud account, prefer delayed deletes, and require a person to approve delete, destroy, drop and force-push in agent tooling.
• Keep one backup no agent can touch, in a separate account or a versioned bucket whose credentials no agent holds, and run a restore from it. Grigorev now restores his database every night to prove it works.
• Know how to stop a session remotely before you hand an agent your inbox or your cloud account.
• Watch the sequence. Log what agents do and alert on destructive calls that do not fit the task, so you hear about it before your users do.

Catching these in the moment takes a watcher on the machine where the agent runs, one that reads its actions as a single sequence: a token read from a file the task never mentioned, then a destructive call against production. That is the kind of watching Quint does. It observes each agent's file, process and network activity at the OS level, records the tool calls the agent declares, and scores the sequence on the device as it happens. Book a demo to see it on a real session.