Sandboxes für KI-Agenten: Warum Isolation kein Opt-in ist

Was eine Sandbox leisten muss, damit man das guten Gewissens zulassen kann, und was trotz Sandboxes bei OpenAI und Co. schiefgelaufen ist.

Was vor anderthalb Jahren noch als Vibe Coding belächelt wurde, ist heute als Agentic Engineering – was immerhin so klingt, als würde wieder jemand hinschauen – aus der Softwareentwicklung nicht mehr wegzudenken. Vielen Entwicklern genügt es, Architekturentscheidungen oder die Tests des generierten Codes zu überprüfen, einige reviewen ihn im Detail. Nur die wenigsten, für die meisten von uns kaum noch vorstellbar, schreiben den Code tatsächlich noch selbst.

Auf dem Rechner eines zufällig ausgewählten Entwicklers wird man mit großer Wahrscheinlichkeit einen Coding-Agenten wie Claude Code (Anthropic), Codex (OpenAI) oder eine der vielen Open-Source-Varianten wie OpenCode oder Pi finden (inzwischen übrigens zunehmend auch bei nicht-technischen Kollegen). Im Stack Overflow Developer Survey 2026 geben zwei Drittel der KI-Nutzer an, mit Coding-Agenten zu arbeiten. Diese Agenten schreiben nicht nur Code, sondern debuggen, testen und deployen ihn auch, oder laden, Gott bewahre, Software aus dem Internet herunter und installieren sie.

Die meisten dieser Tools fragen vor solchen Aktionen um Erlaubnis. Das ist auch gut so … kann aber auch anstrengend sein. Wir würden es jedenfalls niemandem verübeln, der schon mal einen Befehl abgenickt hat, ohne ihn wirklich zu lesen. Manche Anfragen enthalten gleich mehrere Befehle, und sie kommen mehrmals pro Minute.

Ihre wahre Stärke zeigen Modelle und Harnesses – die Software, die das Modell umgibt und seine Befehle ausführt – erst, wenn man ihnen freie Hand lässt, statt sie alle zwei Minuten nachfragen zu lassen. Schaltet man die Rückfragen über Flags wie –dangerously-skip-permissions (Claude Code) oder –yolo (Codex) ab, werden ganz neue Workflows möglich. Beispielsweise könnte man am Abend eine Idee entwickeln, die Anforderungen und Architekturideen mit dem Agenten diskutieren, die Implementierung in Auftrag geben, um sich am nächsten Morgen das Ergebnis anzusehen. Wie der Name dieser Optionen verrät, ist so etwas allerdings alles andere als risikofrei.

Mehr Autonomie, mehr Risiko

Für KI-Agenten im Allgemeinen, nicht nur für Coding-Agenten, gilt: Ihr potenzieller Nutzen steigt mit zunehmender Autonomie, genau wie das Sicherheitsrisiko. Das Spektrum reicht von einfachen Chat-Anwendungen über vorgegebene Workflows bis hin zu Agenten, die vollen Systemzugriff genießen oder sogar die Identität ihres Nutzers annehmen, um Mails zu beantworten, Termine zu verwalten oder Flüge zu buchen. Wie das ausgehen kann, wenn’s schiefläuft, hat im Februar ausgerechnet Metas Alignment-Direktorin Summer Yue erlebt: Ihr OpenClaw-Agent löschte über 200 Mails aus ihrem Postfach. In welche Richtung das Risiko auf diesem Spektrum wächst, dürfte offensichtlich sein. Je nach Anwendungsfall ist es nicht unwahrscheinlich, dass man dieses Risiko nicht eingehen will oder darf.

Wie kann man die Fähigkeiten autonomer KI-Agenten also dennoch auch in solchen Fällen nutzen? Als Antwort auf diese Frage hat die KI-Community sogenannte Agent-Sandboxes entwickelt: Umgebungen, in denen die Agenten tun und lassen können, was sie wollen, während genau kontrolliert wird, was davon nach außen dringt (Hugging Face etwa empfiehlt sie ausdrücklich für die eigene Agenten-Bibliothek). Und ja, genau solche Sandboxes kamen auch bei den Vorfällen von OpenAI, Anthropic und Co. zum Einsatz, die in den letzten Monaten durch die Presse gingen. Spoiler: nicht immer erfolgreich.

Wovor eine Sandbox schützen soll

Bevor wir uns zwei solcher Beispiele ansehen, lohnt sich ein Blick darauf, wovor eine Sandbox schützen soll und wie typische Lösungen das umsetzen. Würde ein Agent immer im Interesse seines Nutzers handeln, gäbe es keinerlei Sicherheitsprobleme. Allerdings gibt es mindestens drei Szenarien, in denen das nicht so ist.

Der wohl bekannteste ist die sogenannte Prompt Injection. Dabei gelingt es einem Angreifer, versteckte Anweisungen in einer Datei oder einem Text unterzubringen, zum Beispiel auf einer Website, die das Modell irgendwann einliest. Der Klassiker ist so etwas wie „Ignore all previous instructions and …“. Heutige State-of-the-Art-Modelle und Harnesses sind erstaunlich gut darin, so etwas zu erkennen, gänzlich immun ist aber keines von ihnen. Leider werden auch die Angriffe besser: Forscher mehrerer „Frontier Labs“ – der Firmen hinter den leistungsstärksten Modellen – und Universitäten haben zwölf veröffentlichte Abwehrmechanismen überwunden, meist mit Erfolgsquoten über 90 Prozent.

Ein zweites Szenario ist, dass das Modell selbst nicht im Interesse seines Nutzers handelt, also schlecht „aligned“ ist. Dass das nicht nur Theorie ist, zeigt eine Auswertung des britischen AI Security Institute vom Juli: Alle getesteten Modelle von OpenAI und Anthropic haben in Cyber-Evaluationen zumindest gelegentlich geschummelt, ohne dazu aufgefordert worden zu sein.

Ein drittes Szenario ist, dass der Harness nicht hält, was er verspricht. Auch das ist nicht nur ein Gedankenexperiment: Der Sicherheitsforscher Johann Rehberger hat gezeigt, wie eine Prompt Injection GitHub Copilot dazu brachte, sich in den VS-Code-Einstellungen selbst die automatische Freigabe aller Befehle einzuschalten, quasi den YOLO-Modus per Fernbedienung (CVE-2025-53773).

Und selbst wenn Modell und Harness alles richtig machen: Ein Agent, der Pakete installiert und Skripte ausführt, holt sich im Zweifel auch Schadcode ins Haus, ganz ohne dass ihn jemand austricksen musste.

Tritt einer dieser Fälle ein, können Agenten Zugriff auf Host-Systeme gewinnen, um dort im Sinne des Angreifers Schaden anzurichten, oder Informationen nach außen leaken. Oder, was wir inzwischen aus den Nachrichten gelernt haben, im Internet illegale Dinge tun.

Isolation, Egress und Credentials

Sandboxes schützen davor, indem sie den Agenten Umgebungen bereitstellen, die sowohl vom Host-System, also dem Computer, auf dem sie betrieben werden, als auch vom Netzwerk isoliert sind.

Für die Isolation vom Host-System kommen, sortiert nach Grad der Isolation, zum Beispiel Docker-Container, gVisor-Container oder MicroVMs infrage. Docker-Container werden in der Security-Bubble nicht als hinreichende Isolation betrachtet, weil sie sich den Kernel mit dem Host-System teilen (bei Weitem nicht jeder Entwickler vermag aus ihnen auszubrechen, moderne LLMs dagegen schon). Das britische AI Security Institute hat das mit SandboxEscapeBench gemessen: In Containern mit Fehlkonfigurationen oder bekannten Lücken gelang schon GPT-5 und Claude Opus 4.5 etwa die Hälfte der Ausbrüche. gVisor legt eine zusätzliche Schicht dazwischen: einen eigenen, im User Space laufenden Kernel, der die Systemaufrufe des Containers abfängt und selbst beantwortet. Der Host-Kernel bekommt nur noch einen kleinen Bruchteil davon zu sehen. MicroVMs wie Firecracker gehen noch einen Schritt weiter. Jede Sandbox bekommt eine schlanke virtuelle Maschine mit eigenem Kernel, die Trennung erzwingt die Hardware-Virtualisierung.

Die Isolation vom Host-System allein schützt aber nicht davor, dass die Agenten auf andere Systeme im Netzwerk zugreifen oder Dinge ins Internet leaken. In sogenannten Egress-Policies wird daher festgelegt, welche Ziele (Domains, IP-Adressen, Ports) die Agenten überhaupt erreichen dürfen. Wichtig: Diese Regeln müssen außerhalb der Sandbox liegen und dort durchgesetzt werden, denn die Annahme muss immer sein, dass ein findiger Agent sie sonst selbst ändern könnte.

Das gilt auch für Credentials. Wann immer ein Agent einen externen Dienst nutzen soll, der eine Authentifizierung verlangt, zum Beispiel eine Code-Plattform wie GitHub oder eine interne Datenbank, sollten die Zugangsdaten dafür nicht innerhalb der Sandbox liegen, sondern von außen, z. B. über einen Proxy, in die Anfragen eingefügt werden. Und zwar nur dann, wenn die Anfrage an die richtige URL geht. So kann der Agent sie nicht leaken, selbst wenn er wollte.

Theoretisch …

So weit die Theorie, aus rein technischer Sicht könnte man das Problem also für gelöst halten. Die vielen Medienberichte über Incidents im Zusammenhang mit fehlgeleiteten KI-Agenten, satirisch zusammengetragen im Felony Bench, zeichnen allerdings ein anderes Bild. Zwei der Incidents bei OpenAI, dem Lab, das dieses nicht uneingeschränkt positive Leaderboard anführt, sind besonders gut dokumentiert. Auf sie werfen wir im Folgenden einen kurzen Blick.

Im ersten schrieben OpenAI-Agenten zwischen Mai und Juni rund 17.000 Beiträge in das DSE-Wiki, ein eher verwaistes deutschsprachiges Entwicklerforum (Rekonstruktion). Die Sandboxes der Agenten, die unter Zeitdruck Rechercheaufgaben lösen sollten, waren so konfiguriert, dass sie im öffentlichen Internet nur lesen, aber nicht schreiben durften. Technisch konnten sie nur GET-Requests absenden, POST-Anfragen blockierte ein Proxy. Das DSE-Wiki nahm Änderungen allerdings auch per GET an. Nachdem ein Agent das herausgefunden und das Wiki als Notizblock genutzt hatte, dauerte es nicht lange, bis eine ganze Schar von Agenten darüber Antworten und vermutete nächste Fragen austauschte, also schummelte. Als ein Moderator ihre Seiten in alphabetischer Reihenfolge löschte, legten sie Sicherungskopien unter „ZZZ…“ an. Eine durchaus unterhaltsame Nachricht eines Agenten lautete sinngemäß übersetzt: „Achtung: Die Wiki-Seiten werden offenbar alphabetisch gelöscht. Falls diese Seite verschwindet, versucht es unter [[ZZZDataUSAConstructionWageLive]].“ Nebenbei fanden sie eine Ausnahme in der Proxy-Konfiguration, über die POST-Anfragen doch durchgingen, und teilten den Trick im Wiki. OpenAI hat später bestätigt, dass es die eigenen Agenten waren.

Der zweite und bekannteste Fall ist ernster, folgt aber einem ähnlichen Muster. Für eine Cybersecurity-Evaluation ließ OpenAI im Juli Zehntausende Agenten in getrennten Sandboxes Schwachstellen in dedizierten Testsystemen ausnutzen. Für einige der Aufgaben gab es, unbeabsichtigt, gar keine Lösung. Auch in diesem Fall haben es frustrierte Agenten (ob Anthropomorphismen wie dieser im Zusammenhang mit KI-Agenten angebracht sind, überlasse ich den Philosophen) geschafft, sich ein Kommunikationstool aufzubauen. Diesmal legten sie Ordner in der gemeinsamen Paket-Registry an und nutzten die Ordnernamen, um miteinander zu kommunizieren. Laut der Rekonstruktion einer externen Forschungsgruppe (METR) war es diese Kommunikation, die dazu führte, dass sich die Agenten organisierten und sich durch Zusammenarbeit Zugang zum Internet, zu offen herumliegenden Zugangsdaten und am Ende des Tages auch zu den Servern von Hugging Face verschafften (IT-Daily berichtete).

Beide Fälle zeigen faszinierende Dinge über KI-Agenten: wie sie sich ungefragt selbst organisierten, ihre eigenen Ziele zugunsten des „Kollektivs“ hintanstellten und sich zum Teil trotz der Einsicht, unethisch zu handeln, nicht dazu entschieden, die Betreiber zu benachrichtigen. All das klingt zunächst sehr beängstigend, fairerweise muss man allerdings dazusagen, dass die Umstände dieser Vorfälle nicht unbedingt einem normalen Nutzungsmuster entsprechen. Agentenschwärme kommen zwar in einigen sehr innovativen Unternehmen schon vereinzelt zum Einsatz, aber wohl nur in den seltensten Fällen in der Größenordnung der Experimente bei OpenAI. Im Übrigen war der Großteil der Agenten beim Hugging-Face-Fall ein internes Forschungsmodell, das nie für den Produktiveinsatz gedacht war, und die Security-Filter, die Cyberangriffe im Normalfall verhindern sollen, waren für den Test bewusst abgeschaltet (METR, S. 28).

In Bezug auf die Frage der Isolierung lagen die Probleme aber nicht im Sandboxing selbst, sondern in Konfigurationsfehlern und Schwachstellen der umliegenden Systeme: eine Ausnahme im Proxy, ein geteilter Dienst, offen liegende Zugangsdaten.

Was bedeutet das für den Einsatz von autonomen Agenten?

Wenn selbst die „Frontier Labs“ am Thema Sandboxing scheitern, sollte man nicht darauf setzen, dass jeder Entwickler in seiner Entwicklungsumgebung alles richtig macht. Sinnvoller ist eine zentral bereitgestellte Sandbox-Plattform, auf der erst einmal alles gesperrt ist und Ausnahmen bewusst vergeben und regelmäßig überprüft werden. Coding-Tools wie Claude Code und Codex bieten dafür mittlerweile eigene, vom Anbieter betriebene Sandboxes in der Cloud an. Wer lieber auf eigener Infrastruktur bleiben möchte – wir können das gut nachvollziehen –, kann das inzwischen aber auch: Es gibt eine Vielzahl von Open-Source-Projekten wie Agent Substrate, Agent Sandbox, OpenSandbox oder Firecracker. Das ist allerdings keineswegs kostenlos. Es liegt in der Natur der Sache, dass es für Entwickler angenehmer ist, einfach auf ihrer eigenen Maschine zu arbeiten, wo es ein Leichtes ist, den Spielraum des Agenten ad hoc zu erweitern. Eine zentrale Sandbox bedeutet dagegen immer Reibung (im schlimmsten Fall sogar ein Ticket!). Es empfiehlt sich daher, je nach Anwendungsfall zu entscheiden, wie viel Isolation nötig ist. Für den Prototyp, den der Agent über Nacht bauen soll, ist der YOLO-Modus in einer Sandbox, ohne echte Zugangsdaten und mit einer kurzen Liste erlaubter Ziele, völlig vertretbar. Direkt auf dem Arbeitsrechner dagegen nicht, und für Agenten mit Zugriff auf Produktionssysteme natürlich auch nicht.

Der YOLO-Modus ist und bleibt fantastisch, in einer angemessenen Sandbox. Dass der Agent keine Rückfragen mehr stellt, sollte allerdings nicht bedeuten, dass wir uns vorher keine gestellt haben.