176 Regeln, die kein Mensch geschrieben hat

Um 02:47 Uhr stoppte mein System ein Deployment. Kein Mensch war wach.

Es war ein Dienstagmorgen, als mein Guard-System anschlug. Nicht wegen eines fehlgeschlagenen Tests. Nicht wegen eines Syntaxfehlers. Ein Agent hatte versucht, einen Commit zu pushen, der einen AWS-API-Schlüssel enthielt. Der Schlüssel steckte in einer Konfigurationsdatei, die eigentlich nie ins Repository sollte. Der Deployment-Prozess wurde blockiert. Um 02:47 Uhr.

Kein Mensch hätte das um diese Zeit gesehen. Der Schlüssel wäre live gegangen.

Das war kein Einzelfall. Es war der 47. Vorfall in 14 Monaten, den mein System automatisch abgefangen hatte, bevor er Schaden anrichten konnte. Und er hat mir klarer als je zuvor gezeigt, warum das Regelwerk wichtiger ist als das Modell selbst.

Was ein Guard-System wirklich ist

Die meisten, die über KI-Sicherheit sprechen, meinen Alignment, Halluzinationen oder Trainingsdaten. Das sind echte Probleme, aber sie liegen auf einer anderen Ebene. Ich rede von etwas Handwerklichem: einem System, das verhindert, dass ein KI-Agent im laufenden Betrieb Fehler macht, die Menschen Geld oder Daten kosten.

Mein System läuft auf einem Prinzip, das ich GRIP nenne: Guards, Rules, Isolation, Protocol. Jeder Agent, der in meinem Stack läuft, durchläuft vor jeder kritischen Aktion eine Prüfkette. Nicht als Empfehlung. Als harter Block.

Das bedeutet konkret: Der Agent darf nicht weiter, bis das Problem behoben ist. Kein Fallback, kein "try anyway", kein Override ohne explizite Freigabe.

# Beispiel: Pre-Commit Guard gegen Secrets
#!/bin/bash
STAGED_FILES=$(git diff --cached --name-only)

for FILE in $STAGED_FILES; do
  if grep -rE "(AKIA[0-9A-Z]{16}|sk-[a-zA-Z0-9]{32,}|ghp_[a-zA-Z0-9]{36})" "$FILE" 2>/dev/null; then
    echo "GUARD BLOCK: Potential secret detected in $FILE"
    echo "Deployment halted. Remove secret before proceeding."
    exit 1
  fi
done

Das ist kein ausgeklügeltes KI-Modell. Das ist ein Shell-Skript, das seit Monaten zuverlässig seinen Job macht.

176 Regeln und wie sie entstanden sind

Ich habe nicht mit 176 Regeln angefangen. Ich habe mit drei angefangen.

Regel 1: Kein Deployment ohne erfolgreichen Health-Check. Regel 2: Keine Datenbankoperation ohne explizite Bestätigung bei destruktiven Aktionen. Regel 3: Keine externen API-Calls ohne Rate-Limit-Prüfung.

Jede weitere Regel entstand aus einem Vorfall. Nicht aus einer Spezifikation, nicht aus einem Framework-Dokument. Aus echten Fehlern, die entweder ich gemacht habe oder mein System fast gemacht hätte.

Das ist das Entscheidende: Guards werden nicht designed. Sie werden aus Schmerz destilliert.

# Guard-Registry: Struktur einer Regel
{
  "id": "SEC-007",
  "name": "api_key_in_commit",
  "severity": "critical",
  "enforcement": "hard_block",
  "trigger": "pre_commit",
  "pattern": r"(AKIA[0-9A-Z]{16}|sk-[a-zA-Z0-9]{32,})",
  "created": "2025-03-12",
  "incident_ref": "INC-2025-019",
  "auto_enforced": True
}

96 Prozent meiner 176 Regeln sind automatisch durchgesetzt. Die restlichen 4 Prozent sind Advisory-Regeln, die den Agenten warnen, aber nicht stoppen. Diese Unterscheidung ist fundamental. Ein Advisory-System ist wertlos, wenn niemand die Warnungen liest. Ein Hard-Block ist unbequem, aber zuverlässig.

Die drei Kategorien, die wirklich zählen

Nach 14 Monaten habe ich gelernt, dass Guards in drei Kategorien fallen:

Sicherheits-Guards schützen vor Datenlecks, unberechtigten Zugriffen und kritischen Infrastrukturfehlern. Der API-Schlüssel-Vorfall fällt hier rein. Diese Regeln haben keine Ausnahmen.

Qualitäts-Guards prüfen, ob eine Ausgabe dem erwarteten Format entspricht, ob ein Agent in einer Schleife steckt oder ob Ausgaben plötzlich leer werden. Diese Guards haben Schwellenwerte.

# Beispiel: Loop-Detection Guard
def detect_agent_loop(action_history, window=10):
    recent = action_history[-window:]
    unique_actions = set(a['type'] for a in recent)
    if len(unique_actions) <= 2 and len(recent) >= window:
        return True  # Agent wahrscheinlich in Loop
    return False

Prozess-Guards stellen sicher, dass bestimmte Schritte in der richtigen Reihenfolge passieren. Kein Deploy vor Code-Review. Kein Datenbankzugriff vor Backup-Bestätigung. Keine externe Kommunikation vor expliziter Freigabe.

Was ich falsch gemacht habe

Ich habe anfangs zu viele Regeln als Advisory gesetzt. Die Logik war: Ich will den Agenten nicht unnötig einschränken. Das war ein Fehler.

Advisory-Regeln geben das Gefühl von Kontrolle, ohne tatsächlich zu kontrollieren. Ich habe gesehen, wie ein Agent zehnmal hintereinander dieselbe Warnung ignoriert hat, weil nichts ihn gestoppt hat. Erst als ich die Regel auf Hard-Block umgestellt habe, änderte sich das Verhalten.

Das zweite Fehler war fehlende Incident-Referenzen. In den ersten sechs Monaten habe ich Regeln hinzugefügt, ohne zu dokumentieren, warum sie existieren. Nach einem Jahr wusste ich nicht mehr, welche Regeln aktiv gebraucht wurden und welche ich aus einer Laune heraus hinzugefügt hatte. Jetzt hat jede Regel eine incident_ref oder eine rationale. Das macht Audits möglich.

Das beschreibe ich ausführlich in "Läuft ohne mich", weil es einer der häufigsten Fehler ist, den ich bei anderen Systemen sehe: Guards, die niemand mehr versteht und deshalb niemand mehr pflegt.

Das Verhältnis zwischen Agent und Regelwerk

Es gibt eine Spannung, die ich permanent manage: Ein Agent, der zu stark eingeschränkt wird, ist nutzlos. Ein Agent ohne Einschränkungen ist gefährlich.

Meine Faustformel: Je autonomer ein Agent operiert, desto enger muss das Regelwerk sein. Nicht weil KI-Modelle unzuverlässig sind, sondern weil Autonomie Kontext voraussetzt, den ein Modell nicht immer hat.

Um 02:47 Uhr hat kein Modell der Welt den Kontext, zu wissen, ob ein bestimmter API-Schlüssel absichtlich oder versehentlich im Commit gelandet ist. Ein Guard hat diesen Kontext auch nicht. Aber ein Guard muss ihn nicht haben. Er muss nur wissen: Schlüssel in Commit gleich Stop.

Einfache Regeln, die zuverlässig greifen, schlagen komplexe Regeln, die manchmal funktionieren.

Wie man anfängt

Wenn ich heute von vorn anfangen würde, würde ich drei Dinge sofort tun:

Erstens: Jeden Incident dokumentieren, auch kleine. Was wäre fast schiefgelaufen? Was hat einen Agenten in eine unerwartete Situation gebracht? Jeder Incident ist ein Guard-Kandidat.

Zweitens: Mit drei Hard-Block-Regeln starten, nicht mit dreißig Advisory-Regeln. Wenige, harte Regeln sind wertvoller als viele weiche.

Drittens: Eine Registry anlegen. Nicht im Kopf, nicht als Kommentar im Code. Eine strukturierte Datei, die für jede Regel enthält: was sie prüft, warum sie existiert, wann sie zuletzt ausgelöst hat.

# guards/registry.yaml
guards:
  - id: SEC-007
    name: api_key_in_commit
    severity: critical
    enforcement: hard_block
    last_triggered: 2026-08-21T02:47:00Z
    trigger_count_30d: 3

Das gibt Sichtbarkeit. Und Sichtbarkeit ist die Voraussetzung für jede sinnvolle Weiterentwicklung.

Wichtigste Erkenntnisse

• Guards entstehen aus Incidents, nicht aus Spezifikationen. Wer wartet, bis er weiß, was er braucht, wartet zu lang.
• Hard-Block schlägt Advisory. Advisory-Regeln geben das Gefühl von Kontrolle, Hard-Blocks geben tatsächliche Kontrolle.
• Jede Regel braucht eine Begründung. Ohne Incident-Referenz oder Rationale ist jede Regel nach einem Jahr tot.
• Autonomie und Regelwerk sind kein Widerspruch. Das Regelwerk ist die Voraussetzung, dass Autonomie sicher funktioniert.
• Das Modell ist austauschbar. Das Regelwerk nicht. Nach 14 Monaten habe ich drei verschiedene Modelle eingesetzt. Die Guards liefen durch.

---

Das Buch: Taschenbuch (24,99 EUR) https://amazon.de/dp/B0HDMT162J | E-Book (9,99 EUR) https://amazon.de/dp/B0HDMS2YQ9

---

Dieser Artikel wurde mit KI erstellt, auf Basis meiner eigenen Systeme und Praxiserfahrung.