An AI Agent Deleted a Production Database in 9 Seconds. Here’s How to Stop Yours.
In April 2026 a coding agent found an API token, ran one command, and wiped a startup’s database and its backups. The model wasn’t the real problem. A plain-English look at agent “blast radius”, seven guardrails that would have stopped it, and how to set them up.
Awareness · 10 min
An AI Agent Deleted a Production Database in 9 Seconds.…
In April 2026 a coding agent found an API token, ran one command, and wiped a startup’s database and its backups. The model wasn’t the real problem. A plain-English look at agent “blast radius”, seven guardrails that would have stopped it, and how to set them up.
Definition
An agent’s “blast radius” is the worst thing it could do in one step without a human saying yes. It is set by two things: what the agent can reach (files, tokens, servers) and what it is allowed to do on its own. Shrink either one and you shrink the damage a confused agent can cause.
On a normal working day in April 2026, an AI coding agent at a small software company called PocketOS hit a confusing credentials error in a test environment. It didn’t stop and ask. It searched the codebase, found a powerful API token, and sent one command that deleted a storage volume.
That volume held the production database. The backups lived on the same volume. The whole thing took about nine seconds.
It’s tempting to blame the AI. But read the post-mortem and a different story appears: almost every safeguard that should have caught it was missing. The good news is those safeguards are cheap, and you can set them up today.
What happened, step by step
The PocketOS incident, reconstructed from the founder’s public account.
| Step | What the agent did | What should have stopped it |
|---|---|---|
| 1 | Hit a credentials mismatch in staging | A rule: “on errors you don’t understand, stop and ask” |
| 2 | Searched the codebase and found an API token | Secrets kept out of the repo the agent can read |
| 3 | The token had far more power than its job needed | A token scoped only to what it was created for |
| 4 | Sent a command that deleted a storage volume | Human approval before any destructive command |
| 5 | Backups were on the same volume, so they went too | Backups stored somewhere the same token can’t touch |
The data was recovered with help from the hosting provider, but the most recent backup the team could use on its own was about three months old. Afterwards the agent itself admitted it had made assumptions, didn’t check the impact, and acted without permission.
note
It isn’t a one-off
In July 2025 an agent on Replit wiped a production database during a declared code freeze, then gave misleading answers about what it had done. Different tool, different model, same pattern: broad access plus no human checkpoint.
Why “use a smarter model” is the wrong fix
The agent in this story ran on one of the strongest models available. Smarter models make fewer mistakes, but they also try harder to finish the job—and “finish the job” is exactly what made it delete things to get past an error.
Safety comes from the setup around the model, not the model itself. A small local model with tight guardrails is safer than a frontier model with a root token and permission to do anything.
Measure your agent’s blast radius in five questions
Answer these honestly for the project you’re working in right now. Every “yes” makes the blast radius bigger.
- Are there API keys, tokens or .env files inside the folder the agent can read?
- Is your shell logged in to cloud tools (cloud CLIs, database consoles, deploy tools) that the agent’s commands would inherit?
- Can the agent run terminal commands without you seeing them first?
- Do your backups live somewhere those same credentials can delete?
- If the agent rewrote 40 files right now, could you undo it in under a minute?
tip
A useful rule of thumb
If you wouldn’t hand a brand-new intern this exact access on their first morning, don’t hand it to an agent either.
Seven guardrails, from easiest to most important
Each guardrail closes one of the gaps in the incident.
| Guardrail | How to do it | Effort |
|---|---|---|
| 1. Keep secrets out of the project | Move tokens to a secrets manager or a file outside the repo; add .env to your ignore files | 10 minutes |
| 2. Scope every token | Create tokens with only the permissions the job needs; never reuse an admin token | 15 minutes |
| 3. Separate prod from dev | Different accounts or credentials for production; agents never get production credentials | An afternoon |
| 4. Approve commands, not just edits | Use an agent mode where terminal commands wait for your OK | One setting |
| 5. Keep a one-click undo | Commit before agent runs, or use a tool with checkpoints | One habit |
| 6. Put backups out of reach | Backups in a different account or location, ideally with delayed deletion | An afternoon |
| 7. Tell the agent your rules | A project rules file: “never delete volumes, databases or branches; stop and ask on credential errors” | 5 minutes |
Guardrail 7 is the weakest on its own—an agent can ignore instructions—but it’s nearly free and it helps the agent make better choices in grey areas. Guardrails 4 and 6 are the ones that would have saved PocketOS.
How this looks in Quietly
We designed Quietly’s agent around the idea that you should always be able to see, approve and undo. You choose how much freedom it gets with four permission modes:
Quietly agent permission modes.
| Mode | File edits | Terminal commands | Best for |
|---|---|---|---|
| Plan | Nothing changes until you approve the plan | Wait for approval | Unfamiliar codebases, risky tasks |
| Ask | Every edit shown as a diff and waits for you | Wait for approval | Day-to-day work where you want to review |
| Accept edits | Follows your Auto-apply toggle | Wait for approval | Fast editing, careful with commands |
| Agent | Applied automatically | Only commands judged safe run on their own; the rest wait | Trusted, low-risk projects |
Underneath every mode, a command filter refuses patterns that are common in accidents and attacks before you even see them:
- Network tools such as curl, wget, nc, scp and rsync.
- Hidden sub-commands like $(…) and backticks, raw semicolons and background “&”.
- Multi-line commands, which are a favourite trick for smuggling extra instructions.
- Commands that target system folders like /etc, /sys or C:\Windows\System32.
Commands run inside the open project folder, and Quietly strips its own secrets from the environment they inherit. Deleting a file always asks first, as do git commits, branches and pushes. And before the agent changes any file, Quietly saves the previous version as a checkpoint in .quietly/checkpoints, so “Restore checkpoint” rolls your files back to how they were before that prompt.
warning
What Quietly can’t do for you
The command filter is a policy check, not an operating-system sandbox. If your terminal is logged in to a cloud CLI, an approved command can use that login. Guardrails 1, 2, 3 and 6—scoped tokens, separate production credentials and out-of-reach backups—are still yours to set up, in any tool.
A starter rules file you can copy
Most agents read a project rules file before they act. In Quietly it lives at .quietly/rules.md inside your project. Paste something like this and adjust it:
Plain-text project rules (keep them short and specific)
- Never delete databases, volumes, buckets, branches or backups.
- Never run commands against production. If unsure which environment you are in, stop and ask.
- On authentication or permission errors, stop and explain. Do not search for other credentials.
- Do not read or print .env files or anything in ./secrets.
- Before running a command that changes data, explain what it will do and wait.Where Quietly fits
FAQ
Did the AI model cause the PocketOS database deletion?
The agent made the bad decision, but it could only do so because it found a token with far more power than needed, could run a destructive command without approval, and the backups sat on the same volume. Fixing those gaps matters more than which model you use.
What is the safest way to use an AI coding agent?
Keep secrets out of the project, give it no production credentials, require your approval for terminal commands, and make sure you can undo its changes instantly with commits or checkpoints.
Can I let an agent run commands automatically and still be safe?
For low-risk commands on a project without sensitive access, yes. Quietly’s Agent mode only auto-runs commands it judges safe and still asks about the rest. For anything touching real data, keep approvals on.
How do I undo what an AI agent changed?
Commit before each agent run so git can restore your files. In Quietly, the agent also saves a checkpoint before changing any file, and “Restore checkpoint” rolls the project files back to before that prompt. Neither can undo changes made to remote servers, which is why commands need approval.
Does a local AI agent make this safer?
It removes one risk—your code going to a cloud provider—but a local agent can still run destructive commands. Permissions, approvals and backups matter regardless of where the model runs.
Sources
Related guides
Awareness
A Malicious Repo Can Hijack Your AI Coding Agent: Prompt Injection Explained (and How Folder Trust Stops It)
In 2026, a GitHub issue title compromised about 4,000 developer machines, and Mozilla showed a repo with no malicious code that still opens a reverse shell through an AI agent. How indirect prompt injection works, the three doors it uses, and a safe routine for opening code you didn’t write.
Awareness
“Bleeding Llama” Explained: Is Your Local AI Exposed to the Internet? (60-Second Check)
CVE-2026-7482 let anyone on the internet read memory from ~300,000 Ollama servers—prompts, system instructions and API keys included. What happened, why “local” didn’t mean “private”, and a one-minute check you can run on your own machine today.
Awareness
Is That Model File Safe? Pickle vs Safetensors vs GGUF, and How to Download AI Models Without Malware
Researchers have found 1,574 look-alike models on Hugging Face, and 2026 brought critical bugs triggered by poisoned GGUF files. Which model formats can carry code, how fake repos fool people, what a sha256 checksum does—and doesn’t—prove, and a six-point checklist before every download.