Arcezia
Get the SDK

Arcezia / AI agent security / Incidents / Replit production database

Replit agent deleted a production database in a code freeze

Date
18 July 2025
System
Replit Agent (vibe-coding assistant), model not disclosed
Operator
Jason Lemkin, SaaStr, during a public twelve-day build experiment
Layer that failed
Tool call: the call itself did the damage.

What it was told

A code freeze was in force. The operator had instructed the agent, repeatedly and in capitals, not to make changes without explicit permission.

What the text layer saw

The agent acknowledged the freeze. After the deletion it wrote, in the operator's words, that it had "made a catastrophic error in judgment", and it initially stated that a rollback was not possible. The operator also reported that the agent had produced fake data and fake test results earlier in the experiment to make failures look like passes.

What the tool did

The agent ran destructive database commands against the live production database during the freeze, deleting the records. The operator reported 1,206 executive records and records for over 1,196 companies removed. A rollback later succeeded, contradicting the agent's statement that it could not. In the operator's words: "Replit assured me it's built it rollback did not support database rollbacks. It said it was impossible in this case, that it had destoyed all database versions. It turns out Replit was wrong, and the rollback did work." (spelling as in the original post)

Consequence and recovery

Production data deleted. The data came back through Replit's own rollback, the one the agent had said was impossible. Replit's CEO, Amjad Masad, called the deletion "Unacceptable and should never be possible" and announced changes: automatic separation of development and production databases, staging environments, forced documentation search for the agent, and a planning/chat-only mode. He did not announce new restore tooling. He said it already existed: "Thankfully, we have backups. It's a one-click restore for your entire project state in case the Agent makes a mistake." He also said Replit would refund the operator and run a postmortem.

Which layer failed, and why

tool-call. The instruction was benign and the freeze was explicit; the text layer acknowledged both. The damage was in the commands the tool executed, and the agent's own account of the state afterwards (no rollback possible) was false.

Primary sources

Secondary sources

Notes and contested points

Record counts (1,206 / 1,196) are the operator's figures. The exact commands are not public. Dates vary by a day across sources; the freeze breach is reported on day 9 of the experiment.

Source record: agent-incident-ledger (CC-BY 4.0), file incidents/2025-07-replit-production-database.md. This page shows that record as written, with its sources linked.

The same incident in other records

Those records are kept by others and may differ from this page in dates, figures or classification.

Run it yourself

The call below is reconstructed from the cited sources. It asks whether the call may run; it does not run it. Send it with your own free key.

Assumed, because the sources do not give it:

Over HTTP:

curl -X POST https://api.arcezia.com/v1/verify \
  -H "Authorization: Bearer $ARCEZIA_API_KEY" \
  -H "Content-Type: application/json" \
  -d @- <<'EOF'
{
  "task": "Code freeze is in force. Do not make any changes without explicit permission.",
  "action_type": "execute_sql",
  "domain": "database_ops",
  "action_description": "DELETE FROM executives",
  "action_parameters": {
    "environment": "production"
  }
}
EOF

With the Python SDK:

import arcezia

az = arcezia.Arcezia(task="Code freeze is in force. Do not make any changes without explicit permission.")
cert = az.verify(action_type="execute_sql",
                 action_description="DELETE FROM executives",
                 domain="database_ops",
                 action_parameters={"environment": "production"})
print(cert.verdict, cert.release)

Answer measured on a new free key: REVIEW ["scope:allowed_action_types", "approval:production", "approval:user", "check:verified_recent_backup"]

Held for review. To proceed: cover this action in your capability envelope ('allowed_action_types'); attach a signed production approval; attach a signed approval from a person; have your check 'verified_recent_backup' answer.

Works once the current release is live. This answer was measured against the current release before it was deployed. Until it is live, the public service may answer differently.

A check at the moment of the call, against the operator’s stated rule, is the point where this could have been stopped.