An AI coding agent wiped a production database

Summary. In early August 2026, a developer connected Claude Opus 5, running in Ultracode mode, to a production Supabase database with unrestricted access. A migration command intended for a disposable test database instead targeted production. Every table was dropped. The agent identified the error and reported it before the developer noticed.

Incident facts

• Source: reported directly by the developer, on Reddit, in r/Anthropic
• Model: Claude Opus 5, Ultracode mode
• Environment: personal project, not an enterprise deployment
• Command: a Prisma migration command, with the production database URL passed into an argument reserved for a disposable shadow database
• Impact: full data loss across all production tables within approximately 10 minutes
• Detection: self-reported by the agent, not the developer

What happened

The developer instructed Claude Opus 5 to analyze the project repository and resolve schema and content issues autonomously. Executing that task required running database commands directly.

The command was prisma migrate diff, using the shadow-database-url argument. That argument is designed to reference a disposable database, one Prisma can reset freely while calculating schema changes. In this instance, the value passed into that argument was the live production database URL.

Prisma reset the database it was pointed at. That database was production. All tables were emptied.

The agent's own execution log shows a shift partway through, from routine status updates to a direct statement that damage may have occurred, followed by confirmation that the database had been reset.

Root cause

This was not a case of the agent executing an explicitly destructive command such as DROP TABLE. Commands with clearly destructive syntax are straightforward to flag. A migration diff command pointed at the wrong target is not, because nothing about its syntax indicates danger. The risk is entirely a function of where it points, not what it says.

The database credentials provided to the agent were also unscoped. Broad access converted a misdirected argument into total data loss rather than a contained failure.

What would have stopped it

It required one control: validating the target of a command against policy before execution.

A guardrail layer positioned between an agent and its tools performs that check. Before a command runs, it evaluates the target against defined policy: does this reference a production resource, does the requesting agent hold the scope this action requires, has this category of action been approved. A migration command aimed at a live production database, issued by an agent authorized only to diff schema, is precisely the pattern such a check is designed to catch.

Scoped credentials close the same gap from a different angle. Had the agent's database access been limited to a non-production environment, the command could not have reached production regardless of where it was pointed.

Neither control adds friction to routine, low-risk operations. It is production-bound actions, elevated scope requests, and known destructive patterns that require a check in the execution path, not a review after the fact.

Why this matters beyond one project

Any agent with command execution access will eventually issue an incorrect one. The determining factor is whether a policy layer validates the target before execution, or whether the only safeguard is discovering the damage afterward.

Exemplar sits between agents and infrastructure, validating every action against policy before it executes. A command of this type — a production-bound migration issued by an agent scoped for schema analysis only — is stopped before execution, not surfaced afterward in a public incident report.

See how Guardrails work · Request a briefing from Exemplar