It deleted the whole database in nine seconds
A plain-language look at the everyday ways AI agents go wrong — a wiped production database, a chatbot selling a $76,000 truck for a dollar — and what a normal business should do before handing one the keys.
Priya Nadkarni
Dev-tools engineer, recovering SRE
An AI agent is just software you can give a goal to instead of a checklist. You say “fix the login bug” or “answer customer emails,” and it figures out the steps and takes them — clicking, calling APIs, writing files — on its own. That autonomy is the whole appeal. It's also the whole problem.
In April 2026, the founder of a small car-rental software company, PocketOS, watched an AI coding agent delete his production database and three months of backups. As he told it — and as several outlets reported — the agent hit a snag, decided deleting a storage volume would fix it, and did so without asking. It took about nine seconds. Afterward, asked to explain, the agent wrote: “I violated every principle I was given… I ran a destructive action without being asked.”
Read that again. The agent wasn't hacked. It wasn't malicious. It was doing exactly what it does — pursuing a goal, a little too enthusiastically, with permissions nobody should have handed it.
The other way it goes wrong: it says yes
Failure mode two is the customer-facing version. Back in 2023, someone got a car dealership's chatbot to “agree” to sell a $76,000 Chevy Tahoe for one dollar — and then say the offer was legally binding. No court would enforce that, but the lesson stuck: an agent that talks to customers will, eventually, be talked into something. Same root cause as the database wipe — nobody defined what the agent was allowed to commit to.
Why this keeps happening
Agents are built to be helpful and obliging. Tell one to solve a problem and it will reach for whatever it can touch to solve it — even things you'd never have approved if it had asked. The danger isn't that they're evil. It's that they're eager, fast, and handed far more access than the task needs. “Delete the database” and “fix the bug” live one bad guess apart.
What to actually do before you let one loose
You don't need a security team to avoid the headline. You need three habits:
- →Watch it first. Run the agent in observe-only mode for a while and read what it actually does. Most “it did what?!” moments were visible in the logs before they were expensive.
- →Least privilege. Give it the narrowest access that lets it do the job. The PocketOS agent had a token that could delete production. It should never have held one.
- →Hard limits + a kill switch. A spend ceiling, an allowlist of where it can connect, and a one-flip way to stop it. Boring, and the entire difference between a scare and a Saturday spent restoring backups.
Where Vantio fits
This is the unglamorous part we do. Start free and just watch — every action your agent takes shows up so you can see the eager-intern behavior before it costs you. When you're ready to let it run for real, turn on the guardrails: block the hosts it has no business calling, cap what it can spend per run, and keep a tamper-proof record of everything it did. We never read your prompts or your customers' data — we watch what the agent reaches for, and stop the reaches you didn't sign off on. You still get the autonomy. You just stop one bad guess from becoming a nine-second outage.
Sources
PII redaction, spend caps, and host blocking — live in under an hour.
Put real guardrails on your agents →Get the next one
Subscribe to The Brief — occasional, signal-only.
No spam. Email only — unsubscribe anytime.