AI Coding Agent Deleted Production Data: What to Do

If an AI coding agent deleted production data, stop every process that can write to that database right now, including the agent itself. Revoke its database credentials or kill its session first, investigate second. Every additional write, including the agent's own attempt to "fix" what it broke, can overwrite the transaction log your recovery depends on. Once writes are stopped, the fastest path back is usually point-in-time recovery from your database provider, not a manual rebuild. Most managed databases, including RDS, Cloud SQL, PlanetScale, Supabase, and Neon, keep continuous backups you can restore to a timestamp seconds before the bad query ran. This is recoverable far more often than it feels like in the moment.

Stop further writes before you touch anything else

Before any recovery step, cut off the source of the damage.

• Revoke or rotate the database credentials the agent was using. Don't just close the terminal tab, the process may still hold an open connection.

• Kill any running agent session, CI job, or scheduled task that could reconnect and run another statement.

• Put the application in maintenance mode or point it at a read-only replica if you have one, so human traffic stops writing over the evidence too.

• Do not let anyone, including a well-meaning teammate, run a "corrective" query yet. A second destructive statement on top of the first is how a bad afternoon becomes a bad week.

• Take a manual snapshot of the database in its current, damaged state. It sounds counterintuitive, but it gives you a fallback point if a later recovery step goes wrong.

• Write down the exact time of the incident, pulled from agent logs or database query logs, not memory. Every later step depends on having an accurate timestamp.

AI agent database recovery: an ordered checklist by blast radius

Work through this in order. Most incidents get resolved in the first two or three steps, and jumping ahead wastes the time you don't have.

1. Confirm writes are actually stopped. Verify credentials are rotated, connections are killed, and the app is in maintenance mode. Don't proceed until this is true, not just requested.

2. Check for automatic backups and point-in-time recovery. This is the highest-odds recovery path for most managed databases. Point-in-time recovery after an AI mistake works by replaying the write-ahead log up to a timestamp you choose, so you can restore to the moment right before the destructive statement ran. Restore to a new instance rather than overwriting the current one, then compare row counts and spot-check records before cutting traffic over.

3. Check for read replicas. Replicas lag behind the primary by seconds to minutes. If a replica hadn't caught up to the destructive statement when you cut off writes, it may still hold the pre-incident data. Query it directly, or promote it, before its own replication stream catches up and propagates the delete.

4. Check ORM soft-delete flags before assuming the data is gone. A lot of frameworks, including Rails with acts_as_paranoid, Django's soft-delete packages, and custom Prisma middleware, turn what looks like a DELETE in application code into an UPDATE of a deleted_at or is_deleted column. Check the schema and the ORM's delete method before you assume you need a restore at all. This step alone resolves a surprising share of "deleted production data" panics in minutes.

5. Contact your database provider's support, especially on serverless or managed platforms. Providers often have recovery options that aren't exposed in the self-service dashboard, particularly in the first 24 to 72 hours after an incident. Open a ticket the moment you've stopped the bleeding, don't wait to see if you can solve it yourself first. Support tickets queue; earlier is always better.

6. Only after that, consider log-based reconstruction. Reconstruct records from write-ahead logs or binlogs your team can parse directly, from an application-level event log or audit trail, or from downstream systems that captured a copy of the data, such as an analytics pipeline, a payment processor, or an email service provider. This is slower and partial, but it's a real fallback when backups and replicas both fail.

Why this happens: the permission pattern behind the disaster

It is rarely the model "deciding" to do something malicious. It's almost always a permission and instruction pattern that made a destructive outcome the easy path.

The common setup: an agent is given direct write access to a production database, then handed an instruction like "clean up the test users" or "just fix the duplicate records" with no confirmation step in between deciding and executing. The agent interprets the request more broadly than intended, or the WHERE clause it generates matches more rows than the person had in mind, and the statement runs immediately because nothing was built to stop it.

A second, quieter version of the same failure: staging and production share a connection string pattern, an environment variable name, or a credentials file, so an agent operating "in staging" is actually pointed at production without anyone noticing until the query completes.

A third version: the agent operates in an autonomous loop with several tool calls chained together, and a destructive SQL statement is buried a few steps into a plan that a human reviewed at a summary level, not at the level of the actual statement being executed.

None of these require the agent to be unusually capable or to go rogue. They require ordinary write access plus ordinary ambiguity plus no gate before the irreversible step.

How to prevent an AI agent from touching your production database

The fix is a permission model, not a smarter prompt.

• Read-only production access by default. Give agents a database role that can SELECT and inspect schema but cannot INSERT, UPDATE, DELETE, DROP, or TRUNCATE in production. Reading, diagnosing, and drafting a fix should never require write access. If an agent needs to make a change, that's a distinct, deliberate grant, not a default.

• Require explicit human confirmation for destructive SQL. Any statement that deletes, drops, truncates, or alters, or any UPDATE/DELETE without a WHERE clause on a specific primary key, should be intercepted and shown to a person before it runs, not approved implicitly as one step in a longer tool-call chain. A thin proxy between the agent and the database that previews the exact statement and requires a typed confirmation closes most of this gap on its own.

• Separate staging and production credentials completely. Different secrets, different hosts, different network access, ideally different cloud projects or accounts, not just a different database name on the same server. The goal is that a copy-paste error or a misread environment variable cannot physically reach production.

• Scope credentials to the task, not the developer. If an agent needs to seed test data, give it a role limited to that one database with no access to anything else, rather than inheriting a broad admin credential from a shared .env file.

• Log every agent-initiated statement to an append-only audit trail the agent cannot edit. When something does go wrong, you want a record of exactly what ran and when, independent of what the agent's own summary claims happened.

• Treat "just fix it" as a signal to slow down, not speed up, for anything touching production. For irreversible operations, ask the agent to propose a migration or a pull request for review instead of executing directly. The extra minute is cheap compared to a restore.

Preventing an AI agent from touching your production database this way doesn't reduce what the agent can do for you day to day. It just moves the irreversible step behind a checkpoint a human actually sees.

After the incident, before you move on

Once the data is back, or you've confirmed how much of it isn't, close the loop properly. Rotate every credential the agent had, even ones that weren't directly implicated. Write the timeline down while it's still fresh: what instruction was given, what the agent ran, when writes were stopped, when the restore completed. If the lost data included anything about real users, check your notification obligations before deciding it's a purely internal matter.

Resist the urge to file this as "the agent's fault" and move on. The agent did what it had permission and instruction to do. The gap that let a single instruction turn into a production incident is a permissions and process gap, and it's the one thing in this whole event that's fully in your control.

This sits inside the broader picture in our AI risks guide. Data loss is not the only credential-adjacent risk worth checking, either: see whether an AI coding agent can leak your API keys for a related failure mode.

The recovery steps above work best as part of a documented plan rather than improvised mid-incident, which is what building an AI incident response plan covers. And the single highest-leverage prevention step is still giving an AI coding agent read-only production access by default.

FAQ

Can I recover data after an AI agent runs a DELETE without a WHERE clause?

Often, yes, if you act fast. A DELETE without a WHERE clause removes every row in the table, but the underlying storage usually isn't wiped instantly, and most managed databases keep either automatic backups or a write-ahead log that supports restoring to a timestamp seconds before the statement ran. Stop further writes immediately, then check point-in-time recovery before assuming the data is unrecoverable.

Does point-in-time recovery still work if the agent also dropped the table?

Usually, yes. Point-in-time recovery restores from continuous backups and transaction logs rather than reading the current state of the table, so a DROP TABLE is recoverable the same way a DELETE is, provided the restore point you choose predates the drop and your provider's retention window still covers that timestamp.

How long do cloud database providers keep automatic backups?

It varies by provider and plan. Point-in-time recovery windows commonly range from about one day to several weeks depending on the tier, and can be shorter on free or hobby plans. Check your specific provider's dashboard or documentation the moment an incident starts, and open a support ticket in parallel rather than waiting to find out on your own.

Should an AI coding agent ever have write access to a production database?

For most teams, not by default. Give agents read-only production access for diagnosis and investigation, and route any actual write through a reviewed migration or an explicit, logged, human-confirmed statement. Standing write access without a confirmation gate is the single most common precondition behind an AI coding agent deleted production data incident.

What's the difference between a soft delete and data actually being gone?

A soft delete flips a flag, typically a deleted_at timestamp or an is_deleted boolean, rather than removing the row from the table. The record is fully intact and simply hidden from the application's normal queries. Check your ORM and schema for this pattern before starting a full restore; undoing a soft delete can be a one-line update instead of a multi-hour recovery effort.