Ein KI-Agent, der eigenen Code schreibt und ausführt, ist nur so sicher wie die Umgebung, in der dieser Code läuft. In einem Tutorial von Machine Learning Mastery zeigt der Autor, wie man diesen Code auf drei Ebenen isoliert: einen limitierten Unterprozess, einen gehärteten Docker-Container und eine Firecracker-MicroVM, und vergleicht dann deren Sicherheit und Latenz.
Der Unterprozess ist die leichteste Ebene: Es handelt sich um einen Child-Prozess, dessen Rechenzeit, Speicher und Dateigröße begrenzt sind, der aber den Kernel und die Dateien des Host-Systems teilt. Ein Container fügt Namespaces und Control Groups (cgroups) hinzu, bleibt aber ein Satz von Prozessen auf dem Host-Kernel. Der Artikel erinnert daran, dass im November 2025 drei Schwachstellen in der Laufzeitumgebung runc es Angreifern ermöglichten, aus Containern auszubrechen. Eine MicroVM hingegen gibt jeder Umgebung ihren eigenen Kernel, hinter einem Hypervisor, der Software, die virtuelle Maschinen betreibt.
Der Aufbau beruht auf einem einzigen Werkzeug, run_python, das dem Agenten zur Verfügung gestellt wird. Jeder vom Modell erzeugte Code durchläuft ein ‘Sandbox’-Objekt mit einer Methode run(code), sodass ein Wechsel der Isolationsstufe den Agenten nicht verändert. Das Tutorial erfordert Python 3.10 oder neuer, ein Linux-System oder WSL für die Unterprozess-Ebene, Docker für den Container sowie einen Account und einen API-Schlüssel von E2B für die MicroVM. Ein Anthropic-API-Schlüssel ist für den Agenten nützlich, kann für Tests aber umgangen werden.
Sechs identische Angriffe auf jede Ebene
Um die drei Ebenen zu vergleichen, werden die gleichen sechs schädlichen Programme ausgeführt: eine Endlosschleife, eine Speicherallokation von 512 MB, ein ‘Fork Flood’ mit 200 Prozessen, das Schreiben einer 50-MB-Datei, das Lesen einer gefälschten Datei mit Zugangsdaten und die Verbindung zu einem gefälschten internen Dienst. Ein Angriff gilt als blockiert, wenn das Erkennungswort nicht in der Ausgabe erscheint, oder bei der Endlosschleife, wenn die Ausführung zeitüberschreitet.
Auf der Unterprozess-Ebene, ausgeführt mit einem normalen Linux-Benutzer, werden vier Angriffe blockiert und zwei gelingen. Die Prozessgrenze gilt nur für einen dedizierten Benutzer, sodass der Fork Flood erlaubt ist, und die gefälschte Datei mit Zugangsdaten bleibt lesbar, weil der Code unter der Identität des Benutzers läuft. Der Autor schlussfolgert, dass diese Ebene hauptsächlich für vertrauenswürdigen Code geeignet ist.
Für den Docker-Container gibt der Autor an, dass mit den gewählten Optionen Docker alle sechs Angriffe blockieren sollte, da der Container kein Netzwerk hat, sein Dateisystem nicht die Dateien des Benutzers enthält und die Grenzen für Speicher, Prozesse und Festplatte gelten. In einer MicroVM können Angriffe auf Speicher, Prozesse und Festplatte die Grenzen der virtuellen Maschine erreichen, bleiben aber auf diese beschränkt, und die geheime Datei sowie der lokale Dienst existieren dort nicht.
Latenz und Wahl der Ebene
Der Unterprozess sollte am schnellsten sein, da er nur Python startet. Für die beiden anderen Ebenen präzisiert der Autor, dass die veröffentlichten Zahlen Behauptungen und keine Garantien sind: Ein zitierter Artikel gibt an, dass E2B in etwa 150 ms startet, während AWS und Docker nahezu sofortige Starts für ihre MicroVM-Produkte beschreiben. Das Skript bench.py ermöglicht es, auf dem eigenen Rechner den Median und die längste Zeit über zehn Ausführungen eines Programms print(1) zu messen.
Der Autor empfiehlt, den Unterprozess für vertrauenswürdigen Code wie persönliche Entwicklungs-Skripte zu reservieren und den gehärteten Container für Fälle, in denen man den Host kontrolliert und die Risiken gering sind, wobei darauf zu achten ist, runc aktuell zu halten. Die MicroVM ist notwendig für Code von mehreren Benutzern, für alles, was Geheimnisse betrifft, und wenn der Agent selbst Container bauen und ausführen muss, was klassische Container laut Docker schlecht handhaben. Docker hat seine Docker Sandboxes auf MicroVM-Basis im April 2026 gestartet, und AWS bietet Lambda MicroVMs an, die ihren Zustand bis zu 8 Stunden behalten und sich bei Inaktivität suspendieren. Laut Docker müssen Dateien, Netzwerkregeln und Geheimnisse von der Infrastruktur und nicht vom Agenten vor dessen Ausführung definiert werden.
