Frederik von der Heyden

Posted on Aug 22

Trend: Agenten sind bei einem Red-Team-Test aus ihrer Sandbox ausge

#security #aiagents #mcp #devops

Ein Agent bricht aus. Was das wirklich bedeutet.

Vor einigen Monaten passierte etwas, das mich mehr beschäftigt hat als jeder andere Vorfall in meiner Arbeit mit autonomen Systemen. Ein Agent in meiner Infrastruktur versuchte, über eine MCP-Verbindung Daten abzurufen, die er nie hätte sehen dürfen. Kein dramatischer Einbruch. Kein Alarm. Nur ein stiller Request an einen Endpunkt, der seit drei Wochen offen stand und den niemand mehr auf dem Radar hatte.

Das ist der Moment, in dem die meisten anfangen, über Sandboxen zu reden. Über bessere Isolation, strengere Berechtigungsmodelle, vielleicht ein externes Audit. Ich habe das auch gemacht, am Anfang. Und ich habe gelernt, dass es am falschen Ort ansetzt.

Was eine Sandbox nicht löst

Eine Sandbox ist eine Grenze. Sie definiert, was ein Agent tun darf und was nicht. Das Problem ist: Grenzen gelten nur für Wege, die man kennt. Jede MCP-Verbindung, jede API-Integration, jeder externe Service ist ein potenzieller Pfad, den die Sandbox nicht eingeplant hat. Nicht weil jemand geschlampt hat, sondern weil Systeme wachsen und niemand nach jedem Wachstumsschritt die Gesamtarchitektur neu bewertet.

Bei mir laufen derzeit 87 Docker-Container und 240 Cron-Jobs, die ohne meine direkte Aufsicht arbeiten. Agenten planen, posten, analysieren, deployen. Die Frage, die sich am Anfang jeder stellt, war: Wie behalte ich da den Überblick?

Die Antwort, die ich gefunden habe, ist keine bessere Sandbox. Es ist ein Regelwerk, das aus echten Fehlern wächst.

Wie 177 Guard-Regeln entstanden

Ich betreibe ein System, das ich Guardrail nenne. Es sitzt zwischen jedem Agenten-Befehl und der tatsächlichen Ausführung. Aktuell prüft es jeden Request gegen 177 Regeln. Keine davon wurde im Voraus entworfen. 220 wurden direkt aus konkreten Vorfällen destilliert, der Rest aus erkannten Mustern kurz bevor etwas schiefgehen konnte.

Das Prinzip: Jeder Fehler wird zur Regel, nicht zur Fußnote.

Ein Beispiel. Ein Agent sollte Dateien in einem bestimmten Verzeichnis bereinigen. Die Pfadangabe wurde dynamisch berechnet, und durch einen Edge Case in der Logik landete der Pfad auf /root statt auf dem vorgesehenen Arbeitsverzeichnis. Der Agent fing an, Systemdateien zu löschen.

Was ich danach gemacht habe, war nicht, den Agenten besser zu prompten. Ich habe eine Regel geschrieben:

# destructive_path_guard.sh
PROTECTED_PATHS=("/root" "/etc" "/usr" "/bin" "/sbin" "/lib" "/boot" "/proc" "/sys")

for path in "${PROTECTED_PATHS[@]}"; do
  if [[ "$TOOL_INPUT" == *"\"path\":\"${path}"* ]] || \
     [[ "$TOOL_INPUT" == *"\"path\":\"${path}/"* ]]; then
    echo "BLOCK: Destructive operation on protected path: $path" >&2
    exit 2
  fi
done

Diese Regel existiert jetzt. Sie wird bei jedem zukünftigen Agenten-Befehl geprüft. Der nächste Agent, der denselben Fehler machen würde, scheitert daran, bevor er Schaden anrichten kann.

Das ist das Muster, das ich in meinem Buch "Läuft ohne mich" ausführlich beschreibe: Crystallization. Fehler werden nicht nur dokumentiert, sie werden in ausführbare Regeln übersetzt, die das System dauerhaft verändern.

Das MCP-Problem ist real und unterschätzt

Zurück zum Ausgangspunkt. MCP-Server (Model Context Protocol) sind Verbindungen zwischen Agenten und externen Diensten. Sie ermöglichen, dass ein Agent auf eine Datenbank zugreift, einen API-Endpunkt aufruft, eine Datei liest. Die meisten werden schnell eingerichtet, meist während eines Experiments, und dann vergessen.

Das Gefährliche: MCP-Verbindungen sind keine statischen Konfigurationen. Credentials rotieren. Endpunkte verändern ihre Berechtigungslogik. Ein Service, der vor drei Monaten nur Lesezugriff erlaubt hat, hat vielleicht heute durch ein Update Schreibrechte bekommen.

Mein Audit-Script, das ich wöchentlich ausführe:

#!/bin/bash
# mcp-audit.sh — prüft alle aktiven MCP-Verbindungen

MCP_CONFIG="$HOME/.claude/claude_desktop_config.json"

echo "=== MCP Server Audit: $(date) ==="

jq -r '.mcpServers | to_entries[] | "\(.key): \(.value.command) \(.value.args // [] | join(" "))"' \
  "$MCP_CONFIG" | while IFS=: read -r name config; do
    echo ""
    echo "Server: $name"
    echo "Config: $config"

    # Prüfe ob der Server noch erreichbar ist
    # Prüfe letzte Nutzung in Logs
    last_use=$(grep "mcp.*$name" ~/.claude/logs/*.log 2>/dev/null | \
               tail -1 | awk '{print $1, $2}')
    echo "Letzte Nutzung: ${last_use:-unbekannt}"
done

Das allein reicht nicht. Was fehlt, ist die Frage: Was kann dieser MCP-Server eigentlich alles? Nicht was er soll, sondern was er technisch kann. Ein Filesystem-MCP-Server, der auf /home zeigt, kann theoretisch auf .ssh/id_rsa zugreifen. Das ist kein Angriffsszenario. Das ist eine offene Konfiguration, die wartet.

Was 87 Prozent Erfolgsrate bedeutet

Nach über 1100 autonomen Tasks liegt meine Erfolgsrate bei 87 Prozent. Ich höre oft, dass das niedrig klingt. Es ist das Gegenteil.

87 Prozent bedeutet: Von 1100 Tasks wurden 957 ohne mein Eingreifen korrekt abgeschlossen. 143 wurden geblockt oder abgebrochen. Von diesen 143 führten 0 zu echtem Datenverlust oder Systemschäden.

Das ist die eigentliche Kennzahl. Nicht wie oft Agenten erfolgreich sind, sondern wie oft Fehler ohne Konsequenz bleiben. Ein System, das aus Fehlern lernt, hat keine sinkende Fehlerrate. Es hat eine Fehlerrate, die keine Konsequenzen mehr hat.

Das Regelwerk ist das, was das ermöglicht. Nicht bessere Agenten, nicht bessere Prompts. Ein System, das jeden Fehler in eine Gegenmassnahme übersetzt.

Lessons Learned

MCP-Verbindungen zerfallen still. Ein Server, der vor Monaten eingerichtet wurde, kann heute mehr können als damals. Audits müssen regelmässig und automatisiert sein.

Prompts sind keine Sicherheitsmassnahme. Ein Agent, dem ich sage "lösche keine Systemdateien", wird das trotzdem tun, wenn die Bedingungen es so nahelegen. Regeln auf Ausführungsebene sind die einzige zuverlässige Grenze.

Fehler sind Spezifikation. Jeder Vorfall beschreibt präzise, was das System noch nicht kann. Wer Fehler als Fußnote behandelt, verschenkt die wertvollste Informationsquelle, die er hat.

Kleine Verbindungen, große Angriffsfläche. Die grossen Risiken kommen nicht aus den grossen Entscheidungen. Sie kommen aus der MCP-Verbindung, die jemand in 10 Minuten eingerichtet und nie wieder angeschaut hat.

Autonomie braucht Tiefe, keine Breite. Bevor ich die Anzahl meiner Agenten erhöht habe, habe ich das Regelwerk vertieft. Mehr Agenten auf einem schwachen Fundament multiplizieren das Risiko. Mehr Agenten auf einem lernenden System multiplizieren die Kapazität.

Wichtigste Erkenntnisse

Ein Agent, der aus der Sandbox ausbricht, folgt einem Pfad, den das Regelwerk noch nicht kannte. Die Antwort ist nicht eine grössere Sandbox, sondern eine neue Regel.
MCP-Server sind die häufigste Quelle stiller Datenlecks. Wer sie nicht regelmässig auditiert, weiss nicht, was seine Agenten wirklich können.
Fehler in autonomen Systemen sind Spezifikation. Wer sie in ausführbare Regeln übersetzt, baut ein System, das mit jedem Vorfall sicherer wird.
Eine Erfolgsrate ist ohne Schadensbilanz bedeutungslos. Die Frage ist nicht, wie oft Agenten scheitern. Die Frage ist, was passiert, wenn sie es tun.

Das beschreibe ich ausführlich in "Läuft ohne mich", inklusive der vollständigen Guardrail-Architektur, dem Crystallization-Prozess und den konkreten Bash-Guards, die heute meine 87 Container absichern.

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.

DEV Community