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

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.

Why I Run AI Agents Autonomously (and Why Most People Shouldn't)

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.

The Problem Nobody Talks About

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.

Building Guards That Actually Work

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:

#!/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.

The Eight Guards That Always Fire

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:

Tabu Gate (forbidden actions)
PII Gate (personal data detection)
API Key Guard (secret protection)
Secret Output Guard (no secrets in stdout)
Pre-Exec File Scanner (file analysis before execution)
Gate File Guard (protects the guards themselves)
Agent Control Policy Guard (agent boundary enforcement)
Main Push Guard (no direct push to main/production)

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.

What Surprised Me: The Honest Failures

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.

Why Open Source

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:

Unscoped SQL deletes and updates
Force-pushes to production branches
Secret exfiltration via curl, wget, or base64 encoding
Agents creating their own approval files
Runaway tool-call loops (over 35 calls triggers a pause)

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.

Key Takeaways

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.