OpenSandbox

KI-Agenten müssen zunehmend selbst generierten Code ausführen, Shell-Befehle absetzen und Browser steuern, und das direkt auf dem Host-System zu tun ist ein Sicherheitsrisiko. OpenSandbox von der opensandbox-group ist eine universelle Sandbox-Laufzeit, die genau für dieses Problem gebaut wurde. Sie gibt Agenten eine isolierte Umgebung, in der nicht vertrauenswürdiger Code laufen kann, ohne den Host zu berühren, und stellt Befehle, Dateisysteme, Code-Interpreter, Browser und Entwicklerwerkzeuge über eine einheitliche API bereit. Das Projekt versteht sich als universelle Sandbox-Infrastruktur, liefert SDKs für Python, Java/Kotlin, JavaScript/TypeScript, C#/.NET und Go und läuft lokal auf Docker oder im großen Maßstab auf Kubernetes. Es ist in der CNCF Landscape gelistet und trägt ein OpenSSF Best Practices Badge, beides Hinweise darauf, dass das Team auf Produktivbetrieb zielt.

OpenSandbox nutzt ein Client-Server-Modell. Das SDK oder die osb-CLI sprechen mit einem Lifecycle-Management-Server, und in jeder Sandbox erledigt ein Ausführungs-Daemon namens execd die Befehlsausführung und die Dateioperationen. Bemerkenswert ist die geschichtete Isolation: Statt auf ein Backend festzulegen, unterstützt das System Standard-Docker-Container, gVisor als User-Space-Kernel, Kata Containers als leichte VMs und Firecracker-MicroVMs, sodass man Performance gegen Isolationsstärke je nach Bedrohungsmodell abwägen kann. Um die Laufzeit herum kommen ein Ingress-Gateway mit Routing-Strategien, Egress-Richtlinien pro Sandbox und ein Credential-Vault, der Secrets einspielt, ohne sie der Workload offenzulegen. Ein MCP-Server erlaubt Agent-Frameworks die direkte Anbindung, und persistente Volumes reichen von Docker über Kubernetes-PVCs bis zu OSSFS.

Am klarsten passt OpenSandbox zu Plattform- und Infrastruktur-Teams, die Agent-Produkte bauen und selbst gehostetes, mehrsprachiges Sandboxing mit feiner Kontrolle brauchen. Wer ohnehin auf Kubernetes läuft und über Python-, Go- und .NET-Dienste hinweg konsistentes Sandbox-Verhalten will, profitiert von der einheitlichen API und der SDK-Breite. Die dokumentierten Beispiele sind konkret: Coding-Agenten wie Claude Code, Gemini und OpenAI Codex innerhalb einer Sandbox, Browser-Automatisierung mit Chrome und Playwright, Remote-Entwicklungsumgebungen mit VNC, VS Code und freigegebenen Ports sowie Machine-Learning- oder Reinforcement-Learning-Training und Agent-Evaluierungen. Teams, denen Datenresidenz, Secret-Handling und Egress-Kontrolle wichtig sind und die Code nicht an einen gehosteten Drittanbieter geben dürfen, sind hier die natürliche Zielgruppe.

Die ehrlichen Einschränkungen beginnen beim Umfang. OpenSandbox deckt viel ab, mehrere Isolations-Backends, ein Ingress-Gateway, einen Credential-Vault, fünf SDKs, und diese Breite bedeutet mehr bewegliche Teile und spürbaren Betriebsaufwand. Der Zugriff erfolgt nur über SDK und CLI, eine UI oder visuelle Werkzeuge sind nicht dokumentiert, also liegen Observability und Debugging bei einem selbst. Schon der einfachste Einstieg verlangt Docker und Python 3.10 oder neuer, und die stärkeren Isolationsmodi wie gVisor und Firecracker bringen eigene Performance-Kosten und Kernel- oder Host-Anforderungen mit. Das Projekt meldet häufige Releases, der Server steht bei Version 0.2.0, was heißt, dass die API noch jung ist und sich ändern kann. Die README nennt keine Grenzen für gleichzeitige Sandboxes, keine Latenzwerte und keine Ressourcenlimits, hier muss man für die eigene Last selbst messen.

Gegenüber gehosteten Optionen wie E2B oder Modal tauscht OpenSandbox Bequemlichkeit gegen Kontrolle. E2B und Modal liefern in Minuten eine verwaltete Sandbox, ohne dass Infrastruktur betrieben werden muss, was für Einzelentwickler und kleine Teams schwer zu schlagen ist. OpenSandbox gibt einem stattdessen den vollen selbst gehosteten Stack in die Hand, die Isolationswahl, die SDK-Breite und die Kubernetes-native Laufzeit, dafür betreibt man alles selbst. Greifen Sie zu, wenn Sie als Plattform-Team mehrsprachige Agent-Infrastruktur aufbauen, Daten in der eigenen Umgebung halten müssen und Kontrolle über Isolation und Netzwerk auf SDK-Ebene wollen. Zu früh ist es, wenn Sie als Einzelentwickler nur schnell eine lokale Sandbox ohne Kubernetes brauchen, denn dann führen ein gehosteter Dienst oder ein schlichter Container schneller zum Ziel. Behalten Sie die API im Auge, während sie über 0.2.0 hinaus reift.