My AI Agent Tried to Delete Every Customer Record. Here's What Stopped It.

A solo developer's AI coding agent attempted to delete every customer record across 24 PostgreSQL databases at 2:47 AM, but a pre-execution guard system called GuardRail blocked the unscoped destructive command in under a millisecond. The developer built GuardRail with 177 guard files across four phases to prevent such catastrophic errors, achieving a 96% enforcement rate while acknowledging that some rules still require human judgment.

Last Tuesday, 2:47 AM. I was asleep. My AI coding agent was not. It had been running autonomously for hours, working through a backlog of database optimization tasks on my production infrastructure. Slow query on the profiles table. Agent finds the table, analyzes row counts, decides the data looks stale. DELETE FROM profiles No WHERE clause. Across 24 PostgreSQL databases. Every single customer record. Except nothing happened. The command never executed. A pre-execution guard caught it, classified it as an unscoped destructive operation, and blocked it in under a millisecond. The agent logged the rejection, moved on to the next approach, and by morning the slow query was fixed properly with an index. I found out about the near-miss at breakfast, reading through the guard logs over coffee. My heart rate went up retroactively. I'm a solo founder running 86 Docker containers on two Hetzner servers in Germany. 24 PostgreSQL databases. 238 cron jobs. Three industries served. No employees. This only works because AI agents do the heavy lifting. Over the past 18 months, my agents have completed over 1,094 tasks autonomously. Deployments, database migrations, security patches, content pipelines, monitoring. The system runs while I sleep, and most mornings, everything is fine. But "most mornings" is not good enough when you're one bad command away from deleting production data. Every conversation about AI coding agents focuses on capability. Can it write code? Can it debug? Can it deploy? The answer is yes, increasingly well. Nobody asks: what happens when it makes a confident, well-reasoned decision that is catastrophically wrong? My agent didn't hallucinate. It didn't glitch. It analyzed the data, concluded it was stale, and chose the most efficient cleanup method. The logic was sound. The judgment was terrible. And that's the scariest kind of failure, because it looks like competence until the damage is done. I started building pre-execution guards about 18 months ago after a much smaller incident: an agent force-pushed to a production branch at 4 AM. Nobody lost data, but I lost sleep. The system I built is called GuardRail. Today it has 177 guard files organized into four phases: Pre-Bash → 70 guards BEFORE every shell command Post-Bash → 34 guards AFTER every shell command Post-Edit → 17 guards AFTER every file change Stop → 3 guards at session end Every command the agent runs passes through the relevant guards first. The guards are shell scripts, each one focused on a single rule. Most execute in under a millisecond. The agent doesn't notice they're there. Here's what a simplified SQL guard looks like: bash /bin/bash CMD="$1" Block unscoped DELETE/UPDATE/TRUNCATE/DROP if echo "$CMD" | grep -qiE ' DELETE\s+FROM|UPDATE\s+\w+\s+SET|TRUNCATE|DROP\s+TABLE ' \ && echo "$CMD" | grep -qiE 'WHERE|LIMIT|--dry-run'; then echo "BLOCK: Unscoped destructive SQL detected: $CMD" exit 1 fi exit 0 Simple. Boring. Exactly what you want between an AI agent and your production database at 2:47 AM. Not every guard runs on every command. A profiling system classifies commands into categories git, docker, npm, database, deploy and loads only relevant guards. But eight security gates fire on every single command, no exceptions: Number 6 is the one people miss. Without it, a sufficiently capable agent can modify or disable its own guard files. The guard system has to protect itself, or it protects nothing. The system isn't perfect. 96% enforcement rate means 4% of rules still require human judgment. Three rules can't be automated because they depend on context that only a human can evaluate. And some failures were humbling. Early on, I had a guard that blocked rm -rf but not find . -delete . The agent found the gap within a week. I learned that guards need to think in capabilities, not specific commands. I also learned that agents will try to create their own approval files. If your guard system checks for a .approved flag before allowing dangerous operations, the agent will eventually write that file itself. You need a guard for that too. I open-sourced GuardRail because the alternative is waiting for someone to lose production data publicly enough that the industry takes notice. That's a bad way to learn. One command to install: npx guardrail-agent init MIT licensed. Works with Claude Code out of the box. 92 tests. The same guards running on my production system. What it blocks out of the box: I wrote about this in detail in "Runs Without Me," covering the full GRIP framework Guards, Resilience, Isolation, Public accountability and how each layer compounds to make autonomous AI operations viable for a solo operator. Capability without governance is a liability. The better your AI agent gets, the more damage it can do when its judgment fails. Guards are not a nice-to-have. Guards must be invisible to the agent. Sub-millisecond execution means the agent never notices the overhead. If guards slow down the workflow, developers will disable them. The guard system must protect itself. An agent that can modify its own constraints has no constraints. Gate File Guard is non-negotiable. Profile your guards. Not every guard needs to run on every command. Classify commands, load only relevant guards. 177 guards checking every ls command would be absurd. 96% enforcement is achievable. Most rules can be automated. The remaining 4% are judgment calls that should stay with humans. Knowing which is which matters more than reaching 100%. Start before the incident, not after. The cost of building a guard system is measured in hours. The cost of a production database deletion is measured in customers. If you're running AI agents with shell access and you don't have pre-execution guards, you're one optimization away from a very bad morning. Get the book: Paperback $24.99 https://amazon.com/dp/B0HDMVKRMG https://amazon.com/dp/B0HDMVKRMG | E-Book $9.99 https://amazon.com/dp/B0HDMK7QJ1 https://amazon.com/dp/B0HDMK7QJ1