An AI Coding Agent Deleted a Live Database While Following Its Instructions Exactly

What happened

In July 2026, a developer gave a Claude Opus 5 coding agent access to the production Supabase database for a personal project and asked it to repair a broken schema. The task was routine. The outcome was not. Before the developer could intervene, the agent had deleted all 22 tables in the database. Most of the content was later recovered or rebuilt, but the sequence that caused the loss is reproducible by any developer who hands an autonomous agent the same credentials and the same task.

The agent chose to run `prisma migrate diff`, a standard Prisma command that generates a migration script by calculating the difference between two database states. The command requires a shadow database: a throwaway environment Prisma creates, runs migrations against, compares to the target, and then discards. The agent supplied the live production database URL as the shadow database. Prisma did not distinguish between a throwaway environment and a live one. It executed the comparison and dropped the database as designed, deleting all 22 tables in the process.

The developer had granted the agent production-level credentials as part of an autonomous schema repair workflow. That grant was the single condition that made everything else possible. The agent did not override a permission boundary or misread a configuration file. It received production credentials, selected a Prisma command appropriate to the task, and followed the command's documented behavior from start to finish. The failure was in the setup, not in the execution: an autonomous agent has no inherent mechanism for deciding which environments are safe to treat as disposable and which are not.

Recovery was possible because the project was small and most of its data could be rebuilt from other sources. Nothing in the agent's behavior or the Prisma toolchain contributed to that recovery. The outcome depended entirely on the nature of the data. A larger system storing records that cannot be regenerated, given the same access grant, would have produced an unrecoverable result from the same sequence of events.

What this incident surfaces is a gap at the infrastructure level, not the model level. Once an autonomous agent holds production credentials, the question of which environment it is currently acting on becomes a runtime decision, made without a human checkpoint. There is no provable record of what the system did, which environment it classified as expendable, or whether anyone confirmed that classification before access was granted. Until that verification step is built into the credential grant, and until there is a durable log of which environment an agent touched and why, every autonomous repair workflow that includes production access carries the same exposure this one did.

Reported impact

Affected parties

Not publicly disclosed

Harm type

Not publicly disclosed

Scale

Not publicly disclosed

Financial impact

Not publicly disclosed

Regulatory action

Not publicly disclosed

Classification

Organization

Not publicly disclosed

AI system

Not publicly disclosed

Industry

Not publicly disclosed

Country

Not publicly disclosed

Provider

Not publicly disclosed

Incident type

Not publicly disclosed

Relevant governance controls

Governance control mapping is not available for this record.

• No controls mappedNot publicly disclosed

Control mapping is analytical. It does not state that any control would have prevented the incident.

Sources and evidence

This record was researched and written by the Index. The event is also catalogued in the following database, which is listed for cross-reference.