Der Tag, an dem mein Agent beinahe einen Passwort-Hash geloggt hätte
Es war der 26. Juni, kurz nach 14 Uhr. Mein Agent arbeitete an einer Datenbankanalyse. Ein Verbindungsfehler war aufgetreten, und der Agent tat genau das, was er tun sollte: Er dokumentierte den Kontext vollständig, um das Problem nachvollziehbar zu machen.
Drei Millisekunden, bevor die Log-Datei gespeichert wurde, hat mein PII-Gate-Guard den Schreibvorgang gestoppt.
Ich habe davon erst abends erfahren. Im Protokoll. Und in diesem Moment wurde mir klar, dass ich mein gesamtes Sicherheitsdenken neu kalibrieren musste.
Was tatsächlich passiert ist
Der Agent analysierte einen psycopg2-Fehler. Im Stacktrace war die Connection-String-Variable enthalten. In dieser Variable steckte der Datenbankbenutzer und, für Testzwecke noch nicht rotiert, ein gehashtes Passwort.
Der Agent hatte keine böse Absicht. Er hat nicht versucht, Daten zu stehlen. Er hat versucht, gründlich zu sein. Er wollte den vollständigen Fehlerkontext dokumentieren, damit ich das Problem am nächsten Morgen schnell nachvollziehen kann.
Korrekt gedacht. Falsch gehandelt.
Das ist der Unterschied, den viele beim Einsatz von KI-Agenten unterschätzen: Ein Schaden entsteht nicht durch bösartige Absicht. Er entsteht durch Gründlichkeit ohne Kontextbewusstsein.
Wie der PII-Gate-Guard funktioniert
Bevor ich die vier neuen Regeln erkläre, die aus diesem Vorfall entstanden sind, hier der Kern des Systems.
Der Guard läuft als Shell-Hook, der jeden Schreibvorgang abfängt, bevor er ausgeführt wird. Er prüft den Inhalt gegen eine Liste von Mustern für personenbezogene und sicherheitsrelevante Daten.
#!/bin/bash
# pii-gate-guard.sh - wird vor jedem file-write ausgeführt
CONTENT="$1"
FILE="$2"
# Muster für kritische Inhalte
PATTERNS=(
'[0-9a-f]{32,}' # MD5/SHA Hashes
'password\s*[:=]\s*\S+' # Passwort-Zuweisungen
'\b[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}\b' # E-Mail-Adressen
'postgresql://[^@]+@' # DB-Connection-Strings mit Credentials
'sk-[a-zA-Z0-9]{32,}' # API-Keys (OpenAI-Format)
)
for pattern in "${PATTERNS[@]}"; do
if echo "$CONTENT" | grep -qiE "$pattern"; then
echo "PII_GATE_BLOCKED: Muster '$pattern' in '$FILE' erkannt" >> ~/.claude/pii-gate.log
exit 1
fi
done
exit 0
Das Prinzip: Der Guard scheitert sicher. Wenn er unsicher ist, blockiert er. Der Agent muss dann explizit eine bereinigte Version des Inhalts liefern.
Die vier Regeln, die danach entstanden sind
Regel 1: Kein vollständiger Stacktrace in Log-Dateien
Stacktraces enthalten oft mehr als nur Zeilennummern. Sie enthalten Variablennamen, manchmal Variableninhalte, Pfade, Konfigurationsdetails. Die neue Regel: Stacktraces werden immer bereinigt, bevor sie persistiert werden.
import re
def sanitize_stacktrace(trace: str) -> str:
# Connection strings entfernen
trace = re.sub(r'postgresql://[^\s\'"]+', '[REDACTED_DB_URL]', trace)
# API Keys entfernen
trace = re.sub(r'sk-[a-zA-Z0-9]{20,}', '[REDACTED_KEY]', trace)
# E-Mail-Adressen ersetzen
trace = re.sub(r'\b[\w.+-]+@[\w-]+\.[a-zA-Z]{2,}\b', '[REDACTED_EMAIL]', trace)
return trace
Regel 2: Umgebungsvariablen sind tabu in Logs
Der Agent hatte Zugriff auf die Umgebungsvariablen des laufenden Prozesses. Das ist normal und notwendig. Aber er darf sie nicht loggen. Punkt. Die Regel ist absolut, ohne Ausnahme.
Regel 3: Jede Log-Datei bekommt einen Sensitivity-Tag
# log-config.yaml
logs:
debug.log:
sensitivity: low
pii_check: false
agent-actions.log:
sensitivity: high
pii_check: true
requires_review: true
Dateien mit sensitivity: high werden nicht nur vor dem Schreiben geprüft. Sie werden nach 24 Stunden automatisch rotiert und lokal verschlüsselt.
Regel 4: Der "Nachtmodus" schränkt Schreibrechte ein
Zwischen 22 Uhr und 6 Uhr läuft der Agent im eingeschränkten Modus. Kein Schreiben in Dateien außerhalb eines definierten /tmp/agent-sandbox-Verzeichnisses. Alles andere landet in einer Review-Queue und wartet auf meine manuelle Freigabe am Morgen.
Was die Zahlen erzählen
Seit ich das System konsequent betreibe, hat der PII-Gate-Guard bei 1.448 autonomen Tasks 147 Schreibvorgänge gestoppt. Das sind 10,2 Prozent aller Tasks.
Ich fand diese Zahl anfangs erschreckend hoch. Inzwischen sehe ich sie als Qualitätsmerkmal. Der Guard stoppt nicht nur kritische Vorfälle. Er stoppt auch Grenzfälle, bei denen der Agent konservativ handeln sollte, es aber nicht von selbst täte.
Die Verteilung der Blockierungen:
- 61 Prozent: Verdächtige Muster in Stacktraces oder Fehlerausgaben
- 23 Prozent: Pfade, die auf sensitive Konfigurationsdateien hindeuten
- 11 Prozent: Mögliche Hashes oder kodierte Strings
- 5 Prozent: Tatsächliche PII wie E-Mail-Adressen oder Namen
Das ist keine Statistik. Das sind 147 Vorfälle, die nie passiert sind.
Was das bedeutet, wenn der Agent nachts arbeitet
Ich lasse meinen Agenten eigenständig arbeiten. Nachts. Wochentags. Manchmal am Wochenende. Er schreibt Code, analysiert Fehler, erstellt Berichte, beantwortet Monitoring-Alerts.
In dieser Zeit kann ich nicht jeden Schritt überwachen. Das ist der Sinn des Systems.
Aber genau deshalb brauche ich Guardrails, die unabhängig von meiner Anwesenheit funktionieren. Nicht als Kompensation für einen schlechten Agenten, sondern als strukturelles Sicherheitsnetz für einen grundsätzlich guten Agenten, der in einem bestimmten Moment nicht den richtigen Kontext hat.
Das Grundprinzip lautet: Vertrauen durch Struktur, nicht durch Hoffnung.
Das beschreibe ich ausführlich in "Läuft ohne mich", weil es eine der Kernfragen jedes Solounternehmers ist, der KI-Agenten produktiv einsetzt: Wie schafft man echte Autonomie, ohne die Kontrolle zu verlieren?
Die DSGVO-Dimension, die viele übersehen
Ein Passwort-Hash in einer Log-Datei ist nicht harmlos, weil er "nur" ein Hash ist. Wenn dieser Hash einem Nutzer zugeordnet werden kann, ist er personenbezogenes Datum im Sinne der DSGVO.
Eine Log-Datei, die in einem Git-Repository landet, ist potenziell dauerhaft sichtbar. Auch nach dem Löschen, denn Git-History.
Ein solcher Vorfall wäre meldepflichtig. 72 Stunden Frist. Benachrichtigung der Betroffenen. Mögliche Bußgelder.
Das ist keine hypothetische Bedrohung. Das ist die reale Konsequenz eines realen Vorfalls, der am 26. Juni um 14 Uhr und drei Millisekunden nicht stattgefunden hat.
Wichtigste Erkenntnisse
1. KI-Agenten scheitern durch Gründlichkeit, nicht durch Böswilligkeit. Der gefährlichste Moment ist nicht, wenn der Agent etwas Falsches tut. Es ist, wenn er etwas Richtiges falsch tut.
2. Guardrails müssen automatisch und still funktionieren. Ich habe von dem Block erst abends erfahren. Das ist kein Versagen. Das ist der Beweis, dass das System funktioniert.
3. 10 Prozent Blockierungsrate ist kein Problem. Es ist ein Frühwarnsystem. Wer keinerlei Blockierungen sieht, hat entweder keine Guardrails oder zu weiche.
4. Die DSGVO unterscheidet nicht zwischen menschlichem und maschinellem Handeln. Ein Datenleck durch einen KI-Agenten ist genauso meldepflichtig wie eines durch einen Menschen.
5. Nachtmodus ist kein Misstrauen, sondern Systemdesign. Eingeschränkte Schreibrechte in autonomen Phasen sind kein Zeichen, dass man dem Agenten nicht vertraut. Sie sind Architektur.
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.
Top comments (0)