KI-Agenten sicher betreiben: Vier Wege zur Isolation im Vergleich
TL;DR: Es gibt vier relevante Ansätze, um KI-Agenten zu isolieren: Docker Sandboxes (lokal auf dem Laptop), E2B (US-Cloud-API für Agent-Plattformen), Daytona (Open-Source-Sandbox-Infrastruktur) und ZWRM (MicroVMs auf Deinen eigenen Servern mit vollem Plattform-Zugriff). Jeder löst ein anderes Problem. Dieser Beitrag vergleicht alle vier -- mit besonderem Blick auf Datenstandort, DSGVO und die Frage, ob Deine Daten in Europa bleiben.
Wer KI-Agenten Code schreiben und ausführen lässt, braucht eine sichere Ausführungsumgebung. Das ist keine Frage mehr. Ein autonomer Agent mit vollem Zugriff auf Dein Dateisystem, Netzwerk und Zugangsdaten ist ein Risiko -- unabhängig davon, welches Modell dahintersteckt.
Die eigentliche Frage ist: Welche Art von Sandbox? Und für Unternehmen im DACH-Raum kommt eine zweite Frage dazu: Wo laufen diese Agents, und wer hat Zugriff auf die Daten?
Warum Agent-Isolation wichtig ist
KI-Agenten sind keine normalen Anwendungen. Sie generieren und führen Code zur Laufzeit aus. Du weißt vorher nicht, was sie ausführen werden. Damit unterscheidet sich die Angriffsfläche grundlegend von einer App, die Du selbst geschrieben und geprüft hast.
Die Risiken sind konkret:
- Ein Agent kann Code ausführen, der eine Kernel-Schwachstelle ausnutzt und aus einem Container ausbricht
- Ein Agent kann unerwartete externe APIs aufrufen -- Daten fließen ab oder Kosten laufen auf
- Ein Agent kann gemeinsame Dateisysteme verändern oder alle verfügbaren Ressourcen verbrauchen
- Ein Agent kann auf Zugangsdaten, Umgebungsvariablen oder SSH-Keys auf dem Host zugreifen
Container-Isolation (Linux Namespaces und cgroups) hilft, aber alle Container auf einem Host teilen sich denselben Kernel. Ein Kernel-Exploit in einem Container kann alles andere kompromittieren. Deshalb setzen alle ernstzunehmenden Tools auf stärkere Grenzen: MicroVMs mit eigenem Kernel oder zumindest gehärtete Container-Runtimes.
Für Unternehmen, die unter DSGVO, DORA oder NIS2 arbeiten, kommt ein weiterer Aspekt dazu: Wo findet diese Code-Ausführung statt? Ein Agent, der auf US-Cloud-Infrastruktur läuft und dabei auf Kundendaten oder interne APIs zugreift, wirft dieselben Fragen auf wie jeder andere Drittanbieter mit US-Jurisdiktion.
Die vier Ansätze
Docker Sandboxes
Docker Sandboxes sind ein Feature von Docker Desktop. Du bekommst eine MicroVM-basierte Sandbox auf Deinem Laptop, in der ein KI-Agent frei arbeiten kann, ohne Dein Host-System zu berühren. Jede Sandbox hat ihren eigenen Docker-Daemon, und Dein Projektverzeichnis wird zwischen Host und Sandbox synchronisiert.
Die Nutzung ist unkompliziert: docker sandbox run claude, und Dein Agent läuft in einer isolierten Umgebung auf Deinem Rechner. Sandboxes bleiben bestehen, bis Du sie entfernst.
Docker Sandboxes unterstützen Claude Code produktiv, mit Codex, Copilot, Gemini und weiteren in Entwicklung. Das Feature ist kostenlos mit Docker Desktop verfügbar -- auf macOS und Windows mit MicroVM-Isolation, auf Linux mit Container-basierter Isolation.
Die Einschränkung: Sandboxes sind rein für lokale Entwicklung gedacht. Der Agent kann Code schreiben und testen, aber nichts deployen, keine Datenbank anlegen, nicht mit Produktions-Infrastruktur interagieren. Es ist eine sichere Box -- kein Arbeitsplatz mit Zugang zu Deiner Infrastruktur.
Gut geeignet für: Einzelne Entwickler, die Agents sicher auf dem eigenen Rechner nutzen wollen.
E2B
E2B ist eine Cloud-Plattform, die Firecracker-MicroVM-Sandboxes als API anbietet. Es ist kein Tool, mit dem Du als Entwickler direkt einen Agent startest. Es ist eine API für Teams, die Agent-Plattformen oder -Frameworks bauen und dafür eine sichere Ausführungsumgebung brauchen.
Jede Sandbox bekommt ein eigenes Dateisystem, Netzwerk und eigene Prozesse. Sandboxes sind standardmäßig kurzlebig (5 Minuten Timeout, erweiterbar auf 24 Stunden im Pro-Plan). E2B bietet SDKs für Python und JavaScript, Cold Starts unter 200ms und benutzerdefinierte Sandbox-Templates.
Die Preise sind nutzungsbasiert: ca. 0,05 USD pro Stunde pro vCPU, sekundengenau abgerechnet. Es gibt einen kostenlosen Einstieg mit 100 USD Guthaben, einen Pro-Plan für 150 USD/Monat und Enterprise-Optionen.
Wichtig für den DACH-Raum: E2B läuft auf US-Cloud-Infrastruktur. Wenn Deine Agents auf Kundendaten, interne APIs oder vertrauliche Codebases zugreifen, läuft diese Verarbeitung in den USA. Das ist kein technisches Problem, aber ein rechtliches -- insbesondere unter DSGVO und dem CLOUD Act. E2B bietet zwar BYOC- und On-Premises-Optionen im Enterprise-Plan an, aber die Standard-Nutzung ist US-basiert.
Gut geeignet für: Teams, die Agent-Plattformen bauen und eine Execution-API brauchen.
Daytona
Daytona positioniert sich als sichere Infrastruktur für die Ausführung von KI-generiertem Code. Die Plattform bietet programmierbare Sandboxes mit schnellem Start (unter 90ms), Dateisystem-Operationen, Git-Integration, Language-Server-Support und Prozess-APIs. Im Februar 2026 hat Daytona eine Series-A-Runde über 24 Millionen USD abgeschlossen.
Daytona ist Open Source (AGPL-3.0) und unterstützt OCI/Docker-Images. Sandboxes laufen auf Deiner eigenen Infrastruktur -- Deine Cloud oder On-Premises -- mit Daytona als Control Plane. Die Isolation ist Container-basiert, nicht MicroVM-basiert.
Für den DACH-Markt relevant: Da Daytona auf eigener Infrastruktur läuft, kannst Du den Datenstandort selbst bestimmen -- zum Beispiel auf Hetzner oder OVH in Deutschland. Die AGPL-3.0-Lizenz bedeutet allerdings, dass Änderungen am Code unter derselben Lizenz veröffentlicht werden müssen, was für manche Unternehmen eine Einschränkung ist.
Gut geeignet für: Teams, die Agent-Ausführungsinfrastruktur selbst aufbauen wollen und mit Open Source arbeiten.
ZWRM Agents
ZWRM Agents laufen in Firecracker-MicroVMs auf Deinen eigenen Servern -- self-hosted oder auf ZWRM-gemanagter Infrastruktur. Jeder Agent bekommt seinen eigenen Kernel, sein eigenes Dateisystem und seinen eigenen Netzwerk-Stack. Die VM wird nach jeder Session zerstört, aber ein persistentes Volume unter /home/agent bewahrt Deine Arbeit zwischen Sessions.
Was ZWRM von den anderen Ansätzen unterscheidet: Agents sind nicht nur isoliert -- sie haben Zugriff auf die gesamte ZWRM-Plattform:
zwrm init-- Projekte aufsetzenzwrm postgres create-- Datenbanken anlegenzwrm secrets set-- Umgebungsvariablen konfigurierenzwrm deploy-- Anwendungen deployenzwrm logs-- Laufzeit-Verhalten prüfenzwrm scale 3-- Instanzen skalieren
Agents kommen vorinstalliert mit gängigen Tools (Python, Node.js, Go, Rust, Bun, Git, GitHub CLI, curl, vim, SSH). Zugangsdaten -- API Keys, Git-Konfiguration, GitHub Tokens, SSH Keys -- werden automatisch bei jedem Start injiziert. Kein manuelles Setup pro Session.
ZWRM unterstützt Claude Code und Codex. Sicherheit wird über mehrere Ebenen abgedeckt: Ressourcen-Limits, Netzwerk-Policies, Ausführungs-Timeouts und Audit Logging.
Für den DACH-Raum: ZWRM ist ein EU-Unternehmen mit Sitz in Deutschland. Die gemanagte Infrastruktur läuft auf Hetzner-Servern in Deutschland und Island. Deine Daten bleiben auf Deinen Servern -- oder auf Servern in Europa unter EU-Jurisdiktion. Kein CLOUD Act, kein Datentransfer in die USA.
Gut geeignet für: Teams, die KI-Agenten nicht nur isolieren, sondern produktiv auf eigener Infrastruktur einsetzen wollen.
Vergleichstabelle
| Docker Sandboxes | E2B | Daytona | ZWRM Agents | |
|---|---|---|---|---|
| Wo es läuft | Dein Laptop (Docker Desktop) | E2B Cloud (USA) | Deine Cloud oder On-Prem | Deine Server (self-hosted oder ZWRM-gemanagt) |
| Isolation | MicroVM (macOS/Windows); Container auf Linux | Firecracker MicroVM | Container-basiert (OCI/Docker) | Firecracker MicroVM |
| Haupteinsatz | Sichere lokale Agent-Entwicklung | API für Agent-Plattformen | Programmierbare Sandbox-Infrastruktur | Gesamter Lifecycle: entwickeln, deployen, betreiben |
| Können Agents deployen? | Nein | Nein | Nein | Ja |
| Credential Management | Manuell | Über API | Über API | Automatische Injektion bei jedem Start |
| Persistenz | Sandbox bleibt bis zum Löschen | Kurzlebig (5 Min Standard, bis 24h) | Konfigurierbar, unbegrenzt möglich | VM wird zerstört; /home/agent bleibt |
| Team-Support / Audit | Pro Entwickler, keine zentrale Sicht | API-Level-Zugriffskontrolle | API-Level-Zugriffskontrolle | Team-Infrastruktur mit Audit Logging |
| Datenstandort | Dein Laptop | US-Cloud | Deine Infrastruktur | Deine Server (EU-Standard bei ZWRM-gemanagt) |
| Preismodell | Kostenlos mit Docker Desktop | Nutzungsbasiert (~0,05 USD/h/vCPU) | Open Source + Managed-Optionen | Kommerziell (ab Bezahlplan) |
| Open Source? | Nein | Teilweise (SDKs) | Ja (AGPL-3.0) | Nein |
| Unterstützte Agents | Claude Code, Codex, Copilot, Gemini u.a. (teils in Entwicklung) | Beliebig (über API) | Beliebig (über API) | Claude Code, Codex |
Welcher Ansatz passt zu Dir?
Du willst Agents sicher auf Deinem Laptop nutzen
Docker Sandboxes. Kein Setup außer Docker Desktop, keine Kosten, keine Server. Dein Agent läuft in einer MicroVM auf Deinem Rechner. Wenn Dein Workflow bei "push to Git" endet, ist das die einfachste Lösung.
Du baust eine Plattform, die Agent-generierten Code ausführen muss
E2B oder Daytona. Beide bieten APIs, um isolierte Ausführungsumgebungen programmatisch zu starten. E2B ist ein Managed Service mit bewiesener Skalierung. Daytona ist Open Source und läuft auf Deiner eigenen Infrastruktur. Die Entscheidung hängt davon ab, ob Du Managed oder Self-Hosted willst -- und ob die AGPL-Lizenz für Deinen Fall funktioniert.
Beachte beim Datenstandort: Wenn Deine Agents mit Kundendaten oder internen Systemen arbeiten, prüfe, wo die Code-Ausführung stattfindet. E2B Standard-Sandboxes laufen in den USA. Daytona und ZWRM laufen auf Deiner eigenen Infrastruktur, zum Beispiel auf Hetzner oder OVH in Deutschland.
Du willst KI-Agenten, die auf Deiner Infrastruktur bauen und deployen
ZWRM. Die anderen Tools isolieren Agents, aber halten sie in einer Box. ZWRM gibt Agents Zugriff auf Produktions-Infrastruktur -- Datenbanken, Deployments, Secrets, Logs -- und isoliert sie gleichzeitig auf Hardware-Ebene. Wenn ein Agent eine Aufgabe von "Code schreiben" bis "läuft in Produktion" durchführen soll, ist das aktuell die einzige Option dafür.
DSGVO-Konformität und Datenhoheit sind Anforderungen
Docker Sandboxes halten alles auf Deinem Laptop. Daytona und ZWRM (self-hosted) halten alles auf Deinen Servern. ZWRM-gemanagte Infrastruktur läuft in Europa unter EU-Jurisdiktion. E2B läuft standardmäßig auf US-Cloud-Infrastruktur.
Für Unternehmen in regulierten Branchen -- Finanzdienstleistungen, Gesundheitswesen, Rechtsberatung, öffentlicher Sektor -- ist der Datenstandort der Agent-Ausführung genauso relevant wie der Datenstandort der Anwendung selbst. KI-Agenten sicher betreiben heißt nicht nur Isolation, sondern auch Kontrolle darüber, wo die Verarbeitung stattfindet.
Du brauchst Audit-Trails und Team-Sichtbarkeit
ZWRM hat integriertes Audit Logging und Ressourcen-Kontrollen pro Agent, gebaut für Teams. Docker Sandboxes sind pro Entwickler ohne zentrale Sichtbarkeit. E2B und Daytona bieten API-Level Logging, sind aber nicht für interaktive Team-Nutzung ausgelegt.
Ein Markt, der sich schnell entwickelt
Vor einem Jahr haben die meisten Entwickler KI-Agenten direkt auf ihrem Rechner laufen lassen und gehofft, dass nichts passiert. Heute gibt es echte Tools mit echten Isolation-Grenzen. Die Ansätze unterscheiden sich, aber sie teilen eine Überzeugung: Autonome Code-Ausführung braucht Isolation auf Hardware-Ebene -- oder zumindest nahe daran.
Wähle das Tool, das zu Deinem Workflow passt. Wenn Du lokal entwickelst, reichen Docker Sandboxes. Wenn Du Agent-Infrastruktur baust, haben E2B oder Daytona die APIs. Wenn Du Agents brauchst, die Software auf Deinen Servern deployen -- und Deine Daten dabei in Europa bleiben sollen -- ist ZWRM dafür gebaut.
Was Du nicht tun solltest: Agents ohne Isolation laufen lassen. Das ist keine Geschmacksfrage.
Du willst KI-Agenten, die auf Deiner eigenen Infrastruktur bauen, deployen und betreiben? Starte eine kostenlose 14-Tage-Testphase auf zwrm.eu.
