Kurzfassung
KI-Agenten führen beliebigen Code aus. Das unterscheidet sie grundlegend von traditionellen Anwendungen. Container teilen sich einen Kernel mit dem Host, und aus Containern kann man ausbrechen. Hardware-Isolation auf ZWRM gibt jedem Agent seinen eigenen Kernel, sein eigenes Dateisystem und sein eigenes Netzwerk. Erst damit ist es sicher, Agents in Produktion frei arbeiten zu lassen.
KI-Agenten sind anders als traditionelle Anwendungen. Sie beantworten nicht nur Anfragen. Sie handeln. Sie schreiben Code, rufen APIs auf, verändern Datenbanken und interagieren mit externen Systemen. Damit ist ihre Angriffsfläche größer als die einer traditionellen Anwendung.
Wenn Du KI-Agenten in Produktion betreibst (oder es vorhast), lautet die Frage nicht, ob Du sie sandboxen solltest. Sondern wie.
Das Agent-Sandbox-Problem
Wenn ein LLM-gesteuerter Agent entscheidet, Code auszuführen, muss dieser Code irgendwo laufen. Das könnte Dein Laptop sein, ein Docker-Container, eine Cloud-VM, Dein Produktions-Server oder ein IoT-Gerät. Aber nur weil der Code überall laufen könnte, heißt das nicht, dass er es sollte.
Die meisten Entwickler erkennen die Gefahr, einen KI-Agenten direkt auf dem eigenen Rechner oder Produktions-Server laufen zu lassen. Du gibst Systemzugriff an einen autonomen Prozess ab, der Code auf Basis probabilistischer Modelle generiert, trainiert auf Daten aus dem Internet. So etwas willst Du nicht mit vollem Zugriff auf Dein Dateisystem, Netzwerk und Deine Zugangsdaten laufen lassen.
Die instinktive Antwort sind Container. Docker, gVisor, seccomp-Profile (“stecken wir den Agent in eine Box”). Die Idee ist richtig, aber die Box ist nicht so stabil, wie Du denkst.
Warum Container nicht reichen
Container bieten Isolation auf Prozess-Ebene. Sie nutzen Linux Namespaces und cgroups, um einzuschränken, was ein Prozess sehen und tun kann. Aber alle teilen sich eine kritische Sache: den Host-Kernel.
Dieser geteilte Kernel ist das Problem. Jeder Container auf einem Host macht System-Calls an denselben Kernel. Ein Kernel-Exploit in einem Container kompromittiert alle anderen, und schlimmer noch: auch den Host. Das ist keine Theorie. Container-Escape-Schwachstellen werden regelmäßig entdeckt (CVE-2024-21626, CVE-2019-5736, um nur zwei zu nennen).
Für eine normale Webanwendung ist dieses Risiko beherrschbar. Die Anwendung führt bekannten Code aus, den Du geschrieben und geprüft hast. Ein KI-Agent generiert und führt dagegen unbekannten Code zur Laufzeit aus. Du weißt schlicht nicht, was er als Nächstes tut. Die Angriffsfläche ist grundlegend größer.
Das kann bei reiner Container-Isolation schiefgehen:
| Szenario | Risiko |
|---|---|
| Agent generiert Code, der eine Kernel-Schwachstelle ausnutzt | Bricht aus dem Container aus, greift auf Host und andere Workloads zu |
| Agent ruft unerwartete externe APIs auf | Verursacht Kosten, gibt sensible Daten an Dritte weiter |
| Agent verändert geteilte Dateisysteme oder Volumes | Beschädigt Daten, die andere Anwendungen nutzen |
| Agent startet Prozesse, die alle Ressourcen verbrauchen | Denial of Service für alles andere auf dem Host |
Zusätzliche Schichten wie seccomp-Profile und AppArmor helfen, aber das sind alles Mechanismen auf Kernel-Ebene. Ein einziger Kernel-Exploit umgeht sie alle gleichzeitig.
Was Hardware-Isolation bedeutet
Hardware-Isolation ist ein komplett anderer Ansatz. Statt Prozesse innerhalb eines geteilten Kernels zu isolieren, bekommt jeder Workload einen eigenen Kernel in einer eigenen virtuellen Maschine.
Genau das macht Firecracker. Firecracker ist ein Open-Source Virtual Machine Monitor, den Amazon für AWS Lambda und Fargate gebaut hat. Er startet leichtgewichtige VMs, sogenannte MicroVMs, in unter 125 Millisekunden mit weniger als 5 MB Speicher-Overhead. Das ist schnell und leicht genug für einzelne Workloads, auch für einzelne Agent-Ausführungen.
Der entscheidende Unterschied zu Containern:
| Container | ZWRM MicroVMs | |
|---|---|---|
| Kernel | Geteilt mit dem Host | Eigener Kernel pro Workload |
| Isolationsgrenze | Linux Namespaces (Software) | Hardware-Virtualisierung (KVM) |
| Auswirkung eines Escapes | Zugriff auf Host und alle Container | Bleibt in der VM eingeschlossen |
| Boot-Zeit | Unter einer Sekunde | 1-5 Sekunden |
| Speicher-Overhead | Minimal | ~20-30 MB pro VM |
| Dichte | Hoch | Hoch (20-50 VMs pro Server) |
Mit einer MicroVM kann ein Agent, selbst wenn er Code generiert, der eine Schwachstelle ausnutzt, nur seine eigene VM kompromittieren. Er hat keinen Weg zum Host-Kernel, keinen Zugriff auf andere VMs und keine geteilten Ressourcen, die er beschädigen könnte.
Wie ZWRM Agents isoliert
Auf ZWRM läuft jede Agent-Ausführung in einer eigenen Firecracker-MicroVM. Wenn Du einen Agent startest, fährt die Plattform eine dedizierte VM hoch mit:
- Eigenem Kernel. Der Agent-Prozess berührt den Host-Kernel nie.
- Eigenem Dateisystem. Keine geteilten Volumes, kein versehentlicher Zugriff auf andere Workloads.
- Eigenem Netzwerk-Stack. Netzwerk-Policies steuern, was der Agent erreichen kann.
- Ephemeral by default. Die VM wird nach der Ausführung zerstört und hinterlässt keinen Restzustand.
Das ist kein Feature, das Du konfigurierst. Es ist die Architektur. Jeder Agent, jedes Mal.
Diese Hardware-Isolation ist das Fundament, und ZWRM legt weitere Schutzschichten darüber:
| Schicht | Was sie tut |
|---|---|
| Ressourcen-Limits | Obergrenzen für CPU, Speicher und Netzwerk-Bandbreite pro Agent-Ausführung. Kein einzelner Agent kann den Host aushungern |
| Netzwerk-Policies | Allowlist, welche externen APIs und Endpoints ein Agent erreichen darf. Alles andere ist blockiert |
| Ausführungs-Timeouts | Harte Zeitlimits pro Ausführung. Keine Endlosschleifen, keine außer Kontrolle geratenen Prozesse |
| Audit Logging | Jede Aktion des Agents wird aufgezeichnet und ist abfragbar. Volle Nachvollziehbarkeit |
Diese Schichten greifen ineinander. Selbst wenn ein Agent einen Weg an einer Kontrolle vorbei findet, halten die anderen. Und die MicroVM-Grenze darunter sorgt dafür, dass der Schaden immer auf diese eine Ausführung begrenzt bleibt.
Wie das in der Praxis aussieht
Einen isolierten Agent auf ZWRM zu starten ist ein Befehl:
zwrm agent claude my-projectKeine Docker-Konfiguration, keine Security-Profile, kein VM-Provisioning. Die Plattform übernimmt Isolation, Ressourcen-Limits, Netzwerk und Aufräumen automatisch.
ZWRM Agents sind ephemeral auf VM-Ebene, aber persistent auf Volume-Ebene. Du legst für jedes Deiner Projekte Agents mit eigenem Kontext, eigener Umgebung und eigenen Secrets an. Wenn Du an einem Projekt arbeitest, startest Du Deinen dedizierten Agent und machst genau dort weiter, wo Du aufgehört hast. Wenn Du fertig bist, wird die VM zerstört, aber Deine Arbeit bleibt auf dem angehängten Volume erhalten.
So kannst Du Dutzende Agents über verschiedene Projekte hinweg betreiben, jeder vollständig von den anderen isoliert, jeder mit eigenen Dependencies und Zugangsdaten, und keiner kann die anderen oder den Host stören.
Warum das für Produktion wichtig ist
Die meisten Agent-Frameworks behandeln Sandboxing als Nebensache. Sie führen Agent-Code im selben Prozess aus, bestenfalls in einem Docker-Container. Für Demos und lokale Entwicklung reicht das. Es reicht nicht, wenn Du Agents in Produktion betreibst, mit echten Daten, für echte Kunden, mit echten Konsequenzen.
In Produktion steht mehr auf dem Spiel:
- Ein Datenleck ist keine Lernerfahrung (sondern ein DSGVO-Verstoß)
- Ein außer Kontrolle geratener Prozess ist kein Ärgernis (sondern Downtime für Deine Kunden)
- Ein kompromittierter Host ist kein Reimage (sondern ein Security-Incident, der jeden Workload auf dieser Maschine betrifft)
Agent-Infrastruktur sollte secure by default sein. Du solltest nicht über Isolation nachdenken, Security-Profile konfigurieren oder hoffen müssen, dass Deine Container-Runtime jeden Grenzfall abfängt. Sicherheit sollte auf Hardware-Ebene eingebaut sein, bei jeder einzelnen Agent-Ausführung.
Genau das leisten Firecracker-MicroVMs, und genau so betreibt ZWRM jeden Agent.
Bereit, KI-Agenten sicher auf Deiner eigenen Infrastruktur zu betreiben? Starte eine kostenlose 14-Tage-Testphase auf zwrm.eu.