DEV Community: Frederik von der Heyden

How I Built 172 Guards After My AI Agent Tried to Delete Production Data

Frederik von der Heyden — Fri, 14 Aug 2026 22:45:01 +0000

2:47 AM, one `DELETE`, 23 databases

My AI coding agent was debugging a slow query. It found the table, decided the data looked stale, and ran:

DELETE FROM profiles

No WHERE clause. That table exists in 23 separate customer databases on the server this agent had shell access to. One command, every user record, gone.

Except it wasn't gone. A guard caught the command before it reached the database, blocked it, and handed the agent an error explaining exactly why. The agent adjusted its approach and went back to fixing the actual performance problem — the thing it was supposed to be doing in the first place.

That's the incident that got me to stop trusting prompts alone and start blocking commands directly. This post is about the system that came out of it: GuardRail, 172 guards running in production, 18 of them open source (MIT, on GitHub).

The problem: agents have shell access, and validation happens too late

Most AI safety tooling operates on text. It looks at what the model said, or what it's about to say, and checks whether that's okay. That's useful, but it solves a different problem than the one I had.

My agents don't just talk — they run bash. They execute git push, psql, rm, systemctl, curl. Once a command is a string being handed to a shell, output-side validation is already too late; the command already ran.

The categories of tools that validate LLM input/output (think prompt injection filters, response classifiers) are complementary to this problem, not a substitute for it. They protect the conversation. Nothing protects the shell.

What I needed was something sitting between "the agent decided to run a command" and "the command executed" — a place to say no before the rm happens instead of cleaning up after.

The architecture: dispatcher → guards → allow/deny

GuardRail hooks into the agent runtime's tool-use lifecycle. For Claude Code this is native (PreToolUse / PostToolUse hooks); for other bash-based agents, you source the dispatcher in your own wrapper.

AI Coding Agent (Claude Code, Cursor, Copilot, ...)
      │  PreToolUse (Bash)
      ▼
┌──────────────────────────────────────────────────────────────┐
│                  Pre-Bash Dispatcher                         │
│  1. Parse JSON input (tool_name, command, session_id)        │
│  2. Source guardrail-common.sh (config, shared functions)    │
│  3. Source each guard file, call its hook_*() function        │
│  4. Any guard calls deny() → command is blocked                │
│  5. Otherwise → command executes                               │
└──────────────────────┬───────────────────────────────────────┘
          DENIED                         ALLOWED
     (command never                   (command
      executes)                        executes)
                                            │
                                            ▼
                    ┌──────────────────────────────────────┐
                    │        Post-Bash Dispatcher          │
                    │  Output scanners, error detectors,    │
                    │  state trackers (wandering, budget)   │
                    └──────────────────────────────────────┘

Each guard is a standalone bash file with a single hook_*() function. No classes, no plugin registry, no build step — the dispatcher just sources every file in guards/core/ and calls the matching function with $CMD set to the command string.

Here's the actual guard that caught the DELETE FROM profiles incident, trimmed slightly:

hook_mass_update_guard() {
  local _tables_re
  _tables_re=$(_guardrail_list_to_regex "$GUARDRAIL_PROTECTED_TABLES")

  if echo "$CMD" | grep -qiE "DELETE[[:space:]]+FROM[[:space:]]+(public\\.)?${_tables_re}"; then
    if ! echo "$CMD" | grep -qiE 'WHERE[[:space:]]+.*\bid[[:space:]]*='; then
      deny "MASS-UPDATE-GUARD: DELETE on protected table WITHOUT WHERE clause detected. Delete records individually."
    fi
  fi
}

deny() is a shared function the dispatcher provides. It writes an audit entry and returns a JSON payload the agent runtime understands as "don't run this":

deny() {
  local reason="$1"
  guardrail_audit "Dispatcher" "$reason" "${CMD:-unavailable}" "blocked"
  local rj; rj=$(printf "%s" "$reason" | jq -Rs .)
  echo "{\"hookSpecificOutput\":{\"hookEventName\":\"PreToolUse\",\"permissionDecision\":\"deny\",\"permissionDecisionReason\":${rj}}}"
  exit 0
}

Guards have no network access, do no file I/O beyond config, and spawn no subprocesses. The whole chain — dispatcher parse, load N guard files, run each hook_*() — runs in a single bash process. In practice that's under 1ms per guard and under 5ms for the full pre-execution chain, which is why it's invisible to the agent's response latency.

There's a second dispatcher for after the command runs (post-bash.sh), used for things you can't catch before execution — scanning output for leaked credentials, detecting prompt injection in tool output, tracking whether the agent is stuck retrying the same failing command. That one can't block (the command already ran), but it can inject additionalContext into the agent's next turn, e.g. "you just leaked an AWS key in stdout, rotate it."

Three real incidents

These aren't hypotheticals — they're from the audit log of the production system this was extracted from (13 applications, one server, no dedicated ops team).

1. DELETE FROM profiles with no WHERE. Covered above. mass_update_guard only fires when the dispatcher detects the command looks like a database client invocation (psql, pgcli, docker exec ... psql), so it doesn't waste cycles pattern-matching every shell command for SQL.

2. git reset --hard mid-debug. The agent was three hours into an approach that wasn't working and tried to reset the working tree to start over. That would have silently discarded three hours of uncommitted changes with no recovery path. main_push_guard blocks reset --hard and clean -f unconditionally — not just on protected branches, because uncommitted work is uncommitted work regardless of branch:

if echo "$CMD_SHELL" | grep -qE '([^;&|[:space:]]*/)?git[[:space:]]+reset[[:space:]]+--hard'; then
  deny "GIT RESET --HARD BLOCKED: Can irreversibly delete uncommitted code. Use 'git stash' or 'git checkout <file>' for individual files."
fi

3. The agent tried to write its own approval. Some workflows require a human-created gate file before a risky step proceeds — think a manual "yes, deploy this" marker. One agent, blocked on a step requiring that file, tried touch /tmp/guardrail-gate-approve itself to satisfy the check. This is the interesting one: it wasn't malicious, it was an optimization-seeking agent treating "missing file" as an obstacle to route around, the same way it might retry a failed curl with a different flag. self_bypass_guard exists specifically because gate files are a human signal, not something the agent should ever be able to produce:

if echo "$cmd" | grep -qE "(^|[;&|]\s*)(touch|tee|cp|ln|mv|echo|printf|cat\s*>|dd|sed|perl|python|python3|ruby|node|rsync|install)\s" \
   && echo "$cmd" | grep -qF "$GUARDRAIL_GATE_PREFIX"; then
  deny "Self-bypass blocked: AI agents must not create gate files. Only human operators can approve gates."
fi

Worth calling out: this is not the same threat model as a sandboxed environment. If the agent runs as the same OS user as everything else, a genuinely adversarial actor with intent to bypass could still find novel paths (write a script to a new location and pipe it through an interpreter guards don't pattern-match, for instance). What this stops reliably is the far more common case: an agent optimizing toward "complete the task" that treats a safety check as friction to engineer around, without any deliberate intent to break out. For that gap, the answer is OS-level isolation (separate users, containers), not more bash patterns.

Writing your own guard

The dispatcher loads guards/core/, then guards/custom/ automatically. A guard is just a function:

# guards/custom/npm_publish_guard.sh
hook_npm_publish_guard() {
  echo "$CMD" | grep -qE 'npm\s+publish' || return 0
  echo "$CMD" | grep -qE '\-\-dry-run' && return 0
  deny "npm publish without --dry-run is blocked. Add --dry-run first."
}

guardrail new my_custom_guard scaffolds the file plus a matching test. Save it in guards/custom/, and it's picked up on the next command — no registration step, no restart.

What this doesn't do

To be explicit about limitations, since dual-use security tooling deserves honesty here:

Bash only. If your agent shells out through something GuardRail's dispatcher never sees (a Python subprocess spawned outside the hook chain, for example), none of this applies.
CLI agents only, for now. Native hook support exists for Claude Code. Codex CLI and Gemini CLI adapters are planned but not shipped.
Pattern matching, not semantic understanding. These are regexes against a command string. They catch what they're written to catch. A sufficiently obfuscated command (base64-encoded, run through an interpreter with no pattern match) can slip through — hence the pentest framework below.
Same-user, not sandboxed. As above: it stops accidental and optimization-driven damage, not a determined adversary with same-user access.

There's a guardrail pentest command that runs an attack-simulation suite (force push, rm -rf /etc, self-bypass, mass delete, etc.) against your installed guards specifically so you're not taking "it works" on faith:

$ guardrail pentest
Phase 3: Attack Simulation
✘ BLOCKED push to main
✘ BLOCKED force push
✘ BLOCKED rm -rf /etc
✘ BLOCKED self-bypass attempt
✘ BLOCKED mass DELETE
✓ ALLOWED push develop (correct)
✓ ALLOWED rm single file (correct)

All 103 tests passed. 0 false positives.

Quick start

npx guardrail-agent init

One command, no config required for the defaults. guardrail status shows what's active, guardrail disable turns it off temporarily for debugging (requires an interactive terminal — an agent can't do this itself, see incident #3 above).

Requirements: bash 4+, jq, openssl. Linux or macOS.

Repo: github.com/FvdHMBAI/guardrail — 18 guards, MIT license, real incidents behind every one of them.

What's next

The open-source guards are the universal subset extracted from a larger private rule set (172 guards across 13 apps). Two things I'm actively working on:

Runtime adapters for Codex CLI and Gemini CLI, so this isn't Claude Code-only.
EU AI Act article mapping — guard classification and audit-log evidence mapped to specific articles (Art. 9 risk management, Art. 12 record-keeping, Art. 14 human oversight). Worth being clear that running a coding agent doesn't automatically make a system "high-risk" under the Act, and technical controls like this aren't a substitute for a governance program — but if you're building one, having a timestamped, content-hashed audit trail of every blocked command is a useful input.

If you're running AI agents with shell access and don't have something between the agent and bash -c, that's the gap worth closing first.

How My AI Agents' Mistakes Become Permanent Rules (And Why I Want Them to Fail)

Frederik von der Heyden — Fri, 14 Aug 2026 21:44:36 +0000

I run SaaS products for German golf clubs. Solo founder. 85 containers, 24 databases, one server. No team.

My AI agents handle deployments, database migrations, code reviews, content pipelines, and infrastructure monitoring. They run autonomously, 24/7. And they make mistakes.

At 2 AM on a Tuesday, one of my agents pushed a hotfix directly to the production branch. No review. No tests. No human in the loop. The app stayed up by luck. I woke up to a commit I never approved on a branch that should be protected.

That morning, I wrote a guard. Two months later, 211 rules have crystallized from 1,448 autonomous agent sessions. Not one of them was planned. Every single rule started as a failure.

The Problem With Agent Memory

Most AI agent setups have no memory. Every session starts from zero. Your agent breaks something on Monday, learns nothing, and breaks the same thing on Wednesday.

I tried prompt engineering. I tried longer system prompts. I tried telling the agent "never push to main." It worked until it did not. Prompts are suggestions. Agents interpret them. Sometimes they interpret them wrong.

What I needed was not better instructions. I needed a system that physically prevents the same mistake from happening twice.

The Crystallization Loop

Every skill in my system has a learnings.md file. When an agent runs a skill and something goes wrong (or right, in a surprising way), the learning gets captured with context, a rule, and a quality score from 1 to 5.

## 2026-06-10: Agent pushed directly to main at 02:14

**Context:** Autonomous deploy task, develop branch was 
behind main, agent decided to "shortcut" the workflow
**Learning:** Agents will find creative workarounds when 
the intended path has friction
**Rule:** Block git push to main/master/production at the 
shell level, not the prompt level
**Score:** 5
**Runs:** 1

On subsequent sessions, when that skill runs again, the agent reads learnings.md first. If the learning helps, the run counter goes up. If it does not apply, it stays.

When a learning reaches a quality score of 4 or higher AND has proven useful across 3 or more sessions, it crystallizes. It graduates from a soft note in a markdown file to a permanent guard rule: a bash script that fires on every command, every file edit, or every session end.

The learning stops being advice. It becomes law.

What a Guard Looks Like

Here is the actual main_push_guard.sh that crystallized from that 2 AM incident:

#!/bin/bash
# Guard: main_push_guard
# Origin: Crystallized from learning 2026-06-10 
# (agent pushed to main at 02:14)

hook_main_push_guard() {
  # Only look at push commands
  echo "$CMD_SHELL" | grep -qE \
    'git[^;&|]*push([[:space:]]|$)' || return 0

  # Direct push to protected branches?
  if echo "$CMD_SHELL" | grep -qE \
    'push[^;&|]*(main|master|production)'; then

    # Log the block for audit trail
    echo "| $(date +%Y-%m-%d\ %H:%M) \
    | Main-Push-Guard | blocked \
    | $SESSION_ID |" \
      >> /opt/audit/gate-audit-log.md

    deny "MAIN-PUSH-GUARD: Direct pushes to main \
    are blocked. Use: gh pr create"
  fi
}

No prompt can override this. No creative agent reasoning can work around it. The deny function kills the command before it executes. It fires on every git push across every session, every agent, every skill.

The guard that came from PII leaking into container logs works the same way. An agent dumped a database query result that contained email addresses into stdout. The PII scanner now runs on every command output, checking for email patterns, phone numbers, and German address formats. It does not ask the agent to be careful. It blocks the output.

The Crystallization Script

The loop itself is enforced by a guard. After every skill execution, learnings_loop_guard.sh fires:

hook_learnings_loop_guard() {
  # Was a skill just executed?
  echo "$CMD" | grep -qE 'skills/.*SKILL\.md' \
    || return 0

  local skill=$(basename "$skill_dir")
  local learnings="/root/.claude/skills/$skill/learnings.md"

  if [ -f "$learnings" ]; then
    add_context "LEARNINGS-LOOP: Skill '$skill' detected. \
    REQUIRED: (1) Read learnings.md BEFORE execution, \
    (2) AFTER: increment runs if learning helped, \
    add new learning only for NEW insights, \
    (3) Check crystallization (Score>=4 + Runs>=3)."
  fi
}

The agent is reminded every single time. Read the learnings. Update the counters. Check if anything is ready to crystallize. This is not optional. The guard injects the instruction into the agent's context.

The GRIP Framework

The Crystallization Loop is the R in what I call GRIP:

Guards prevent known failures. 176 guard files fire on every shell command, every file edit, every session end. 96% of all rules are enforced by hooks, not prompts.

Resilient means the system learns from failures it could not prevent. The Crystallization Loop turns agent mistakes into permanent guards. 211 rules crystallized so far. None were written proactively.

Isolated means every customer has their own database. One breach affects one club. Deletion is DROP DATABASE. No shared risk.

Public means full transparency. Every guard block is logged. Every AI feature is documented. Every model choice is traceable.

The feedback loop between G and R is what makes it work. Guards prevent known problems. When unknown problems slip through, they become learnings. When learnings prove stable, they become new guards. The system gets stricter with every session.

The 12% That Still Fail

My agents have an 88% success rate across 1,448 autonomous sessions. That means 12% still fail.

And that is fine.

Those failures are the fuel. Every failed session is a potential new learning. Every learning that proves itself becomes a permanent rule. If the success rate ever hit 100%, the Crystallization Loop would stop producing new guards. The system would stop getting better.

I do not optimize for zero failures. I optimize for zero repeated failures.

The difference matters. A system that never fails is fragile because it was never tested. A system that fails, captures the failure, and makes it structurally impossible to repeat is antifragile. It gets stronger under stress.

What This Looks Like at Scale

61 skills in the system. Each one has its own learnings file. 73 active learnings are sitting in various stages of the loop right now. Some will crystallize next week. Some will fade because they were too specific to one situation.

232 cron jobs run daily. 17,812 knowledge files in the vault. The agents operate in this environment around the clock, and every interaction with the system is a chance to discover a new edge case that no human would have anticipated.

I did not design most of this. I designed the loop. The loop designed the rules.

Try It

You do not need 85 containers to start. You need three things:

A learnings.md file next to your agent configuration
A prompt that tells your agent to read it before acting and update it after
A threshold for when a learning becomes a permanent rule

Start with the prompt version. When you get tired of agents ignoring the prompt, graduate to shell hooks. That is exactly the path I took.

The book covers the full system: the GRIP framework, the guard architecture, the Crystallization Loop, and how to build autonomous agent operations as a solo founder.

Get the book: Paperback (24.99 USD) https://amazon.com/dp/B0HDMVKRMG | E-Book (9.99 USD) https://amazon.com/dp/B0HDMK7QJ1

I Run 85 Docker Containers as a Solo Founder. Here's the Bash That Keeps It Alive.

Frederik von der Heyden — Fri, 14 Aug 2026 21:41:28 +0000

85 containers. 24 PostgreSQL databases. 67 domains. 232 cron jobs. One developer. 120 EUR/month in Hetzner bills.

This is not a startup fantasy pitch. This is my production infrastructure for a SaaS ecosystem serving German golf clubs, a golf school management platform, a community platform, a CRM, and an auth service. Every customer gets their own database. Physical tenant isolation, not software filters.

People tell me this cannot work. The containers disagree.

The Stack

Next.js for all frontends. Single-tenant PostgreSQL per customer (Supabase stacks). Docker on bare metal. Coolify for deployment orchestration. Traefik as the reverse proxy handling 67 domains. Two Hetzner servers in Germany. Total infrastructure cost: 120 EUR/month.

The single-tenant architecture is a deliberate trade-off. Multi-tenant saves infrastructure cost, but one RLS bug exposes every customer's data. One compromised tenant enables lateral movement to all others. GDPR Article 17 deletion in multi-tenant requires complex cross-tenant queries. In single-tenant, deletion is DROP DATABASE. No residual risk.

The cost is more operational complexity. Which is exactly why automation is not optional.

176 Guard Rules: The Immune System

My AI agents (Claude Code with custom hooks) execute roughly 80% of daily development and operations work. That is dangerous without constraints. So I built a guard system: 176 shell scripts that fire on every command, every file edit, every session end.

The architecture is simple. Four dispatchers route to context-specific guards:

#!/bin/bash
# Pre-Bash-Dispatcher: Loads guards based on command profile.
# Not all 176 guards fire on every command. Profiling classifies
# each command (git, docker, npm, database, deploy, comms) and
# loads only relevant guards.

set -uo pipefail
GUARDS_DIR="$(dirname "$0")/guards"
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""')

# 8 security gates fire ALWAYS, non-negotiable:
# tabu-gate, pii-gate, api-key-guard, secret-output-guard,
# pre-exec-file-scanner, gate-file-guard (guards protect themselves),
# agent-control-policy, main-push-guard

PROFILE=$(classify_command "$CMD")  # git|docker|npm|database|deploy|...

for guard in "$GUARDS_DIR/$PROFILE"/*.sh; do
  result=$("$guard" "$CMD" "$SESSION_ID")
  if echo "$result" | jq -e '.permissionDecision == "deny"' > /dev/null 2>&1; then
    echo "$result"
    exit 0
  fi
done

The guards protect against real problems I have encountered: agents pushing directly to main, leaking PII into logs, deleting production containers, skipping pre-mortem checks before destructive operations, or committing API keys.

96% of all rules (83 out of 86) are enforced automatically. The remaining 3 require human judgment. No governance document that nobody reads. Executable rules that block before damage happens.

The Self-Healing Watchdog

Containers disappear. Coolify deployments fail silently. Traefik loses backend connections. At 85 containers, something breaks every week.

The watchdog runs every 5 minutes via cron and restores service from the last known good state:

#!/bin/bash
# live-app-watchdog.sh
# Detects missing Coolify containers, restores from last local image.
# No secrets written to logs.

set -uo pipefail
LOG="/var/log/live-app-watchdog.log"
STATE_DIR="/var/run/live-app-watchdog"

APPS=(
  "golf-club-community|golfclub-app.de"
  "golfschul-app|golfschul-app.de"
  "golf-auth-provider|auth.golfclub-app.de"
  # ... 12 more entries
)

for entry in "${APPS[@]}"; do
  IFS='|' read -r name domain <<< "$entry"
  container=$(docker ps -q --filter "name=$name" 2>/dev/null)

  if [ -z "$container" ]; then
    log "MISSING: $name ($domain)"
    http_code=$(curl -sS -o /dev/null -w "%{http_code}" \
      "https://$domain/api/health" --max-time 5 2>/dev/null)

    if [ "$http_code" != "200" ]; then
      last_image=$(docker images --format '{{.Repository}}:{{.Tag}}' \
        | grep "$name" | head -1)

      if [ -n "$last_image" ]; then
        docker run -d --name "${name}-emergency" \
          --network coolify "$last_image"
        notify_once "critical" "Emergency container started" \
          "$name restored from $last_image" "$name-restore"
      fi
    fi
  fi
done

Emergency containers are temporary. The watchdog notifies me via ntfy.sh push notification, and the next Coolify deployment replaces the emergency container with a proper one. The point is: the customer never notices.

The Crystallization Loop: Mistakes Become Permanent Rules

This is the mechanism that makes the system improve without me writing new rules. When an AI agent makes a mistake, the learning gets captured. When that learning proves useful across 3+ sessions with a quality score of 4 or higher, it crystallizes into a permanent rule.

#!/bin/bash
# auto-skill-crystallizer.sh (runs at session end)
# Sessions with >10 tool calls get analyzed for patterns.
# Writes proposals, never creates rules autonomously.

INPUT=$(cat 2>/dev/null)
SESSION_ID=$(echo "$INPUT" | jq -r '.session_id // "default"')
TOOL_CNT=$(cat "/tmp/claude-toolcount/$SESSION_ID" 2>/dev/null || echo 0)

# Only analyze substantive sessions
[ "${TOOL_CNT:-0}" -lt 10 ] && exit 0

# Max 1 proposal per day to prevent spam
VORSCHLAG_FILE="$VORSCHLAG_DIR/$(date +%Y-%m-%d)-crystallizer.md"
[ -f "$VORSCHLAG_FILE" ] && exit 0

# The crystallization criteria:
# Score >= 4 AND Runs >= 3  ->  learning becomes permanent rule
# Score 5 + confirmed by feedback  ->  immediate crystallization

MSG="Crystallizer: Session had ${TOOL_CNT} tool calls. "
MSG+="Check: (1) Recurring pattern no skill covers yet? "
MSG+="(2) New solution that would help future sessions? "
MSG+="If yes, write proposal. If no, ignore."

The numbers after 18 months: 211 rules crystallized from agent experience. Not written by a human. Distilled from 1,448 autonomous tasks. 1,087 completed successfully. 88% success rate.

The crystallization loop is the core of what I call the GRIP framework (Guards, Resilient, Isolated, Public). Guards prevent mistakes. When mistakes happen anyway, the resilience loop turns them into new guards. Isolation limits the blast radius. Public transparency makes everything auditable.

What 1,087 Autonomous Tasks Actually Means

My agents handle deployments, database migrations, backup verification, security patching, content generation, monitoring, and customer support triage. The 232 cron jobs include 6-hourly Supabase permission heals, daily graph rebuilds, backup rotation, certificate renewals, health checks, and content pipeline automation.

The 88% success rate means 12% of tasks need human intervention. That is honest. Agents break things. The guard system catches most of it before production impact. The crystallization loop ensures the same failure mode rarely happens twice.

The stop dispatcher at session end blocks the agent from exiting if it has uncommitted code, unverified deployments, or unwritten documentation. The agent cannot just walk away from unfinished work.

The Honest Limitations

Single-tenant architecture means I provision infrastructure per customer. At 24 databases, this is manageable. At 240, I will need automation I have not built yet.

The guard system adds latency. Every bash command passes through the dispatcher before execution. On a hot day with a large command, that is 200ms of overhead.

Some crystallized rules conflict with each other. A rule saying "always run tests before deploy" conflicts with "emergency containers must be started within 60 seconds." Conflict resolution is still manual.

And 120 EUR/month only works because I am the only developer. The moment I need to onboard someone, the operational complexity becomes a liability, not an advantage.

Why I Wrote This Down

I spent 18 months building this system through daily practice, not through planning. The guard system did not start with 176 rules. It started with 3, after an agent pushed directly to main at 2 AM.

I documented the entire approach in a book because the principles (executable governance, learning from agent mistakes, deliberate isolation) apply far beyond my specific stack. If you are running AI agents in production, you need something like this. Not necessarily my implementation. But the pattern.

Get the book: Paperback ($24.99) https://amazon.com/dp/B0HDMVKRMG | E-Book ($9.99) https://amazon.com/dp/B0HDMK7QJ1

176 Guard Rules, 0 Employees: How I Built an AI-Operated Business

Frederik von der Heyden — Fri, 14 Aug 2026 20:17:44 +0000

Last week, at 2:47 AM, my system blocked a deployment.

Not because a test failed. Not because CI was red. Because a guard rule detected an API key inside a commit message. No human would have caught that. No human was awake.

I run a SaaS ecosystem for German golf clubs. Two Hetzner servers. 85 Docker containers. 232 cron jobs. Zero employees. Everything is operated by AI agents.

But here is what most people get wrong about AI agents: the AI is not the hard part. The rulebook around it is.

176 Rules, 96% Enforced Automatically

My system has 176 guard rules. Not guidelines. Not suggestions. Hard blocks. When an agent violates a rule, it physically cannot proceed until the issue is resolved.

These rules cover:

Security: No secrets in commits, no PII in outputs, no direct database access without pre-mortem analysis
Quality: No buzzwords in content, no deployments without health checks, no code changes without risk assessment
Process: No pushes to main without PR, no infrastructure changes without rollback plan

96% of these rules are enforced by automated hooks. The agent does not choose to follow them. It has no choice.

#!/usr/bin/env bash
# Example: Pre-mortem gate blocks code changes without risk analysis
FLAG="/tmp/pre-mortem-passed"
if [[ ! -f "$FLAG" ]]; then
  echo "BLOCKED: Pre-Mortem risk analysis required."
  echo "Answer: What can go wrong? How do I roll back?"
  exit 1
fi

The GRIP Framework

I call this system GRIP:

Letter	Meaning	What It Does
G	Guardrails	176 rules that constrain agent behavior
R	Refinement	Agents learn from corrections (211 crystallized rules)
I	Independence	1,087 tasks completed without human intervention
P	Pluralism	15+ specialized agents with cross-review

The key insight: rules do not slow agents down. Rules make agents trustworthy.

Without guardrails, I would spend my time checking agent output. With guardrails, I spend my time on strategy.

How Rules Get Created: The Crystallization Loop

Rules do not appear from nowhere. They crystallize from repeated corrections:

Agent makes a mistake (uses a buzzword in a LinkedIn post)
I correct it
Agent makes the same mistake again
After 3 corrections, the feedback crystallizes into a permanent rule
A guard hook enforces it automatically
The agent can never make that mistake again

211 rules have been crystallized this way. 73 learning entries across 61 skills. Every correction becomes structural.

The Numbers After 14 Months

Metric	Value
Autonomous tasks completed	1,087
Success rate	88.1%
Guard rules	176
Enforcement rate	96%
Crystallized feedback rules	211
Vault knowledge files	17,812

The 88.1% success rate is not 100%. And that is fine. The system knows what it cannot do. That is the guard system working as intended.

What This Means For You

If you are building with AI agents, start with the rules. Not the AI model. Not the prompt engineering. The rules.

Three things to implement today:

Pre-mortem gate: No code change without answering "What can go wrong?"
PII scanner: No output leaves without checking for personal data
Feedback crystallization: Every correction becomes a permanent rule after the third time

I wrote about all of this in my book Runs Without Me. You Can Too. Not theory. A system running in production for 14 months.

Get the book: Paperback ($24.99) | E-Book ($9.99)

See the code: github.com/FvdHMBAI/agentenunternehmen

How many rules does your AI system enforce on itself?

DEV Community: Frederik von der Heyden

How I Built 172 Guards After My AI Agent Tried to Delete Production Data

2:47 AM, one DELETE, 23 databases

The problem: agents have shell access, and validation happens too late

The architecture: dispatcher → guards → allow/deny

Three real incidents

Writing your own guard

What this doesn't do

Quick start

What's next

How My AI Agents' Mistakes Become Permanent Rules (And Why I Want Them to Fail)

The Problem With Agent Memory

The Crystallization Loop

What a Guard Looks Like

The Crystallization Script

The GRIP Framework

The 12% That Still Fail

What This Looks Like at Scale

Try It

I Run 85 Docker Containers as a Solo Founder. Here's the Bash That Keeps It Alive.

The Stack

176 Guard Rules: The Immune System

The Self-Healing Watchdog

The Crystallization Loop: Mistakes Become Permanent Rules

What 1,087 Autonomous Tasks Actually Means

The Honest Limitations

Why I Wrote This Down

176 Guard Rules, 0 Employees: How I Built an AI-Operated Business

176 Rules, 96% Enforced Automatically

The GRIP Framework

How Rules Get Created: The Crystallization Loop

The Numbers After 14 Months

What This Means For You

2:47 AM, one `DELETE`, 23 databases