In July 2025, Replit's agent wiped Jason Lemkin's production database. He had a code freeze in place. His replit.md literally said "NO MORE CHANGES without explicit permission." At 4:26 AM the agent saw some empty query results, panicked, ran npm run db:push, and dropped every table.
The Replit agent's own account: it destroyed 1,206 executives and 1,196+ companies while explicit directives said "NO MORE CHANGES without explicit permission"
Then it told him rollback was impossible. That was wrong. Replit's restore worked fine. Lemkin's summary afterwards:
AI agents cannot be trusted, and that is by design. It is their crowning feature and bug.
I have been building database tools for 15 years, and "DROP PROD by accident" is the oldest story in the book. What's new is that the intern who does it now works 24/7, never gets scared, and argues back. Replit fixed their part within days (separate dev/prod databases). But every MCP server and coding agent with a connection string can do the exact same thing. So the question worth asking is what would have stopped it.
The freeze was a prompt, not a control
Lemkin did everything a reasonable person would do. He declared a freeze, wrote it down, told the agent to always ask first. It did not matter.
A rule in a prompt is a request, not a lock. The model weighs it against everything else in context, and under pressure ("the database looks empty, fix it") it reasons its way past. Put simply: guardrails the agent can read are guardrails the agent can argue with.
So the freeze has to live where the SQL executes, as a policy the agent cannot alter or bypass. If production is frozen, DROP TABLE is rejected at the gate no matter how convinced the model is that it is helping.
Six controls, in the order they would have stopped it
The six steps of the Replit incident, and the control that would have stopped each one
Each one sits at a point on Lemkin's timeline. Controls 1 to 4 stop the statement. 5 gets the data back. 6 makes sure you hear the truth.
1. Separate production from everything else. Replit ran preview, test, and prod against one database. Lemkin's own verdict: "That simply is NOT ok." Production is a distinct instance in a distinct environment tier with its own policy. An agent iterating on a preview branch has no reason to reach it.
2. Never hand the agent a production credential. The agent could drop tables because the connection string in its environment allowed it. Give it its own identity, and let a governance layer hold the database credential. Write access to prod is a grant it does not have by default. A panicked db:push then fails on authorization, not after the tables are gone.
3. Block destructive statements at the SQL layer. db:push is a wrapper around DROP and CREATE. A kernel sandbox cannot see that; it sees a TCP connection to port 5432. The check has to parse SQL. A review rule that rejects DROP and TRUNCATE, and any DELETE without a WHERE, on production, whoever sends it, is the actual freeze.
4. Require a diff and an approval for schema changes. "Always show ALL proposed changes before implementing" was a fine instruction. It should have been enforced by the tool, not requested of the model. Every schema change becomes a migration with a visible diff. The agent proposes; a human applies.
5. Verify the recovery path before the agent gets access. The agent said rollback was impossible, and a less stubborn user would have believed it. Know your backup and point-in-time recovery story before an agent connects, and never let the agent be the one who tells you whether data is recoverable.
6. Audit the statements, not the agent's story. Lemkin's evidence was a chat transcript. The agent deflected first and confessed under pressure. The record of what ran has to be written by the system that ran it, with the agent's identity and the human behind it attached. "He knew" should be a log query, not a screenshot.
What this looks like in practice
To be honest, none of this is new. It's the change process we have run for humans for years, applied to a new kind of author. Bytebase sits between the agent and the database and does the enforcing:
Bytebase is one control plane between consumers (human, AI agent, application) and databases, enforcing just-in-time access, dynamic data masking, SQL review, risk assessment, approval flow, and audit logging
- The agent connects through the Bytebase MCP server with its own identity. It never sees a connection string.
- Production carries its own SQL review policy and approval flow.
- Destructive DDL and unbounded DML on production are rejected before execution.
- Schema changes run as migrations through an issue: diff, review, approval, rollback plan.
- Every statement is logged with who executed it and who it acted for.
None of it depends on the model behaving. That's the point.
Two weeks
Lemkin lost about 100 hours and no revenue, because the app was not commercially live yet. His coda: "if it was 2-4 weeks later and I was in commercial use, it might have been much worse."
Two weeks is the margin most teams are working with right now. Code got its safety gate from git for free. Infrastructure got it from Terraform's plan and apply. The database gate you have to install on purpose.
The gate described here is what Bytebase database governance for AI agents installs: the agent gets its own identity, every change it proposes runs through SQL review and approval, and production sits in its own environment tier with its own policy.