Der Agent hat die Sandbox nie verlassen

Ein Coding-Agent läuft in einer Sandbox, damit, wenn er etwas Leichtsinniges tut — und das wird er, denn er liest den ganzen Tag nicht vertrauenswürdigen Text und glaubt den meisten davon —, der Schaden an der Sandbox-Mauer endet. Das ist das Versprechen. Am 20. Juli 2026 veröffentlichte Pillar Security sieben Wege, auf denen das Versprechen bricht, in vier der meistgenutzten Agenten: Cursor, OpenAIs Codex CLI, Googles Gemini CLI und Antigravity. BleepingComputer berichtete in derselben Woche.

Sieben ist nicht die überraschende Zahl. Was die sieben gemeinsam haben, ist dies: in den Worten der Forscher selbst, „in fast jedem Fall musste der Agent die Sandbox nicht direkt durchbrechen. Er musste nur etwas schreiben, das eine vertrauenswürdige Komponente außerhalb der Sandbox später ausführen, laden, scannen oder als sicher behandeln würde."

Der Zug: drinnen bleiben, eine Datei schreiben, den Host sie ausführen lassen

Denken Sie daran, was die Sandbox eines Coding-Agenten tatsächlich enthält. Sie enthält den Prozess des Agenten — das, was die Entscheidungen des Modells ausführt. Sie enthält nicht die Dateien des Agenten, denn die ganze Aufgabe besteht darin, Dateien zu schreiben: Quellcode, Konfigurationen, Build-Skripte. Diese Dateien landen auf derselben Festplatte, die Ihre anderen Werkzeuge lesen. Und Ihre anderen Werkzeuge sind nicht in einer Sandbox. Die Python-Erweiterung Ihres Editors ist nicht in einer Sandbox. Ihr git ist nicht in einer Sandbox. Der Docker-Daemon ist nicht in einer Sandbox. Sie vertrauen dem, was auf der Festplatte liegt, denn bis vor Kurzem war das Einzige, was auf diese Festplatte schrieb, Sie selbst.

Also berührt der Agent die Mauer nie. Er schreibt eine Datei genau dorthin, wo er soll, und wartet darauf, dass etwas auf der anderen Seite sie liest. Pillars sieben Ausbrüche sind sieben Versionen dieses einen Zugs:

Antigravity fügte zwei weitere derselben Form hinzu — eine macOS-Seatbelt-Sperrliste, die einen Fall übersah, und eine VS-Code-Task-Konfiguration, die der Agent schrieb und die die IDE später von selbst ausführte. Beide galten als schwerer durchzuführen, reimen sich aber auf den Rest.

Warum das Patchen jedes Einzelnen die Form nicht schließt

Jeder davon bekam einen Fix, und es sind gute Fixes. Cursor lieferte 3.0.0 aus, das Codex CLI lieferte 0.95.0 aus, das Docker-Socket wurde abgeriegelt. Wenn Sie diese Werkzeuge nutzen, aktualisieren Sie sie. Aber sehen Sie, was ein Fix hier leisten muss. Er muss jede Datei finden, die der Agent schreiben kann und die ein anderes Programm als Anweisungen behandelt — Hook-Konfigurationen, Interpreter-Pfade, git-Metadaten, Task-Definitionen, Lint-Regeln, was auch immer nächstes Quartal erscheint — und jede als Sonderfall behandeln. Das ist eine Sperrliste, und Pillar nennt Sperrlisten als den ersten von vier wiederkehrenden Fehlermodi, weil „ein Sandbox-Profil, das von ‚standardmäßig erlauben' ausgeht, sich jede gefährliche Operation merken muss, die das OS bereitstellt". Das OS fügt ständig Operationen hinzu. Die Liste ist nie fertig.

Der tiefere Grund ist ein Satz im Bericht, der sich wie eine Definition liest: „Wenn ein Agent die künftigen Eingaben von Systemen schreiben darf, war er von vornherein nie in einer Sandbox." Eine Grenze, die um den Prozess des Agenten gezogen wird, auf einer Maschine, auf der der Agent eine Festplatte und eine Reihe vertrauenswürdiger Daemons mit allem anderen teilt, ist um das Falsche gezogen. Der Wirkungsradius, schreiben sie, „ist nicht der Prozess des Agenten; er umfasst alles, was der Agent schreiben kann und dem der Host später vertraut". Auf dem Laptop eines Entwicklers ist das nahezu alles.

Wo Bromure die Linie zieht

Bromure Agentic Coding versucht nicht, die gefährlichen Dateien aufzuzählen oder der Sandbox Hooks, virtuelle Environments und Task-Runner beizubringen. Es verschiebt die Grenze. Der Agent jedes Profils läuft in einer wegwerfbaren Linux-VM auf Apple Silicon, einen Hypervisor von macOS entfernt. In diesem Modell ist das „vertrauenswürdige Werkzeug außerhalb der Sandbox" — die Python-Erweiterung Ihres Editors, Ihr git, der Docker-Daemon, der Task-Runner der IDE — nicht auf der anderen Seite einer Berechtigungsmauer. Es ist auf der anderen Seite eines Hypervisors und liest die Festplatte der VM überhaupt nicht.

Das ist der ganze Unterschied. Pillars Zug braucht zwei Dinge am selben Ort: eine Festplatte, die der Agent beschreiben kann, und ein vertrauenswürdiges Programm, das diese Festplatte liest. Legen Sie die Festplatte des Agenten in die VM, und das zweite Ding ist weg. Der Agent kann eine Hook-Konfiguration schreiben, einen Interpreter im virtuellen Environment austauschen, eine Task-Definition platzieren — jede Datei aus allen sieben Ausbrüchen — und es gibt kein nicht sandboxiertes Host-Werkzeug, das dieses Dateisystem beobachtet, um sie aufzugreifen. Was auch läuft, läuft in der Box, als der wegwerfbare Benutzer ubuntu in einer Maschine, die nichts enthält.

Es gibt eine zweite Hälfte der Ausbrüche, die zu benennen sich lohnt, weil Bromure auch sie beantwortet. Angenommen, eine vom Agenten geschriebene Datei wird tatsächlich von einem Werkzeug innerhalb der VM ausgeführt — der Sinn, Code auszuführen, ist meist, etwas zu stehlen oder irgendwohin zu gelangen. Beides sind hier Sackgassen. Der Code geht auf die Anmeldedaten los, die die Reise lohnenswert machen, den Anthropic-Schlüssel, die AWS-Schlüssel, das GitHub-Token, und findet Köder: ein Credential-Broker auf dem Host injiziert Platzhalter wie brm_…, eine synthetische kubeconfig und einen wegwerfbaren SSH-Schlüssel und tauscht den echten Wert erst an der Netzwerkgrenze ein, bei Anfragen an Ziele, die Sie bereits genehmigt haben. Und der ausgehende Schritt — die Beute exfiltrieren oder einen zweiten Host erreichen — überquert den Host-Proxy, wo das wahre Ziel auf dem Weg nach draußen gefiltert wird und wo eine zerstörerische Aktion gegen die Cloud- und git-APIs, die das Profil vorschaltet, ein Delete, ein Drop oder ein Terminate, auf einen Schutzmechanismus trifft, der sie ablehnen kann, egal wozu der Agent überredet wurde.

Vor all dem sitzt die Schicht, die diese Ausbrüche an der Wurzel fasst. Jeder beginnt mit einer Injection — einer bösartigen Anweisung in einer Datei oder einem Tool-Ergebnis, das der Agent liest, die ihm sagt, überhaupt erst die vergiftete Konfiguration zu schreiben. Bromure bewertet diesen nicht vertrauenswürdigen Inhalt mit einem Injection-Detektor auf dem Gerät, bevor das Modell darauf reagiert. Er fängt das meiste davon, und eine hinreichend neuartige Nutzlast kann einen Klassifikator noch immer passieren, was genau der Grund ist, warum er vor der wegwerfbaren Box sitzt und nicht an ihrer Stelle.

Die Grenze war um das Falsche gezogen

Die bleibende Lehre aus Pillars Woche ist keine Liste von sieben zu patchenden Bugs. Sie ist, dass das Sandboxen des Agenten-Prozesses, auf einer Maschine, auf der dieser Prozess eine Festplatte und eine Reihe vertrauenswürdiger Werkzeuge mit allem teilt, was Ihnen gehört, die Linie um das Falsche zieht. Der Agent muss nicht ausbrechen, wenn er die Eingaben zu etwas schreiben kann, das bereits draußen ist.

Die bekannten Dateien zu patchen ist richtig, und Sie sollten es tun. Aber es ist ein Rennen gegen jedes künftige Format, dem ein Host-Werkzeug zu vertrauen beschließt, und dieses Rennen endet nicht. Bromure Agentic Coding steigt aus. Es geht davon aus, dass der Agent dazu überredet wird, die vergiftete Datei zu schreiben, und sorgt dafür, dass, wenn ein Werkzeug sie liest, dieses Werkzeug in einer wegwerfbaren Box mit Ködern für die Geheimnisse und einem Filter auf der Leitung ist — nicht Ihr Laptop, der Ihre Schlüssel hält. Das ist der Unterschied zwischen einer Mauer, die Sie ständig patchen müssen, und einer Linie, die eine Ebene tiefer gezogen ist, wo das Schreiben keinen Leser hat. Installieren Sie es und geben Sie Ihrem Agenten eine Maschine, die nicht Ihre ist, um sie zu verlieren.