Ihr Agent ist nie aus der Sandbox ausgebrochen. Er musste nicht.

Was ist ein Sandbox-Ausbruch bei einem Coding-Agenten?

Meist überhaupt kein Ausbruch. In den 2026 offengelegten Fällen brach der Agent nicht aus seinem Container aus, überwand keinen Hypervisor und nutzte keinen Kernel-Fehler. Er nutzte seine ganz gewöhnliche, vorgesehene Fähigkeit, Dateien in dem Projekt zu schreiben, an dem er arbeitete, und eine dieser Dateien war zufällig die Eingabe eines Programms, das mit den vollen Rechten des Nutzers läuft.

Hier ist der offengelegte Satz. Er lohnt sich als Liste, weil das Muster erst in der Summe sichtbar wird.

Lesen Sie die dritte Spalte von oben nach unten. Vier der sieben sind ein Schreibvorgang, kein Ausbruch. Der Agent erzeugte eine Datei, ein vertrauenswürdiger Prozess konsumierte sie, und dieser Prozess war nicht in der Box.

“

Wenn ein Agent die künftigen Eingaben von Systemen schreiben darf, war er nie in einer Sandbox.

Die CSA nennt das den Trust Handoff Flaw und definiert es präzise: Der Agent „bleibt in der Box und befolgt jede Regel", schreibt aber eine Datei, eine Hook-Konfiguration, einen Interpreter einer virtuellen Umgebung, einen Git-Config-Eintrag, eine Task-Definition, „die irgendein anderes, nicht isoliertes Werkzeug konsumiert, nachdem der Zug des Agenten geendet hat".

Diese Definition leistet mehr, als sie zunächst wirkt. Sie verschiebt die Sicherheitsgrenze von einem Ort, den Sie konfigurieren können, zu einer Beziehung, die Sie mit einiger Wahrscheinlichkeit nie inventarisiert haben: die Menge der Programme auf dem Entwicklerrechner, die projektlokale Dateien lesen und danach handeln, ohne zu fragen.

Warum versagen Sandboxes immer auf dieselbe Weise?

Weil im Sandbox-Design vier Annahmen immer wiederkehren, und das Verhalten eines Agenten macht alle vier ungültig. Die CSA-Notiz benennt sie, und man sollte sie als Entwurfsfehler und nicht als Bugs formulieren, weil jede einzelne im nächsten Produkt wiederkehren wird, das einen Agenten ausliefert.

Nichts davon ist exotisch. Es sind die klassischen Fehlermodi der Perimetersicherheit, wiederentdeckt an einem neuen Ort, von Teams, die schnell in eine Kategorie liefern, die es vor zwei Jahren nicht gab.

GitSpawn: dieselbe Schwäche, in der Datei, die jedes Repository hat

Falls das Muster noch abstrakt klingt, macht die Offenlegung von Manifold Security Anfang September 2026 es konkret, und sie ist die sauberste Illustration des gesamten Arguments.

core.fsmonitor ist eine Git-Performance-Einstellung. Ihr Wert ist ein Kommando, das Git ausführt, um zu ermitteln, welche Dateien sich geändert haben. Git liest ihn aus der .git/config des Repositories selbst. Coding-Agenten rufen Git beim Start auf, um Branch und geänderte Dateien zu bestimmen, also läuft das Kommando sofort, mit den Rechten des Nutzers, bevor überhaupt ein Bestätigungsdialog existiert, den man zeigen könnte.

Ein Repository zu klonen genügt inzwischen. Keine bösartige Abhängigkeit, kein Post-Install-Skript, kein Code zum Prüfen und nichts, was ein Scanner beim Lesen von Quelldateien melden würde. Die Nutzlast steckt in einer Konfigurationsdatei, die die meisten Entwickler nie geöffnet haben.

Zwei Details verdienen Betonung. Erstens sind die Fixes pfad- und nicht klassenbezogen: Manifold meldete einen zweiten Weg in Claude Code, der in 2.1.252 noch offen war, nachdem der erste gepatcht worden war. Zweitens waren mehrere Agenten zum Zeitpunkt der Offenlegung noch als verwundbar bestätigt. Wenn Ihre Kontrolle lautet „wir haben aktualisiert", dann hat Ihre Kontrolle eine Versionsnummer und eine Race Condition eingebaut.

Die von Manifold empfohlene Gegenmaßnahme lohnt sich heute, passt in ein Kommando und zeigt gut, wie schmal ein Fix pro Einzelfall ist:

# Ein Repository pruefen, das Sie mit einem Agenten oeffnen wollen
git config --get core.fsmonitor

# Den Mechanismus global abschalten
git config --global core.fsmonitor false

# Oder ihn bei einzelnen Hintergrundaufrufen entfernen
git -c core.fsmonitor=false status

Das schließt core.fsmonitor. Es tut nichts für core.hooksPath, für .vscode/tasks.json, für einen venv-Interpreter, für einen .claude-Hook oder für den nächsten Konfigurationsschlüssel, bei dem jemand bemerkt, dass er ausführbar ist. Eine Entwurfseigenschaft lässt sich nicht wegpatchen.

Was eine Sandbox tatsächlich abdeckt und was nicht

Der Fairness halber gegenüber Sandboxing, das wirklich betrieben werden sollte: Es leistet echte Arbeit, und die ist nicht wenig. Sie ist nur schmaler als die Rhetorik darum herum.

Die letzten vier Zeilen sind die entscheidenden, und sie teilen eine Eigenschaft: Der Agent tut nichts Verbotenes. Perimeterkontrollen erkennen Grenzverletzungen. Keine dieser Zeilen ist eine.

Ein weiteres Versagen gehört hierher, weil es das menschlichste von allen ist. Im März 2026 wurde ein Issue gegen Claude Code eröffnet, das meldete, die sandbox-Einstellung in ~/.claude/settings.json werde nicht angewandt, wenn der Agent innerhalb der VS-Code- oder Cursor-Erweiterung lief: Die Erweiterung startete die native Binärdatei ohne die Option --sandbox, sodass das macOS-Seatbelt-Profil selbst bei sandbox.enabled: true nie angewandt wurde. Die meldende Person bestätigte es, indem sie aus einer Cursor-Sitzung heraus eine Datei nach ~/Desktop schrieb. Das Issue wurde als Duplikat geschlossen, und der vorgeschlagene Workaround war, die CLI direkt zu starten oder PreToolUse-Hooks als Ersatzwächter zu verwenden.

Wie auch immer der Status heute ist, die Problemklasse ist dauerhaft: Eine Sandbox ist eine Konfiguration, Konfigurationen haben Oberflächen, auf denen sie stillschweigend nicht greifen, und eine Kontrolle, die Sie für aktiv halten, ist schlimmer als eine, von der Sie wissen, dass sie aus ist.

Was also tun?

Behalten Sie die Sandbox. Hören Sie auf, sie als die Kontrolle zu behandeln. Und schließen Sie dann die Übergabe, wo die eigentliche Exposition liegt.

Das ist der Schritt, den niemand macht, und der, den die CSA einfordert. Listen Sie die Programme auf einem Entwicklerrechner auf, die Dateien aus dem Arbeitsverzeichnis konsumieren und danach handeln: Editor und Erweiterungen, Language Server, Git-Client, Shell-Profil, Container-Runtime, Task-Runner, Test-Watcher. Diese Liste ist Ihre echte Angriffsfläche. Die Sandbox steht nicht darauf. Für Einrichtungen im Anwendungsbereich von NIS2 ist eine solche Bestandsaufnahme ohnehin Teil der geforderten Risikoanalyse.

Eine Denylist verlangt, dass Sie das Betriebssystem aufgezählt haben. Eine Allowlist verlangt, dass Sie Ihren eigenen Arbeitsablauf aufgezählt haben, und das ist eine Aufgabe, die Sie tatsächlich abschließen können. Und prüfen Sie, was ein Kommando tut, nicht wie es heißt: git show stand wegen seines Namens auf einer Allowlist.

Keine Agentensitzung sollte den Docker-Socket, die Kubernetes-Config oder irgendeinen lokalen Endpunkt erreichen können, der privilegierter ist als sie selbst. Das ist kostenlos und hat bei drei Produkten eine ganze Klasse entfernt.

Eine Änderung an .git/config, .vscode/, .claude/, .cursor/, an einem Virtualenv-Interpreter oder an einem CI-Workflow ist keine Codeänderung. Sie ist eine Änderung daran, was als Nächstes ausgeführt wird. Sie verdient einen anderen Freigabeweg als eine React-Komponente, und heute bekommt sie meist denselben.

Umgebungsvariablen reisen mit dem Prozess. Eine perfekt isolierte Sandbox, die AWS_SECRET_ACCESS_KEY erbt, hat das Dateisystem isoliert und die Zugangsdaten veröffentlicht.

Jeder Punkt oben ist eine Härtungsmaßnahme, um die ein entschlossener Pfad irgendwann herumführt, weil sie alle statisch sind. Was die Klasse schließt, ist die Bewertung der Handlung in dem Moment, in dem sie geschieht, mit der Möglichkeit, sie abzulehnen.

An diesem letzten Schritt sitzt unser eigenes Produkt, lesen Sie die nächsten drei Absätze also mit diesem Wissen. Dass wir es für eine Folge der Belege und nicht unserer Roadmap halten, liegt daran, dass die CSA ohne etwas zu verkaufen zur selben strukturellen Schlussfolgerung kam, und dass der Workaround im Issue-Tracker von Anthropic selbst ein PreToolUse-Hook war.

Ein Hook sitzt dort, wo die Sandbox nicht sitzen kann. Er bewertet einen Tool-Aufruf, bevor er ausgeführt wird, das heißt er sieht den Schreibvorgang selbst: Diese Sitzung will gleich .git/config ändern, oder einen core.hooksPath ergänzen, oder eine Workflow-Datei bearbeiten, die bei Fork-Ereignissen mit Schreibrechten läuft, oder ein Tool aufrufen, dessen Beschreibung sich seit gestern geändert hat. Das sind diskrete, prüfbare Ereignisse mit Subjekt und Objekt. Eine Sandbox sieht einen Prozess, der Bytes in ein erlaubtes Verzeichnis schreibt, und hat keine Grundlage für einen Einspruch, weil nichts Verbotenes geschieht.

Es ist eine andere Frage, keine dickere Mauer. Die Sandbox fragt „darf dieser Prozess hier sein". Die Sperre fragt „soll diese konkrete Handlung jetzt stattfinden". Der Trust Handoff Flaw existiert genau deshalb, weil die erste Frage eine befriedigende Antwort hat, während die zweite nie gestellt wird.

Und sie degradiert ehrlich. Regeln im Kontext des Agenten verbessern, was er vorschlägt, und das ist eine echte und probabilistische Verbesserung. Findings in der Schleife sorgen dafür, dass eine vorgeschlagene Änderung gegen den realen Zustand des Repositories durchdacht wird. Nur der Hook ist deterministisch, und wir sagen lieber, welches der drei eine Kontrolle ist, als anzudeuten, alle drei seien es. Die breite Fassung dieses Arguments steht in Sicherheit von KI-Coding-Agenten.

Häufige Fragen

Reicht eine Sandbox aus, um einen KI-Coding-Agenten abzusichern?

Nein, und die Offenlegungen von 2026 zeigen mit ungewöhnlicher Klarheit warum. Von den sieben bei Cursor, Codex CLI, Gemini CLI und Antigravity reproduzierten Ausbrüchen bestand die Mehrzahl gar nicht darin, aus der Sandbox herauszukommen. Der Agent schrieb eine Datei innerhalb seines erlaubten Workspace, und ein vertrauenswürdiger Prozess außerhalb der Sandbox führte sie später aus. Eine Sandbox begrenzt den Schaden eines Prozesses, der sich innerhalb der Grenze schlecht verhält, und das ist es wert. Gegen einen Agenten, der sich einwandfrei verhält und seine Nutzlast an etwas übergibt, das nie in der Box war, kann sie nichts ausrichten.

Was ist der Trust Handoff Flaw?

So nannte die Cloud Security Alliance in einer Forschungsnotiz vom 22. Juli 2026 das Muster hinter den Sandbox-Ausbrüchen bei Coding-Agenten im Jahr 2026. Der Agent bleibt innerhalb seiner Grenze und befolgt jede Regel, schreibt aber eine Datei, eine Hook-Konfiguration, einen Interpreter einer virtuellen Umgebung, einen Git-Config-Eintrag oder eine Task-Definition, die irgendein anderes, nicht isoliertes Werkzeug konsumiert, nachdem sein Zug beendet ist. Die Notiz fasst es so: Wenn ein Agent die künftigen Eingaben von Systemen schreiben darf, war er nie in einer Sandbox.

Welche Coding-Agenten hatten 2026 Sandbox-Ausbrüche?

Die Forschung von Pillar Security reproduzierte Ausbrüche bei Cursor, OpenAIs Codex CLI, Googles Gemini CLI und Googles Antigravity, sieben insgesamt, von denen mindestens vier einen Hersteller-Patch erhielten. Getrennt davon deckte die GitSpawn-Offenlegung von Manifold Security im September 2026 goose (CVE-2026-72718), Codex (CVE-2026-19592), Claude Code (CVE-2026-55607) und Hermes Agent (CVE-2026-71963) ab, wobei Qwen Code und Grok Build zu diesem Zeitpunkt ebenfalls als verwundbar bestätigt waren.

Kann ein Git-Repository allein durch das Öffnen Code ausführen?

Ja, und das ist der GitSpawn-Befund. core.fsmonitor ist eine Git-Performance-Einstellung, deren Wert ein Kommando ist, das Git ausführt, um zu ermitteln, welche Dateien sich geändert haben, und Git liest ihn aus der .git/config des Repositories selbst. Coding-Agenten rufen Git beim Start auf, also läuft das Kommando mit den Rechten des Nutzers, bevor ein Bestätigungsdialog erscheint. Die Prüfung ist ein Kommando, git config --get core.fsmonitor, und global abschalten geht mit git config --global core.fsmonitor false.

MicroVM, gVisor oder Container für meinen Coding-Agenten?

Wählen Sie nach Ihren Performance- und GPU-Randbedingungen, denn für diese Bedrohungsklasse spielt die Wahl kaum eine Rolle. Firecracker gibt die stärkste Isolation, gVisor ist ein vernünftiger Mittelweg mit einem Kernel im User Space, und Container sind die Untergrenze. Keine der drei ändert etwas daran, dass eine nicht isolierte Python-Erweiterung einen Interpreter ausführt, den der Agent verändert hat. Investieren Sie den Entscheidungsaufwand darin, was der Agent schreiben darf und welche lokalen Programme ihm vertrauen, und behandeln Sie die Isolationsprimitive als Einstellung für den Schadensradius.

Sandboxt die aktivierte Sandbox-Einstellung meinen Agenten wirklich?

Prüfen Sie es, statt es anzunehmen. Im März 2026 meldete ein Issue gegen Claude Code, dass sandbox.enabled: true in ~/.claude/settings.json keine Wirkung hatte, wenn der Agent innerhalb der VS-Code- oder Cursor-Erweiterung lief, weil die Erweiterung die native Binärdatei ohne die Option --sandbox startete und das macOS-Seatbelt-Profil nie angewandt wurde. Die meldende Person bestätigte es durch einen Schreibvorgang nach ~/Desktop aus einer Cursor-Sitzung. Testen Sie Ihre eigene Konfiguration, indem Sie einen Schreibvorgang außerhalb des Workspace versuchen und beobachten, ob er abgelehnt wird.

Was ist Agent-Time-Sicherheit, und wie unterscheidet sie sich vom Sandboxing?

Sandboxing stellt eine Perimeterfrage: Darf dieser Prozess an diesem Ort sein. Agent-Time-Sicherheit stellt eine Handlungsfrage: Soll diese konkrete Operation jetzt stattfinden, und sie kann ablehnen. Der Unterschied ist beim Trust Handoff Flaw entscheidend, weil der Schreibvorgang, der die spätere Ausführung auslöst, keine Perimeterverletzung ist und einer Isolationsschicht völlig legitim erscheint. Eine Sperre, die den Tool-Aufruf bewertet, sieht, dass das Ziel .git/config heißt, und lehnt ab, was keine Stärke der Isolation leisten wird.

Heißt das, Sandboxes für Agenten sind sinnlos?

Keineswegs, und sie aufzugeben wäre die falsche Lehre. Eine Sandbox begrenzt zuverlässig den Schaden einer bösartigen Abhängigkeit, eines zerstörerischen Kommandos oder einer außer Kontrolle geratenen Schleife, und das sind häufige Fälle. Die Korrektur besteht darin, sie nicht länger als Eindämmung gegenüber einem adversarialen Agenten zu beschreiben. Sie ist ein Schadensradius-Begrenzer, der neben Egress-Kontrolle, Credential-Hygiene und einem Durchsetzungspunkt auf den Handlungen selbst steht.