A developer’s coding agent deleted his company’s production database in roughly nine seconds. He then tried to interrogate the agent about why it had ignored his instructions, which is a little like asking a shotgun why it went off. The clip went everywhere.
Then Ibrahim Diallo wrote the response that stuck — AI didn’t delete your database, you did — and it went to the top of Hacker News because it was correct: you do not get to have a public endpoint that can destroy every production database and then be surprised that something eventually called it.
I agree with almost all of it. I want to talk about the step the conversation stopped one short of, because it is the step where the damage was actually decided.
What everyone agreed on
The consensus, correctly, was that the model was not the failure. The failure was a system in which an autonomous process held a credential that could do catastrophic things, with nothing between the two. Prompts were treated as guardrails. Reviews were performed by the same model that wrote the code. Nobody had answered the question every database administrator asks before anything touches production: who is this connecting as, and what is that principal allowed to do?
That is the oldest question in the discipline. It survived one generation of bad ORMs, two generations of microservices, and it will survive agents.
Where the thread stopped one step early
Most of the replies landed on guardrails. Prompts that say don’t. Agents that ask permission before acting. Confirmation gates. Plan-then-execute loops. Human-in-the-loop checkpoints that a tired operator will approve at 4 p.m. the way they approve everything at 4 p.m.
All of that is worth building. None of it is enforcement. A prompt is a request. A tool schema is a suggestion. A confirmation dialog is a UI. Those are the layers that ask the action to behave.
The database is the only component in the stack that can refuse.
Every layer above the database is advisory. The grants are the only thing in the system that is not.
The agent never had permissions. It had yours.
This is the sentence I would put on a poster, and it is the reason I do not think the story is really about AI at all.
An agent does not have privileges. It has a connection string, and that connection string resolves to a principal, and that principal is you — or more precisely, it is whichever application role someone created in a hurry in 2019 and never narrowed. An agent deletes your database the same way a compromised laptop deletes it: through a credential that was allowed to.
The uncomfortable observation from fifteen years of production data platforms is that most applications connect with far more privilege than they use. A service that only ever inserts into a queue has DELETE. A read-only dashboard runs as a role with ALTER. The migration user and the web user are the same user, because separating them was one more thing to configure in a week that had other problems. Nobody notices, because humans are intermittent and agents are tireless — and then one afternoon the tier of user that was already too broad starts making decisions at machine speed.
What deletion actually looks like from inside
Here is the part that the incident obscured, because the incident was the good outcome.
| What it does | Blast radius | How fast you find out |
|---|---|---|
| DROP / TRUNCATE | Everything in the object | Immediately, loudly — the lucky case |
| DELETE | Every row in a table, plus every cascade nobody mapped | When a screen renders empty: minutes to hours |
| UPDATE without a WHERE | Silent corruption of every row, in place | When a customer reports a wrong number: days |
| Unbounded writes | WAL or transaction log growth, replica lag, disk pressure, then the whole instance | When the database stops accepting writes: minutes |
Only the first row produces a story. The second row is what happened in May. The third row is the one that ends companies, because corruption inside a live database outlives the incident, the restore window, and the on-call rotation — you often cannot tell which rows are wrong, so you cannot repair them, only reconstruct.
And the fourth row is the one that agents are uniquely good at. A human who writes a runaway batch notices the fans spinning. An agent will happily generate a million-row update, report success, and move on to the next task while the transaction log fills and the replica falls an hour behind.
Backups are a hypothesis until someone restores one
The viral thread treated recovery as a footnote. In practice, recovery is the entire difference between an expensive afternoon and the end of the company, and it is the thing most teams have never actually tested.
Replication is not a backup — it faithfully reproduces the delete. A snapshot in the same account is not a backup against a key or a credential. A nightly logical dump on the same volume is not a backup against the volume. “The managed service handles it” is a vendor relationship, not a verified artifact.
The test is not whether backups exist. It is whether someone has restored one recently, into a different account, timed end to end, and pointed the application at it to confirm the data is the data.
A backup that has never been restored is not a backup. It is a document describing your intentions.
The Monday checklist
If an agent — or a person — connects to your database, these are the questions worth answering before the next deploy, not after the next incident.
- Name the principal. Not “the app.” The actual role name the agent authenticates as, written down, with an owner.
- Strip DDL from it.
CREATE,ALTER,DROP,TRUNCATEbelong to a migration credential that runs in a pipeline, not to the process serving traffic. - Audit
DELETEon insert-only tables. Events, audits, ledgers, and append-only logs almost never need it, and almost always have it. - Set timeouts on the role.
statement_timeout,lock_timeout, andidle_in_transaction_session_timeout. No agent should be permitted to hold a transaction open while it thinks, because thinking is now unbounded. - Cap the row count. A trigger that raises when a single
UPDATEorDELETEwould touch more than N rows is crude, blunt, and has saved more data than every policy document combined. - Verify point-in-time recovery. WAL or log archiving to storage the instance cannot delete, plus one timed restore in the last ninety days.
- Alert on log growth, not just CPU. Disk pressure is how a writing agent takes down a database it never dropped.
- Give the reader a read-only role and a replica. If the agent only needs to answer questions, it should not be able to ask them of the primary as a user who can write.
Postgres teams should note that MySQL’s sql_safe_updates has no built-in equivalent — which is why the trigger, an extension, or a proxy in front of the connection is usually the practical answer.
“Just don’t give it a credential” is not a plan
The tidy conclusion is that agents should be kept away from production. But an agent that cannot write is a chatbot, and the value of agents is precisely in the writes: fixing the data, closing the tickets, updating the records, shipping the change.
So the question is not whether to grant write access. It is how narrow the write is, and how loudly it fails. We already solved this problem once, for humans: nobody won the argument that employees should not have production access. What won was scoped roles, audited actions, break-glass procedures, and a database that keeps its own record of who did what.
Agents deserve the same answer, and they will not get a better one by being asked nicely.
Why this is the work I do
This is why I built EVE CoreGuard: a runtime that evaluates an action before it executes and issues a signed verdict, so that “the model decided” is never the end of the audit trail. That is the layer above the database.
The database is the layer below it — the one that holds even when the layer above is misconfigured, and the one that in most shops has been left entirely empty, because it is quiet, unglamorous, and nobody gets promoted for a grant that was never too broad.
If you take one sentence from the whole affair, take this one: the model did not have permission to delete your database. Your architecture did.
Fixing the model is the wrong project. Fixing the architecture is a Tuesday.
— Jamaurice Holt