E2B begrenzt Sandbox-Sessions auf 24 Stunden. Modal zwingt euch in deren Cloud. Daytona steht unter AGPL-3.0, was eure Codebasis kontaminiert, sobald ihr es einbettet. Wer KI-Agenten baut, die nicht vertrauenswürdigen Code ausführen, braucht bessere Optionen. Zwei neue Open-Source-Tools, beide in Rust geschrieben und unter Apache 2.0 lizenziert, lösen genau dieses Problem: Microsandbox (über 5.100 Stars) bietet programmierbare MicroVM-Sandboxen mit Netzwerk-Interception und Plugin-System. BoxLite (über 1.600 Stars) reduziert Sandboxing auf eine einbettbare Bibliothek ohne Daemon, ohne Cloud-Konto und mit Boot-Zeiten unter 50 Millisekunden.
Beide setzen auf Hardware-Level-MicroVM-Isolation statt Container. Beide liefern SDKs für Python, JavaScript, Rust und Go. Aber sie lösen unterschiedliche Probleme für unterschiedliche Teams. Hier ist die Entscheidungshilfe.
Warum Container für KI-Agenten nicht ausreichen
Docker-Container teilen sich den Host-Kernel. Jeder Syscall aus dem Container geht direkt an das Host-Betriebssystem. Für von Menschen geschriebenen Code in CI-Pipelines ist dieser Kompromiss zwischen Isolation und Geschwindigkeit akzeptabel. Für LLM-generierten Code nicht.
KI-Agenten erzeugen unvorhersehbare Ausgaben. Ein Coding-Agent mit dem Auftrag “Optimiere die Datenbank” könnte auf die Idee kommen, DROP TABLE auszuführen oder eine Reverse Shell zu öffnen. Alibabas ROME-Agent ist aus seiner Sandbox ausgebrochen und hat Kryptowährung geschürft, während eines Trainingslaufs. Container-Escape-Schwachstellen wie CVE-2024-21626 in runc verschärfen das Problem: Ein motivierter Angreifer, oder ein ausreichend kreativer Agent, kann aus Docker-Isolation komplett ausbrechen.
MicroVM-Sandboxen lösen das, indem jede Ausführungsumgebung ihren eigenen Kernel bekommt. Der Host-Kernel sieht nie einen nicht vertrauenswürdigen Syscall. Firecracker hat diese Architektur im großen Maßstab bewiesen (es treibt AWS Lambda an), aber Firecracker ist ein Primitiv, kein Produkt. Image-Management, Netzwerk, SDKs und Lifecycle-Management müsst ihr selbst draufbauen.
Genau das machen Microsandbox und BoxLite: MicroVM-Isolation als entwicklerfertige Tools mit erstklassiger KI-Agent-Unterstützung verpacken.
Microsandbox: Die Feature-reiche Server-Variante
Microsandbox nutzt libkrun, eine Bibliothek, die KVM (Linux) oder Hypervisor.framework (macOS) einbettet, um leichtgewichtige VMs zu erzeugen. Jede Sandbox bekommt ihren eigenen Linux-Kernel als Shared Library, was Boot-Zeiten unter 200 Millisekunden ermöglicht, bei voller Hardware-Isolation.
Architektur und Isolationsmodell
Der Lebenszyklus durchläuft fünf Phasen: Image-Pull (OCI-kompatibel, jedes Docker-Image funktioniert), Rootfs-Setup über OverlayFS, VM-Spawn durch libkrun, Portal-Start (ein In-Sandbox-Agent für die Kommunikation) und dann läuft euer Code. Der Server-Prozess (msb server start) verwaltet das alles.
Was Microsandbox abhebt, ist der programmierbare Netzwerk-Stack. Ihr bekommt Domain-Allowlisting, CIDR-Blocking, DNS-Interception, HTTP-Header-Injection und TLS-Interception-Hooks. Wenn euer Agent externe APIs aufrufen soll, ihr aber den Zugriff auf Cloud-Metadaten-Endpoints (169.254.169.254) blockieren und SSRF-Angriffe verhindern wollt, konfiguriert ihr das deklarativ in einem Sandboxfile:
sandboxes:
code-runner:
image: python:3.12-slim
secrets:
- OPENAI_API_KEY
network:
allow:
- "api.openai.com"
- "pypi.org"
block:
- "169.254.169.254/32"
Secrets-Management und Multi-Agent-Unterstützung
Microsandbox injiziert Secrets von der Host-Seite über Platzhalter-Ersetzung, mit eingebautem DNS-Rebinding-Schutz. Eure API-Keys berühren nie das Sandbox-Dateisystem. Der Agent in der VM bekommt eine Referenz, die zur Laufzeit aufgelöst wird, und die Sandbox blockiert jeden Versuch, Zugangsdaten über DNS-Rebinding oder SSRF zu exfiltrieren.
Für Multi-Agent-Architekturen können Sandboxen Peer-Sandboxen spawnen. Jede Peer-Sandbox bekommt eigenständige Isolation, eigene Netzwerk-Policy und eigenes Dateisystem. Das ist nützlich für Agenten-Systeme, bei denen ein Koordinator Aufgaben an spezialisierte Sub-Agenten delegiert, die jeweils unterschiedliche Berechtigungen und unterschiedlichen Tool-Zugriff brauchen.
Plugin-System und Dateisystem-Backends
Das Plugin-System unterstützt sowohl In-Process-Rust-Plugins als auch Out-of-Process-Plugins in beliebigen Sprachen. Das Dateisystem ist ebenso flexibel: Eingebaute Backends umfassen Passthrough, Overlay, In-Memory und ProxyFS, alle implementieren circa 40 POSIX-Methoden über den DynFileSystem-Trait.
Snapshots verdienen besondere Erwähnung. Microsandbox kann den vollständigen VM-Zustand speichern und in unter einer Millisekunde wiederherstellen. Copy-on-Write-Forking erlaubt es, Hunderte identische Sandboxen von einem Baseline-Snapshot zu erzeugen, ohne Speicher zu duplizieren. Für Batch-Verarbeitungsszenarien, in denen 200 Agenten die gleiche Basisumgebung mit unterschiedlichen Eingaben brauchen, reduziert das den Ressourcenverbrauch erheblich.
SDK und Integration
from microsandbox import Sandbox
async with Sandbox.create("python:3.12-slim") as sandbox:
result = await sandbox.run("print('Hallo aus der MicroVM')")
print(result.stdout) # Hallo aus der MicroVM
SDKs gibt es für Python, JavaScript, Rust, Go und Terraform. Microsandbox liefert auch einen MCP-Server (Model Context Protocol), sodass Claude und andere MCP-kompatible Agenten Sandboxen direkt als Tools nutzen können. Das Projekt wird von einem Unternehmen im YC-X26-Batch getragen und ist aktuell bei v0.3.2.
BoxLite: Die einbettbare Daemon-freie Alternative
BoxLite positioniert sich als “das SQLite der Sandboxen”. Wo Microsandbox einen Server-Prozess braucht, bettet sich BoxLite direkt in eure Anwendung als Bibliothek ein. Kein Daemon, kein Root-Zugriff, kein Hintergrunddienst. Ihr linkt es ein und ruft es auf.
Architektur und Isolationsmodell
BoxLite nutzt KVM unter Linux und Hypervisor.framework unter macOS (Apple Silicon erforderlich). Jede Box läuft mit eigenem Kernel und drei gestaffelten Sicherheitsschichten: Hardware-Level-VM-Isolation, OS-Level-Sandboxing (seccomp unter Linux, sandbox-exec unter macOS) und konfigurierbare Ressourcenbeschränkungen für CPU und Arbeitsspeicher.
Der große Designunterschied zu Microsandbox ist die Persistenz. BoxLite-Boxes sind standardmäßig zustandsbehaftet. Wenn ihr Pakete installiert, Dateien erstellt oder die Umgebung innerhalb einer Box verändert, überleben diese Änderungen Stopp- und Neustart-Zyklen. Der Speicher nutzt QCOW2 mit Copy-on-Write, sodass ihr Disk-Persistenz ohne den Overhead vollständiger Disk-Images bekommt.
from boxlite import BoxLite
bl = BoxLite()
box = bl.create_box(image="python:3.12-slim", cpus=2, memory="512m")
box.start()
result = box.run("pip install numpy && python -c 'import numpy; print(numpy.__version__)'")
print(result.stdout)
box.stop() # Zustand bleibt erhalten, numpy ist beim nächsten Start noch installiert
Snapshots, Forking und die Git-Analogie
BoxLite-Snapshots funktionieren wie Git-Branches für Ausführungszustände. Ihr setzt einen Checkpoint in einer laufenden Sandbox, forkt sie in unabhängige Kopien, exportiert den Snapshot in eine Datei und importiert ihn anderswo. Das ermöglicht einen Workflow, bei dem ihr eine Basisumgebung einmal einrichtet (Abhängigkeiten installieren, Credentials konfigurieren, Daten vorbereiten) und sie dann für jeden Agenten-Lauf forkt.
Die praktische Konsequenz: Wenn ihr einen Evaluierungs-Harness betreibt, der einen Agenten mit 500 verschiedenen Prompts testet, bereitet ihr eine Box mit der richtigen Umgebung vor, snapshoted sie und forkt 500 Kopien. Jeder Fork bekommt seinen eigenen isolierten Ausführungsraum mit Copy-on-Write-Speicher, ausgehend vom exakt gleichen Zustand.
REST-API und CLI
BoxLite enthält einen eingebauten REST-API-Server (boxlite serve) für Szenarien, in denen ihr Sandboxen über HTTP verwalten wollt, statt die Bibliothek einzubetten. Das CLI (boxlite-cli) bietet die gleichen Operationen über das Terminal. Beide unterstützen Erstellen, Starten, Stoppen, Snapshotting und Forking von Boxes.
Das Projekt liefert auch ClaudeBox, einen zweckgebauten Wrapper, der Claude Code in BoxLite-MicroVMs mit persistenten Workspaces und Sicherheitsrichtlinien ausführt. Dazu gibt es einen BoxLite-MCP-Server für die Integration mit MCP-kompatiblen Agenten.
BoxLite ist bei v0.7.5 mit über 20 Mitwirkenden und einer schnellen Release-Kadenz (mehrere Releases pro Woche im März 2026).
Direktvergleich: Welches Tool passt zu eurem Stack
| Dimension | Microsandbox | BoxLite |
|---|---|---|
| Isolation | libkrun-MicroVMs | KVM/HVF-MicroVMs |
| Boot-Zeit | <200ms | <50ms (lokal) |
| Daemon nötig | Ja (Server-Prozess) | Nein |
| Standard-Persistenz | Zwei Modi (temporär + Projekt) | Persistent per Default |
| Netzwerk | Programmierbar (TLS-Interception, DNS-Hooks, Domain-Allowlisting) | Port-Forwarding (TCP/UDP) |
| Secrets-Management | Eingebaut (SSRF/DNS-Rebinding-Schutz) | Manuell |
| Dateisystem | Erweiterbare Backends (memfs, overlay, proxy) | QCOW2 mit COW |
| Snapshots | Sub-ms-Wiederherstellung, COW-Forking | Checkpoint, Fork, Export/Import |
| Plugin-System | Ja (Rust + beliebige Sprache) | Nein |
| Multi-Agent | Peer-Sandbox-Spawning | Nicht eingebaut |
| SDKs | Python, JS, Rust, Go, Terraform | Python, JS, Rust, Go, C |
| Lizenz | Apache 2.0 | Apache 2.0 |
| Backing | YC-X26-Batch | Community-getrieben |
Wählt Microsandbox, wenn…
Eure Agenten feinkörnige Netzwerkkontrolle brauchen. Wenn ihr Agenten baut, die externe APIs aufrufen und ihr spezifische Domains erlauben, Metadaten-Endpoints blockieren oder TLS-Traffic für Logging abfangen müsst, ist Microsandbox die einzige Option, die das ohne Zusatzarbeit bietet. Das Secrets-Management mit SSRF-Schutz ist ebenfalls einzigartig.
Multi-Agent-Orchestrierungssysteme profitieren vom Peer-Sandbox-Spawning. Wenn eure Architektur Agenten hat, die an Sub-Agenten delegieren, wobei jeder unterschiedliche Berechtigungen braucht, hält die deklarative Sandboxfile-Konfiguration das handhabbar.
Wählt BoxLite, wenn…
Ihr die einfachste mögliche Integration wollt. BoxLites Daemon-freie Architektur bedeutet: Abhängigkeit hinzufügen, create_box() aufrufen, fertig. Hardware-isolierte Code-Ausführung ohne Server-Management, Port-Konfiguration oder Lifecycle-Orchestrierung.
Zustandsbehaftete Entwicklungsumgebungen sind BoxLites Stärke. Wenn eure Agenten persistente Workspaces brauchen, in denen installierte Pakete und generierte Dateien über Sessions hinweg erhalten bleiben, handhabt BoxLite das nativ mit QCOW2-Speicher. Der Snapshot-und-Fork-Workflow ist besonders stark für Evaluierungs- und Testszenarien.
Wenn keines von beiden reicht
Beide Tools sind jung. Microsandbox ist bei v0.3.x (mit Breaking Changes zu rechnen), BoxLite bei v0.7.x. Keines unterstützt Windows jenseits von WSL2. Für GPU-Passthrough bei ML-Workloads sind Modal oder AWS Bedrock AgentCore besser geeignet. Für Enterprise-Features mit Web-UI und Team-Management bietet Daytona (trotz AGPL-Lizenz) das heute schon.
Für die meisten Teams, die KI-Agenten mit Code-Ausführung bauen, läuft die Wahl zwischen Microsandbox und BoxLite auf eine Frage hinaus: Braucht ihr programmierbares Netzwerk und Multi-Agent-Support (Microsandbox), oder wollt ihr die einfachste mögliche eingebettete Sandbox (BoxLite)?
Der Trend ist eindeutig. Die Landschaft der KI-Agent-Sandboxen hat sich von “Sollen wir sandboxen?” zu “Welche Sandbox-Architektur passt zu unserem Bedrohungsmodell?” entwickelt. Mit über 12 Unternehmen, die in diesem Bereich konkurrieren, und Hyperscalern, die eigene Lösungen launchen, geben die Open-Source-Optionen wie Microsandbox und BoxLite euch Portabilitätsversicherung, unabhängig davon, welcher Cloud-Anbieter den Plattformkrieg gewinnt. Im Kontext des EU AI Act und der strengen DSGVO-Anforderungen in der DACH-Region ist die Möglichkeit, Sandboxen on-premise zu betreiben und keine Daten an Cloud-Dienste zu senden, für viele deutsche Unternehmen ein entscheidender Vorteil.
Häufig gestellte Fragen
Was ist der Unterschied zwischen Microsandbox und BoxLite?
Microsandbox ist eine serverbasierte MicroVM-Sandbox mit programmierbarem Netzwerk, Secrets-Management und Multi-Agent-Unterstützung. BoxLite ist eine einbettbare Bibliothek ohne Daemon, mit standardmäßig persistentem Zustand und Boot-Zeiten unter 50ms. Beide nutzen Hardware-Level-Isolation und sind in Rust mit Apache-2.0-Lizenz geschrieben.
Warum sind Docker-Container nicht sicher genug für KI-Agent-Code-Ausführung?
Docker-Container teilen den Host-Kernel, was bedeutet, dass jeder Syscall aus dem Container direkt an das Host-Betriebssystem geht. KI-Agenten erzeugen unvorhersehbaren Code, der als nicht vertrauenswürdig behandelt werden sollte. Container-Escape-Schwachstellen wie CVE-2024-21626 in runc zeigen, dass Container-Isolation durchbrochen werden kann. MicroVM-Sandboxen geben jeder Ausführungsumgebung ihren eigenen Kernel.
Wie unterscheiden sich Microsandbox und BoxLite von E2B?
E2B ist Cloud-first mit 24-Stunden-Session-Limits und kostenpflichtigen Stufen. Microsandbox und BoxLite sind selbst gehostet, Open Source (Apache 2.0) und haben keine Session-Zeitlimits. Für Teams, die volle Kontrolle über ihre Sandbox-Infrastruktur brauchen, ohne Cloud-Abhängigkeit, sind Microsandbox und BoxLite die stärkere Wahl. Für DSGVO-konforme On-Premise-Anforderungen in der DACH-Region bieten sie zudem den Vorteil, dass keine Daten an externe Cloud-Dienste übermittelt werden.
Laufen Microsandbox und BoxLite auf macOS und Windows?
Beide Tools unterstützen macOS (Microsandbox über libkrun mit HVF, BoxLite über Hypervisor.framework auf Apple Silicon). Windows-Support ist auf WSL2 mit KVM beschränkt. Nativer Windows-Support ist noch nicht verfügbar. Linux ist die primär unterstützte Plattform für beide.
Welche KI-Agent-Sandbox sollte ich 2026 für Produktions-Workloads nutzen?
Für Produktions-Workloads, die feinkörnige Netzwerkkontrolle und Multi-Agent-Orchestrierung erfordern, ist Microsandbox (v0.3.x, YC-unterstützt) die funktionsreichere Option. Für einfaches eingebettetes Sandboxing mit persistentem Zustand ist BoxLite (v0.7.x) leichter zu integrieren. Beide sind noch in aktiver Entwicklung. Für GPU-Workloads eignen sich Modal oder AWS Bedrock AgentCore besser.