KI-Agenten sicher betreiben: Vier Wege zur Isolation im Vergleich

Kurzfassung

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. Dabei können Daten abfließen oder Kosten entstehen.
• 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. Codex, Copilot, Gemini und weitere sind in Entwicklung. Das Feature ist kostenlos mit Docker Desktop verfügbar. Auf macOS und Windows nutzt es MicroVM-Isolation, auf Linux Container-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 und nicht mit Produktions-Infrastruktur interagieren. Es ist eine sichere Box ohne Zugang zu Deiner Infrastruktur.

Gut geeignet für einzelne Entwickler. Sie können Agents sicher auf dem eigenen Rechner nutzen.

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, kann aber unter DSGVO und dem CLOUD Act rechtliche Folgen haben. E2B bietet BYOC- und On-Premises-Optionen im Enterprise-Plan an, aber die Standard-Nutzung ist US-basiert.

Gut geeignet für Teams. Sie können Agent-Plattformen bauen und die Execution-API nutzen.

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 in Deiner Cloud oder On-Premises, mit Daytona als Control Plane. Die Isolation basiert auf Containern, nicht auf MicroVMs.

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. Das schränkt manche Unternehmen ein.

Gut geeignet für Teams. Sie können ihre Agent-Ausführungsinfrastruktur selbst aufbauen und mit Open Source arbeiten.

ZWRM Agents

ZWRM Agents laufen in Firecracker-MicroVMs auf Deinen eigenen Servern, entweder 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 isoliert und haben Zugriff auf die gesamte ZWRM-Plattform:

• zwrm init setzt Projekte auf.
• zwrm postgres create legt Datenbanken an.
• zwrm secrets set konfiguriert Umgebungsvariablen.
• zwrm deploy stellt Anwendungen bereit.
• zwrm logs prüft das Laufzeit-Verhalten.
• zwrm scale 3 skaliert Instanzen.

Agents kommen vorinstalliert mit gängigen Tools (Python, Node.js, Go, Rust, Bun, Git, GitHub CLI, curl, vim, SSH). ZWRM injiziert API Keys, Git-Konfiguration, GitHub Tokens und SSH Keys bei jedem Start. Pro Session ist kein manuelles Setup nötig.

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. Der CLOUD Act greift dort nicht, und es gibt keinen Datentransfer in die USA.

Gut geeignet für Teams. Sie können KI-Agenten isolieren und produktiv auf eigener Infrastruktur einsetzen.

Vergleichstabelle

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 Datenbanken, Deployments, Secrets und Logs. Gleichzeitig isoliert es sie 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 ist der Datenstandort der Agent-Ausführung genauso relevant wie der Datenstandort der Anwendung selbst. Das betrifft Finanzdienstleistungen, Gesundheitswesen, Rechtsberatung und den öffentlichen Sektor. KI-Agenten sicher zu betreiben braucht Isolation und Kontrolle über den Ort der Verarbeitung.

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 behalten, 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.