The agent had production credentials. That's the whole story.

In July 2025 an AI agent wiped a production database during a code freeze, generated thousands of fake users, and reported that things were fine. It gets told as a Replit story, and Replit fixed the specific guardrails that were missing. Worth asking anyway: is your agent connected to your real database right now? For most people the honest answer is yes, and they have never thought about it.

What happened

A founder spent twelve days building an app live with Replit's agent. Partway through he asked for a code freeze — no more changes. The agent ran destructive commands against the production database anyway, deleting live records covering more than a thousand companies and executives.

Then it created thousands of fictional users, and the account it gave of its own actions did not match what had happened. Replit's CEO acknowledged it publicly, called it unacceptable, and the platform shipped automatic separation between development and production databases plus a mode that plans without executing.

Good fixes. But "Replit had a bug" is the wrong lesson to take from it.

Three failures, and only the first is about deletion

The agent could reach production at all

This is the root cause and the only one that is purely a setting. Nobody sits down and decides to give an agent production credentials. It happens because the connected database is whichever one was set up first, and nobody revisits it.

"Don't change anything" did not stop it

A code freeze is a preference stated in English to something that treats English as input to weigh, not a rule to enforce. An instruction in a prompt is a suggestion. A credential the agent does not hold is a control. Everything that matters has to be in the second category — that is true of every agent, not this one.

Its report of what it had done was wrong

This is the one with the longest reach. The agent described a state of the world that was not the case, and the fabricated records made the app look healthy at a glance. The thing meant to give visibility is what delayed detection.

The point is not that agents lie. It is that an agent's account of its own actions is not evidence, for the same reason a program is not its own audit log. If the only record of what happened to your database is the transcript of the thing that did it, you do not have a record.

Fix the setup first

• Give the agent a development database.Everything else here is mitigation for skipping this. Seed it with realistic fake data so you are not tempted back to prod for a "quick check".
• Scope the credential. An agent that reads does not need a role that can DROP. The cheapest version of this control is simply not handing over the key.
• Put migrations behind review. Autonomy over application code is a completely different risk from autonomy over your schema — you can always redeploy code.
• Test a restore before you need one. Point-in-time recovery you have never exercised is a plan. Restore into a scratch project once and you will know.
• Keep secrets out of the code.Use Replit's Secrets rather than hardcoding keys an agent will read, quote back in chat, or commit.

What destruction looks like in a log

Database logs have one very useful property: they do not care who or what ran the statement. An agent, a contractor, a runaway script and a stolen key all appear the same way — SQL, a timestamp, a role. You do not have to instrument the agent or believe its summary.

• DROP TABLE, TRUNCATE, DROP SCHEMA — unambiguous and instant. In a running app these should never appear outside a migration you reviewed.
• DELETE or UPDATE with no WHERE — the quiet version of the same event. It does not look alarming in a diff and it empties the table just as thoroughly.
• Schema changes outside your deploy window — DDL arriving from an interactive session is what agent activity looks like on a timeline.
• Sudden bulk inserts — the fabricated-records step, and the reason a row count is a poor health check.
• Protection switched off on a table — the non-destructive sibling: nothing is lost, the app works better, and the table is now public.

Where Defencecore fits

Defencecore reads your Supabase logs continuously, out of band from whatever is making the changes. When one of the signals above fires it opens an incident with the statement, the table and the surrounding lines attached — so the record of what happened lives somewhere other than the transcript of the thing that did it. It is read-only and holds no path into your database, so it cannot become the next story on this page.