Code Sandbox 2026: Die 7 besten Sicherheitstools für KI-Agenten

Vercel Sandbox ist 2026 für die meisten Cloud-Agenten-Teams die beste Code Sandbox insgesamt. Entscheidend ist allerdings nicht der Preisabstand: Beim hier normierten Workload reichen die Kosten der verwalteten Angebote von $55.55 bis $288 pro Monat. Für den Produktivbetrieb zählt vielmehr, ob modellgenerierter Code sowohl einen eigenen Ausführungskernel als auch einen Egress-Pfad erhält, über den niemals Live-Zugangsdaten offengelegt werden.

Code Sandbox im Überblick: die Shortlist

Die folgenden Preise und Produktlimits wurden am 19. August 2026 überprüft. Die sieben Tools decken lokale Coding-Agenten ebenso ab wie verwaltete Cloud-Agenten, denn für beide Einsatzfelder gelten unterschiedliche Risiko- und Kostenmodelle.

Die Reihenfolge ist bewusst nicht nach dem niedrigsten Preis sortiert. Northflank verursacht mit $55.55 zwar die niedrigste modellierte Rechnung unter den verwalteten Cloud-Angeboten. Vercel gewinnt dennoch insgesamt, weil Firecracker-Grenze, zur Laufzeit steuerbare Egress-Richtlinie und Zugangsdatenvermittlung zusammen eine sauberere Standardlösung für Produktteams ergeben, die einen Agenten ausliefern möchten, ohne selbst einen Cluster zu betreiben. Docker liegt auf Platz zwei: Das Tool bietet ohne Anbietergebühr eine ungewöhnlich vollständige lokale Schutzgrenze, ist jedoch keine verwaltete Laufzeitumgebung für kundennahe Jobs.

Die Entscheidungsregel ist einfach: Es gewinnt das günstigste Tool, das beide erforderlichen Schutzgrenzen für den konkreten Workload erfüllt. Die erste Grenze hält nicht vertrauenswürdigen Code hinter einem eigenen Kernel oder einer vergleichbar starken Syscall-Isolation. Die zweite hält Produktiv-Secrets und ausgehende Berechtigungen aus diesem Code heraus. Eine günstige VM, die einen API-Schlüssel im Klartext erhält, fällt durch. Dasselbe gilt für eine gut isolierte VM mit unbeschränktem Egress ins öffentliche Internet.

So wurden die Tools ausgewählt

OpenAI empfiehlt Sicherheitsverantwortlichen inzwischen, risikoreiche Workflows ohne Zugriff auf sensible Produktivsysteme oder das offene Internet auszuführen, Sandbox-Grenzen regelmäßig zu testen, Agentenaktionen zu überwachen und den zulässigen Handlungsspielraum festzulegen. Die Leitlinien zum Agents SDK werden noch deutlicher: Prompt-Injection- und Exfiltrationsversuche sind vorauszusetzen, Orchestrierung und Rechenumgebung müssen getrennt bleiben, und Zugangsdaten gehören nicht in jene Umgebung, in der generierter Code läuft. Das sind Betriebsanweisungen und keine theoretischen Randfälle. OpenAI veröffentlichte die aktuelle Empfehlung am 10. August.

Daraus ergibt sich die Prüfung der zwei Schutzgrenzen, die allen Bewertungen zugrunde liegt:

1. Ausführungsgrenze: Erhält jeder potenziell schädliche Job einen eigenen Kernel, eine microVM, eine VM oder eine dokumentierte Syscall-Isolation? Kann der Prozess oder das Dateisystem eines Nutzers auf das eines anderen zugreifen?
2. Egress- und Zugangsdaten-Grenze: Lässt sich das Netzwerk standardmäßig sperren, auf benannte Ziele begrenzen und eine Zugangsdaten-Injektion erst nach Verlassen der Sandbox durchführen?
3. Kontrollgrenze: Können Richtlinien, Protokolle, Kontingente und Identitäten außerhalb des Codes liegen, den das Modell möglicherweise verändert?
4. Betriebliche Eignung: Ist das Produkt lokal, API-zentriert, Edge-nativ, GPU-orientiert oder eine vollständige Plattform? Die richtige Schutzgrenze im falschen Betriebsmodell wird schnell zu ungenutzter Technik.
5. Laufende Kosten: Was kostet derselbe Workload, sobald das Aktionsguthaben verbraucht ist?

Dieser Vergleich kombiniert Preise und Analyse; er erhebt nicht den Anspruch eines Penetrationstests. Sämtliche Preise, Limits und Funktionen stammen von aktuellen Originalseiten der Anbieter. Ein Produkt wurde nur aufgenommen, wenn die Herstellerangaben ausreichten, um sowohl Isolation als auch Egress zu beurteilen, und wenn es eine Schutzgrenze für potenziell schädlichen Code statt lediglich einer allgemeinen Entwicklungsumgebung bot.

Der normierte Workload umfasst 10,000 Ausführungen pro Monat. Jede Ausführung dauert 5 Minuten, fordert 2 vCPU und 4 GiB Arbeitsspeicher an und hält die CPU 1 Minute lang aktiv; in den verbleibenden 4 Minuten wartet der Agent auf Dateien, Pakete oder Netzwerkarbeit. Diese Unterscheidung ist relevant, weil Vercel und Cloudflare aktive CPU-Zeit anders abrechnen als bereitgestellten Arbeitsspeicher, während E2B, Daytona, Northflank und Modal Rechenleistung über die gesamte Laufzeit berechnen.

Moderne Agentenarbeit hat zwei klar getrennte Seiten. Läuft der Coding-Assistent auf einem Laptop, lohnt der Abgleich mit den Workflows in Codex vs Claude Code vs Cursor. Steuert der Agent einen Browser, wird auch die Browser-Sitzung Teil der Schutzgrenze, wie der Vergleich der besten Browser für KI-Agenten zeigt. Eine Sandbox ersetzt weder die Wahl des richtigen Agenten noch kann ein starker Agent auf die Isolation seiner Tools verzichten.

1. Vercel Sandbox: beste Gesamtlösung für Cloud-Agenten-Teams

Vercel Sandbox ist die beste Gesamtlösung für Produktteams, die eine verwaltete API, eine starke Rechengrenze und Secrets benötigen, die nicht in generierten Code gelangen müssen.

Jede Sandbox läuft in einer Firecracker-microVM. Die integrierten Umgebungen unterstützen Node.js 22, 24 und 26 sowie Python 3.13; für eigene Laufzeitumgebungen dient ein OCI-Image. Sitzungen in Pro und Enterprise können bis zu 24 Stunden laufen, gegenüber 45 Minuten in Hobby. Zugleich steigt das Ressourcenlimit von 4 vCPU in Hobby auf 8 in Pro und 32 in Enterprise. Pro vCPU stehen fest 2 GB Arbeitsspeicher bereit, sodass der 2-vCPU-Workload dieses Vergleichs genau 4 GB erhält.

Der Sicherheitsvorteil zeigt sich nach dem Start der VM. Die Netzwerk-Firewall von Vercel kann Richtlinien bei laufendem Prozess ändern, Zugangsdaten erst beim Verlassen der Sandbox in eine ausgehende Anfrage einsetzen und ausgewählte Anfragen über einen eigenen Proxy leiten. Damit lässt sich ein sicherer zweistufiger Job umsetzen: Während der Einrichtung ist die Paketregistrierung erreichbar, anschließend wird der breite Zugriff entfernt, und erst dann läuft modellgenerierter Code mit einer kurzen Zielliste. Die Sandbox erhält die benötigten Tools, ohne zugleich die Schlüssel für GitHub, eine Modell-API oder einen Objektspeicher zu übernehmen.

Die entscheidende Hürde liegt in der Konfiguration, nicht in der Isolation. Vercels Firewall-Dokumentation nennt allow-all als Standard; eine neue Sandbox darf also unbeschränkt auf das öffentliche Internet zugreifen. Vercels Einrichtungsablauf installiert Pakete mit breitem Zugriff und wechselt danach auf eine benutzerdefinierte Positivliste, bevor nicht vertrauenswürdiger Code startet. Fehlt dieser zweite Schritt in der Orchestrierung, schützt Firecracker weiterhin den Host, doch alles innerhalb der Sandbox kann nach außen gesendet werden. Die Zugangsdatenvermittlung verhindert, dass der Gast den Klartextschlüssel kopiert. Sie hindert generierten Code aber nicht daran, den Schlüssel während des Jobs über eine zulässige Anfrage zu missbrauchen.

Das Observability-Update vom 7. Juli macht aus dieser Richtlinie eine betriebliche Kontrolle. Teams können aktive CPU-Zeit, bereitgestellten Arbeitsspeicher, Datenübertragung, laufende Sandboxes und Sitzungen erfassen und die Kennzahlen anschließend nach Sandbox Name und Sandbox Session ID gruppieren. Vercel stellt Sandbox-Observability in jedem Tarif bereit; manuelle Abfragen sind in Pro und Enterprise verfügbar. Für das Budget folgt daraus eine konkrete Maßnahme: Jeder Jobtyp erhält ein Tag, seine Kosten werden zugeordnet, und Sitzungen mit ungewöhnlichem Egress oder auffälliger Laufzeit werden untersucht.

Am besten geeignet für: Verwaltete Coding-Agenten, Code-Interpreter, Preview-Builder und kundennahe Ausführung auf einem Vercel-Stack.
Besonderheit: Firecracker, laufzeitbasierte Egress-Richtlinien, Zugangsdatenvermittlung und optionales Request-Proxying in einem Produkt.
Preis: Hobby kostet $0. Pro kostet $20/Monat, enthält $20 Nutzungsguthaben und berechnet danach $0.128 pro aktive CPU-Stunde, $0.0212 pro GB-Stunde bereitgestellten Arbeitsspeichers, $0.60 pro 1 Million Erstellungsvorgänge, $0.15 pro GB Netzwerkverkehr und $0.08 pro GB-Monat für Snapshots. Enterprise wird individuell angeboten.
Kostenlos testen: Hobby enthält 5 aktive CPU-Stunden, 420 GB-Stunden Arbeitsspeicher, 5,000 Erstellungsvorgänge, 20 GB Netzwerkverkehr, 10 gleichzeitige Sandboxes und 15 GB Snapshot-Speicher. Eine Pro-Testversion ist verfügbar.

Eine sichere Bereitstellungsfolge für Vercel

1. 1

   Bedrohungsmodell festhalten

   Festlegen, was der generierte Code lesen, schreiben, aufrufen und offenlegen darf. Repository-Zugangsdaten, Produktivdatenbanken, Cloud-Metadaten und interne Admin-APIs bleiben standardmäßig außerhalb der Sandbox.

2. 2

   Sauberes Image erstellen

   Ausgangspunkt ist eine integrierte Laufzeitumgebung oder ein OCI-Image, das nur die für den Job erforderlichen Tools enthält. Kundendaten und langlebige Zugangsdaten gehören weder ins Image noch in einen Snapshot.

3. 3

   Egress für die Einrichtung kurz öffnen

   Nur die Paketregistrierung, der Quellcode-Host oder der Artefaktspeicher wird freigeschaltet, der für die Einrichtung nötig ist. Falls vorübergehend ein breiter Zugriff erforderlich ist, muss die Richtlinienänderung ein expliziter Orchestrierungsschritt und keine informelle Konvention sein.

4. 4

   Netzwerk schließen

   Bevor modellgenerierter Code startet, wird auf benannte Ziele umgestellt und alles andere gesperrt. Besonders riskante Anfragen laufen über den eigenen Proxy, wenn eine stabile Richtlinie dies erfordert.

5. 5

   Jedes Secret vermitteln

   Zugangsdaten werden nur für den genehmigten Host und die zulässige Anfrageform injiziert. Ein Rohwert gehört nicht allein deshalb in eine Umgebungsvariable, weil die microVM isoliert ist.

6. 6

   Beobachten und zerstören

   Protokolle werden gestreamt, Laufzeit und Ressourcen begrenzt und nur benötigte Ergebnisse aufbewahrt; anschließend wird die Sandbox zerstört. Ein regelmäßiger Test sollte versuchen, einen gesperrten Host zu erreichen und einen vermittelten Schlüssel auszulesen.

Fazit: Vercel ist die Standardwahl, wenn möglichst wenige Infrastrukturentscheidungen bei gleichzeitig starker Schutzgrenze gefragt sind. Lokale Ausführung, eine eigene Cloud oder umfangreiche GPU-Funktionen sprechen dagegen für eine andere Lösung.

2. Docker Sandboxes: beste Wahl für lokale Coding-Agenten

Docker Sandboxes ist hier die stärkste lokale Option, weil es sich um ein eigenständiges microVM-Produkt handelt und nicht um einen regulären Container mit beruhigendem Namen.

Die microVM bildet die primäre Vertrauensgrenze. Jede Sandbox verfügt über einen eigenen Kernel und eine eigene Docker Engine, ohne Zugriffspfad zum Docker-Daemon des Hosts. Ausgehender TCP-Verkehr läuft über einen hostseitigen Proxy mit standardmäßiger Sperre. Direkter externer UDP- und ICMP-Verkehr ist blockiert, und API-Zugangsdaten lassen sich in HTTP-Header einsetzen, ohne Rohwerte in der VM abzulegen. Für unbeaufsichtigte Sitzungen mit Codex, Claude Code, Copilot CLI, OpenCode oder Kiro ist das eine ernst zu nehmende lokale Architektur.

Auch der Anbieterpreis ist eindeutig: Die sbx-CLI kostet $0, hat keine Gebühr pro Arbeitsplatz und darf kommerziell genutzt werden. Eine zentrale Organisationsverwaltung mit verwalteten Netzwerk-, Dateisystem- und MCP-Richtlinien sowie Audit-Protokollen erfordert ein separates kostenpflichtiges Abonnement. Die eigentlichen Rechenkosten fallen auf Laptop oder Workstation an. Der sinnvolle Vergleich lautet deshalb nicht Dockers $0 gegenüber Northflanks $55.55, sondern lokale Hardware und Betriebsaufwand gegenüber einem verwalteten Dienst.

Die entscheidende Hürde liegt genau dort, wo lokale Arbeit auf den Host trifft. Im direkten Modus wird der Arbeitsbereich mit Schreibzugriff eingebunden. Ein Agent kann damit Git-Hooks, CI-Konfigurationen, IDE-Tasks, Makefile-Targets, Paketskripte und andere Dateien verändern, die später außerhalb der VM ausgeführt werden. --clone bindet das Host-Repository schreibgeschützt ein und gibt dem Agenten einen privaten Klon; für unbekannte Repositorys oder autonome Ausführungen ist das die sicherere Wahl. Docker weist außerdem darauf hin, dass breite Wildcard-Domains in der Standard-Positivliste verbleiben können, gemeinsam genutzte Agenten-Skills ohne Deaktivierung einen sandboxübergreifenden Lese- und Schreibspeicher bilden und lokale stdio-MCP-Server auf dem Host statt in der microVM laufen.

Docker Sandboxes 0.38.0 erschien am 6. August und brachte Kit spec v2, eine vollwertige MCP-Verwaltung, auf dem Host verbleibende OAuth-Zugangsdaten, Cedar-Richtlinien für Organisationen sowie eine sandboxbezogene --deny-network HOST-Kontrolle. Außerdem wurde CVE-2026-17106 behoben. Daraus folgt eine Wartungsregel und kein bloßer Grund zum Feiern von Release Notes: Lokale Isolationssoftware braucht einen verbindlichen Update-Rhythmus, und eine neu zentralisierte MCP-Oberfläche erfordert dieselbe Prüfung des Host-Vertrauens wie jede andere Brücke aus der VM.

Damit eignet sich Docker Sandboxes hervorragend für einen Entwicklerarbeitsplatz, aber kaum als sofort einsetzbares Cloud-Backend. Es schützt die Workstation vor den meisten Agentenaktivitäten; Arbeitsbereich, gemeinsam genutzte Skills und hostseitige MCP-Integrationen bleiben jedoch ausdrückliche Brücken. Jede einzelne muss separat geprüft werden.

Am besten geeignet für: Lokale Coding-Agenten, die Pakete installieren, Docker-Builds ausführen und unbeaufsichtigt arbeiten müssen, ohne umfassenden Host-Zugriff zu erhalten.
Besonderheit: microVM-Isolation, standardmäßig gesperrtes Proxy-Netzwerk und hostseitige Zugangsdaten-Injektion bei $0 Anbietergebühr.
Preis: $0 für die CLI ohne Gebühr pro Arbeitsplatz; Organisationsverwaltung wird individuell bepreist.
Kostenlos testen: Die zentrale CLI und isolierte lokale Sandboxes sind kostenlos.

Fazit: Docker Sandboxes eignet sich für lokale Agenten. Bei riskanten Aufgaben sollte der Klonmodus aktiviert, breite Netzwerkregeln sollten reduziert und jeder Host-MCP-Server als privilegiert behandelt werden. Ein Vergleich mit verwalteten APIs ist erst sinnvoll, wenn Hardware und Betriebsaufwand eingepreist sind.

3. Cloudflare Sandbox SDK: beste Edge-Lösung mit integrierter Richtliniensteuerung

Cloudflare Sandbox SDK passt am besten, wenn die Kontrollebene bereits in Workers liegt und der Agent einen streng programmierten Weg ins Internet benötigt.

Cloudflare Containers führt jede Sandbox in einer eigenen VM mit Dateisystem-, Prozess- und Netzwerkisolation sowie Ressourcenlimits pro Sandbox aus. Die Sicherheitsseite macht das Mandantendesign ausdrücklich klar: Prozesse innerhalb einer Sandbox teilen Dateien, Prozesse und das lokale Netzwerk. Daher ist pro Nutzer eine eigene Sandbox erforderlich. Dieser Hinweis ist für die Architektur wertvoller als eine pauschale Behauptung vollständiger Isolation, denn er zeigt, wo die Identitätsgrenze verlaufen muss.

Die zweite Schutzgrenze ist eine natürliche Erweiterung von Workers. Das öffentliche Internet ist standardmäßig erreichbar, doch enableInternet = false kehrt die Haltung um: Datenverkehr bleibt gesperrt, sofern allowedHosts oder ein Outbound-Handler ihn nicht zulässt. Ein Outbound-Handler läuft außerhalb der Sandbox in der vertrauenswürdigen Workers-Laufzeitumgebung, kann einen Authorization-Header injizieren und Zugangsdaten auf eine Sandbox-Instanz begrenzen. Der Gast erhält niemals das echte Token. Bei deaktiviertem Internet ist Nicht-HTTP-Verkehr gesperrt, und DNS darf ausschließlich Cloudflares Server verwenden. Damit wird ein naheliegender Exfiltrationsweg geschlossen.

Die beiden offen benannten Einschränkungen sind Exposition und Reifegrad. Ein Quick Tunnel verwendet einen zufälligen trycloudflare.com-Hostnamen ohne separates Zugriffstoken. Wer die URL kennt, kann ihn erreichen; eine sensible Vorschau benötigt daher weiterhin eine Authentifizierung auf Anwendungsebene. Der am 13. August aktualisierte Überblick empfiehlt @cloudflare/sandbox@next für neue Projekte und bezeichnet SDK 1.0 als Preview. Für ein frühes Produkt mit begrenztem Schadensradius kann das vertretbar sein. Ein reguliertes Unternehmen, das ausschließlich stabile Abhängigkeiten zulässt, muss möglicherweise warten oder das aktuelle stabile Paket festschreiben und auf Funktionen verzichten.

Auch Cloudflares feste Instanzgrößen verändern den Preisvergleich. Der normierte Job fordert 2 vCPU und 4 GiB an, doch die kleinste passende Instanz ist standard-3 mit 2 vCPU, 8 GiB und 16 GB Festplatte. Der niedrige Arbeitsspeicherpreis der Plattform bleibt konkurrenzfähig, allerdings wird in diesem Beispiel die Hälfte des bereitgestellten Arbeitsspeichers nicht genutzt.

Am besten geeignet für: Workers-basierte Agenten, Edge-Anwendungen, Browser-Terminals, Code-Kontexte und HTTP-lastige Workloads mit programmierbarem Egress.
Besonderheit: Zugangsdaten und Egress-Logik können außerhalb der Sandbox in Workers liegen und pro Ziel sowie Instanz begrenzt werden.
Preis: Workers Free enthält weder Containers noch Sandbox SDK. Workers Paid kostet $5/Monat und enthält 375 vCPU-Minuten, 25 GiB-Stunden Arbeitsspeicher und 200 GB-Stunden Festplatte. Zusätzliche Nutzung kostet $0.000020 pro vCPU-Sekunde, $0.0000025 pro GiB-Sekunde und $0.00000007 pro GB-Sekunde Festplatte.
Kostenlos testen: Keine eigene Sandbox-Testversion; Containers erfordert Workers Paid.

Fazit: Cloudflare ist die beste Vercel-Alternative, wenn Workers bereits die vertrauenswürdige Kontrollebene bildet und HTTP-Richtlinien die zentrale Steuerungsebene sind. Zuerst muss der Internetzugriff deaktiviert, jeder Tunnel mit Anwendungs-Authentifizierung versehen und die feste Instanzgröße ins Budget aufgenommen werden.

4. E2B: beste microVM-API für portable Agentenlaufzeiten

E2B ist die konsequenteste API-zentrierte microVM-Lösung für Teams, die eine Agenten-Sandbox unabhängig von einer größeren Bereitstellungsplattform suchen.

Jede E2B-Sandbox läuft in einer Firecracker-microVM mit eigenem Kernel, Arbeitsspeicher und Page Cache. Dieser separate Kernel ist wichtig: Selbst eine Kernel-Schwachstelle in einem Gast benötigt weiterhin einen Escape aus Firecracker, um den Host zu erreichen. Ab SDK v2.0.0 ist außerdem der sichere Controller-Zugriff standardmäßig aktiv. Für Controller-Anfragen wird das beim Erstellen der Sandbox ausgegebene Zugriffstoken benötigt. Ältere benutzerdefinierte Templates müssen möglicherweise neu gebaut werden, bevor sie mit dieser Haltung funktionieren.

Die API umfasst die entscheidenden Netzwerkprimitive: allow_internet_access, allowOut, denyOut und einen Egress-Proxy. Wird der Internetzugriff deaktiviert, entspricht das einer Sperre von 0.0.0.0/0. Die aktuelle Erstellungsanfrage macht diese Kontrollen sichtbar. Auf den zitierten Produktseiten zeigt E2B allerdings keinen so hervorgehobenen integrierten Zugangsdatenvermittler wie Vercel, Cloudflare, Daytona oder Docker. Benötigt generierter Code ein Produktiv-Token, sollte ein vertrauenswürdiger Proxy außerhalb von E2B stehen und die Zugangsdaten dort einsetzen, statt sie über eine Umgebungsvariable im Gast bereitzustellen.

E2B wird attraktiver, wenn die Kontrolle über den Bereitstellungsort ausschlaggebend ist. Enterprise BYOC unterstützt derzeit AWS und GCP; laut Anbieter verbleiben Templates, Snapshots, Laufzeitprotokolle und sensibler Datenverkehr in der VPC des Kunden. Weniger attraktiv ist das Angebot bei einer preiswerten eigenen Instanz mit 4 GiB: Die Preisseite ordnet benutzerdefinierte CPU- und RAM-Konfigurationen dem Pro-Tarif zu, der vor der Nutzung bereits $150/Monat kostet.

Hobby bietet großzügige Bedingungen zum Testen. Der Tarif kostet $0 zuzüglich Nutzung, enthält ein einmaliges Nutzungsguthaben von $100, erfordert keine Kreditkarte, ermöglicht Sitzungen bis zu 1 Stunde und unterstützt 20 gleichzeitige Sandboxes. Pro verlängert Sitzungen auf 24 Stunden und erhöht die Parallelität auf 100; zusätzliche Kapazität lässt sich bis 1,100 erwerben. Ein Upgrade hebt die Limits an, erzeugt aber kein wiederkehrendes Nutzungsguthaben.

Am besten geeignet für: API-zentrierte Agenten, Code-Interpreter, Evaluierungs-Workloads und Unternehmen, die BYOC auf AWS oder GCP benötigen.
Besonderheit: Ein eigener Firecracker-Kernel pro Sandbox hinter einer einfachen, auf Agenten zugeschnittenen API.
Preis: Hobby kostet $0 zuzüglich Nutzung. Pro kostet $150/Monat zuzüglich Nutzung. Enterprise hat einen individuellen Grundpreis zuzüglich Nutzung. CPU kostet $0.000014 pro vCPU-Sekunde beziehungsweise $0.0504 pro vCPU-Stunde; Arbeitsspeicher kostet $0.0000045 pro GiB-Sekunde beziehungsweise $0.0162 pro GiB-Stunde. Beim Speicher sind 10 GiB in Hobby und 20 GiB in Pro enthalten.
Kostenlos testen: Ein einmaliges Nutzungsguthaben von $100 in Hobby, ohne Kreditkarte.

Fazit: E2B bietet in dieser Gruppe die sauberste unabhängige microVM-API. Die Lösung passt, wenn Portabilität oder BYOC wichtiger sind als der Pro-Grundpreis. Ein vertrauenswürdiger externer Zugangsdaten-Proxy sollte von Anfang an Teil der Architektur und keine nachträgliche Härtungsmaßnahme sein.

5. Daytona: bester Zugangsdaten-Proxy mit flexiblen Laufzeitklassen

Daytona dokumentiert den klarsten Zugangsdatenvermittler dieser Gruppe und bietet außerdem die Wahl zwischen schnellen Standard-Containern sowie dedizierten Linux- oder Windows-VMs.

Das Secret-Konzept ist ungewöhnlich konkret. Daytona speichert verschlüsselte Zugangsdaten der Organisation, legt in der Sandbox lediglich einen opaken Platzhalter ab und ersetzt ihn am eigenen Proxy durch den echten Wert in einem ausgehenden HTTPS-Header. Der Proxy übermittelt den Wert nur an einen erlaubten Host und entfernt ein eventuell zurückgesendetes Secret aus der Antwort, bevor diese den Gast erreicht. Generierter Code kann ein Token verwenden, ohne es jemals lesen zu können.

Dieses Konzept besitzt eine riskante Ausnahme: Fehlt bei einem Secret das Feld hosts, gilt es als uneingeschränkt. Der Proxy darf den echten Wert dann für jedes Ziel einsetzen. Die Dokumentation empfiehlt daher, für jedes Secret eine Positivliste festzulegen. Die Ersetzung funktioniert zudem nur in HTTPS-Headern, nicht in Request-Bodys, Query-Strings, Klartext-HTTP oder transformierten Werten wie Base64-codierten Basic-Auth-Daten. Akzeptiert ein Anbieter seinen Schlüssel ausschließlich im Body, kann Daytonas Vermittler diesen Aufruf nicht schützen.

Die Netzwerkkontrollen umfassen Positivlisten für Domains und CIDRs, eine vollständige Ausgangssperre und einen vorgeschalteten Proxy. Organisationsbeschränkungen in Tier 1 und Tier 2 haben Vorrang und lassen sich nicht pro Sandbox lockern. Tier 3 und Tier 4 erlauben dagegen standardmäßig vollständigen Internetzugriff, der für potenziell schädliche Jobs eingeschränkt werden muss. Für Käufer ist nicht entscheidend, ob Daytona eine Positivliste unterstützt, sondern ob Organisationstarif und Sandbox-Konfiguration gemeinsam tatsächlich die gewünschte Richtlinie ergeben.

Die Wahl der Laufzeitumgebung ist das zweite ausschlaggebende Merkmal. Linux-Container sind der schnell startende Standard. Daneben bietet Daytona dedizierte Linux-VM- und Windows-VM-Klassen sowie GPU-Sandboxes mit H100, H200, RTX PRO 6000, RTX 5090 und RTX 4090. Für vertrauenswürdige Build-Aufgaben kann die Container-Klasse den richtigen Geschwindigkeitskompromiss liefern. Bei potenziell schädlichem mandantenfähigem Code muss die VM-Klasse bewusst gewählt werden; der Begriff Sandbox allein garantiert nicht die stärkste Grenze.

Am besten geeignet für: Agenten, die externe APIs aufrufen müssen, ohne Zugangsdaten sehen zu dürfen, gemischte Linux- und Windows-Workloads sowie GPU-gestützte Ausführung.
Besonderheit: Platzhalter-Secrets, hostgebundene HTTPS-Injektion und Bereinigung der Antwort außerhalb des Gasts.
Preis: Der öffentliche Dienst hat einen Grundpreis von $0 und wird nutzungsabhängig abgerechnet. CPU kostet $0.0504 pro vCPU-Stunde, Arbeitsspeicher $0.0162 pro GiB-Stunde und Speicher nach den ersten 5 GiB $0.000108 pro GiB-Stunde. Kundenseitig verwaltete Rechenleistung wird über den Vertrieb angeboten.
Kostenlos testen: $200 kostenloses Rechenguthaben ohne Kreditkarte.

Fazit: Daytona ist die beste Wahl, wenn die sichere Secret-Bereitstellung schwieriger ist als das Erstellen der Sandbox. hosts muss immer gesetzt, für tatsächlich schädlichen Mandantencode eine VM gewählt und die tatsächlich wirksame Netzwerkstufe der Organisation in die Freigabeprüfung aufgenommen werden.

6. Northflank: beste Lösung für BYOC und Plattformkontrolle

Northflank ist die beste Option, wenn die Sandbox im eigenen Cloud-Konto liegen und sich eine umfassendere Anwendungsplattform mit Diensten, Datenbanken, Jobs und Richtlinien teilen soll.

Northflank bietet Kata-Container-microVMs oder gVisor für eine Workload-Isolation auf VM-Niveau. Laut aktueller Infrastrukturseite erhält jeder Container einen eigenen Kernel und wird durch Namespace-, Ressourcen-, Speicher- und Netzwerkgrenzen abgeschirmt. Ein Service Mesh ergänzt gegenseitiges TLS zwischen Workloads; Netzwerkrichtlinien auf Projektebene und private Vernetzung verringern unbeabsichtigte projektübergreifende Zugriffe.

Das Bereitstellungsspektrum ist breiter als bei allen API-zentrierten Runnern in diesem Vergleich. Northflank kann die eigene Managed Cloud verwenden oder AWS-, GCP-, Azure- oder Civo-Konten anbinden. Darüber hinaus wird kundeneigenes Kubernetes lokal, auf Bare Metal oder in einer Public Cloud unterstützt. Auf microVM-fähigen BYOC-Node-Pools erhalten Workloads standardmäßig microVM-Isolation. Das passt gut zu Datenresidenz, bestehenden Cloud-Verträgen, Zugriffen auf private Dienste und Unternehmen, die Anwendungs- und Sandbox-Infrastruktur gemeinsam steuern möchten.

Dieselbe Breite ist zugleich die Kehrseite. Ein kleines Agentenprodukt braucht nicht automatisch Cluster, Projekte, Service Mesh, Bereitstellungsvorlagen, Datenbanken und eine Plattform-Kontrollebene. Northflank kann in diesem Vergleich die niedrigste Ressourcenschätzung erzielen und organisatorisch dennoch teurer sein, wenn niemand die Plattform verantwortet. Die passende Käufergruppe will BYOC oder die umgebende Plattform ohnehin. Alle anderen sollten die Entwicklungsstunden mit Vercel oder E2B vergleichen, bevor sie den niedrigen Stückpreis feiern.

Der kostenlose Sandbox-Tarif eignet sich zum Kennenlernen der Plattform und enthält 2 kostenlose Dienste, 1 kostenlose Datenbank und 2 kostenlose Cronjobs. Produktive Rechenleistung wird sekundengenau mit $0.01667 pro vCPU-Stunde und $0.00833 pro GB-Stunde berechnet. Egress kostet $0.06 pro GB und SSD-Speicher $0.15 pro GB-Monat.

Am besten geeignet für: BYOC, private Dienste, Anforderungen an die Datenresidenz und Teams, die eine Plattform für Sandboxes und Anwendungsinfrastruktur suchen.
Besonderheit: Kata- oder gVisor-Isolation in verwalteten oder kundeneigenen Cloud-Bereitstellungen.
Preis: Sandbox ist kostenlos. Die nutzungsabhängige Abrechnung beginnt bei $0/Monat und berechnet $0.01667 pro vCPU-Stunde, $0.00833 pro GB-Stunde Arbeitsspeicher, $0.06 pro GB Egress und $0.15 pro GB-Monat SSD. Enterprise wird individuell angeboten.
Kostenlos testen: Ein kostenloser Sandbox-Tarif mit 2 Diensten, 1 Datenbank und 2 Cronjobs.

Fazit: Northflank ist die richtige Antwort, wenn die Platzierung in der eigenen Cloud oder eine einheitliche Plattform zwingend erforderlich ist. Für ein Produktteam aus zwei Personen ist es nicht automatisch das Schnäppchen, denn der niedrigste Verbrauchspreis kann dennoch die größte Plattformaufgabe erzeugen.

7. Modal: beste Wahl für Python-, ML- und GPU-intensive Ausführung

Modal ist hier die beste Sandbox, wenn generierter Code eng mit Python, Notebooks, Modellinferenz oder stoßweisen GPU-Workloads verbunden ist.

Modal Sandboxes verwendet gVisor, das Systemaufrufe zwischen Gast-Workload und Host-Kernel abfängt und beschränkt. Eine Standard-Sandbox kann weder eingehende Netzwerkverbindungen annehmen noch auf andere Modal-Ressourcen zugreifen. Das begrenzt den Schadensradius innerhalb der Plattform und schafft eine starke Ausführungsgrundlage für Datenanalyse und modellintensive Jobs.

Die ausgehende Richtlinie ist weniger konservativ. Sandboxes können standardmäßig jede öffentliche IP-Adresse erreichen. Modal unterstützt eine vollständige Netzwerksperre, CIDR-Positivlisten und eine Beta-Domain-Positivliste für TLS-Verkehr; diese Kontrollen müssen jedoch aktiv eingeschaltet werden. Auch spätere Richtlinienänderungen setzen eine bestimmte Einrichtung voraus: Damit eine Domain- oder CIDR-Liste nachträglich verschärft werden kann, muss die Sandbox mit der jeweiligen Positivlisten-Kategorie erstellt worden sein. block_network=True lässt sich nicht über denselben dynamischen Weg ändern. Ein Agent, der das Netzwerk nur während der Einrichtung öffnet, braucht daher einen vorab entworfenen Lebenszyklus.

Der wirtschaftliche Vorteil von Modal liegt in der umgebenden serverlosen ML-Plattform und nicht im niedrigsten Sandbox-Verbrauchspreis. Ein physischer Kern entspricht 2 vCPU und kostet $0.00003942 pro Kernsekunde. Arbeitsspeicher kostet $0.00000667 pro GiB-Sekunde. Starter kostet $0 zuzüglich Rechenleistung, enthält $30 monatliches Guthaben, 3 Workspace-Arbeitsplätze sowie Parallelität für 100 Container und 10 GPUs. Team kostet $250/Monat zuzüglich Rechenleistung, enthält dafür $100 monatliches Guthaben und ergänzt unbegrenzte Arbeitsplätze, eine Parallelität von 5,000 Containern und 50 GPUs, einen Proxy mit statischer IP-Adresse, Umgebungsbudgets, eigene Domains und Rollbacks von Bereitstellungen.

Damit ist Modal leicht zu rechtfertigen, wenn dieselbe Plattform außerdem Modelle, geplante Funktionen und GPU-Jobs ausführt. Schwieriger wird die Begründung für einen einfachen Code-Interpreter, dessen wichtigste Anforderungen microVM-Isolation und Zugangsdatenvermittlung sind. Die aktuelle Sicherheitsseite für Sandboxes dokumentiert Netzwerkkontrolle und Plattformisolation, aber keinen externen Mechanismus zur Secret-Injektion, der so ausdrücklich beschrieben wäre wie bei Daytona oder Cloudflare.

Am besten geeignet für: Python-Agenten, Notebooks, Datenanalyse, ML-Pipelines und GPU-intensive Ausführung von generiertem Code.
Besonderheit: gVisor-Sandboxes als Teil von Modals serverloser CPU- und GPU-Plattform.
Preis: Starter kostet $0 zuzüglich Rechenleistung und enthält $30 monatliches Guthaben. Team kostet $250/Monat zuzüglich Rechenleistung und enthält $100 monatliches Guthaben. Enterprise wird individuell angeboten. Sandbox-CPU kostet $0.00003942 pro physische Kernsekunde, wobei 1 Kern 2 vCPU entspricht; Arbeitsspeicher kostet $0.00000667 pro GiB-Sekunde.
Kostenlos testen: $30 wiederkehrendes monatliches Starter-Guthaben.

Fazit: Modal gewinnt, wenn die Sandbox Teil eines ML- oder GPU-Systems ist. Für eine einfache API zur Ausführung potenziell schädlichen Codes führen Vercel, Cloudflare, E2B oder Daytona den Sicherheitsverantwortlichen direkter ans Ziel.

Was die monatliche Rechnung wirklich aussagt

Die günstigste verwaltete Schätzung beträgt $55.55, die höchste $288. Das ergibt eine monatliche Spanne von $232.45. Bei hohem Volumen ist das relevant, aber verglichen mit einer Fachkraft für die Wartung eines internen Runners oder einem einzigen Vorfall mit offengelegtem Produktiv-Token bleibt der Betrag klein. Aus Sicherheitssicht sollte ein Team deshalb weder Klartext-Secrets noch offenen Egress akzeptieren, um einen niedrigen dreistelligen Monatsbetrag zu sparen.

Das sind Vergleichsschätzungen und keine Rechnungen. Bei Vercel wird angenommen, dass der Pro-Grundpreis von $20 durch die enthaltenen $20 Nutzungsguthaben ausgeglichen wird. Cloudflare muss eine standard-3-Instanz mit 8 GiB und 16 GB Festplatte zuweisen, um die Anforderung von 2 vCPU zu erfüllen. E2B enthält den Pro-Tarif für $150, weil der Vergleich eine eigene Zuteilung von 4 GiB verwendet. Bei Modal ist das wiederkehrende Starter-Guthaben von $30 abgezogen. Daytonas $200 und E2Bs $100 sind einmalige Guthaben und reduzieren daher nicht den Wert für den Dauerbetrieb.

Das Abrechnungsmodell kann die Reihenfolge umkehren. Vercel und Cloudflare berechnen aktive CPU-Zeit, sodass ein I/O-gebundener Agent während Wartephasen weniger kostet. Rechnet die CPU alle 5 Minuten, steigt Vercel von $113.34 auf $284.01 und Cloudflare von $91.63 auf $187.63. Für einen kompilierintensiven Coding-Agenten muss der ausgelastete Fall modelliert werden. Ein Browser-Agent, der auf Seiten wartet, dürfte eher bei der Annahme von 1 Minute liegen.

Der praktische Break-even zwischen Vercel und Daytona liegt bei 1.58 aktiven CPU-Minuten innerhalb einer 5-minütigen Ausführung, also ungefähr 95 Sekunden. Unterhalb dieses Punkts gewinnt in diesem Modell Vercels Abrechnung aktiver CPU-Zeit; oberhalb sind Daytonas Pauschalsätze für die Laufzeit vor Netzwerk und Speicher günstiger. Dahinter steckt eine Entscheidung über den Workload, die wie eine Preisfrage aussieht: Für die Budgetplanung zählt die tatsächliche Rechenzeit des Agenten, nicht allein seine Gesamtlaufzeit.

Der größere Budgetposten ist die Verantwortung. Northflanks Schätzung von $55.55 wirkt außergewöhnlich günstig, bis Cluster, Richtlinien, Bereitstellungsvorlagen, Incident Response und eine entsprechend qualifizierte Fachkraft hinzukommen. E2Bs $288 erscheinen teuer, bis BYOC den Aufbau einer separaten Plattform erspart. Ein solider Einkauf vergleicht den gesamten Betriebsaufwand und nicht nur den vCPU-Preis.

Welches Tool passt zu welchem Einsatz?

Vercel Sandbox ist die Wahl für eine starke verwaltete Standardlösung, sofern die Netzwerkrichtlinie vor der nicht vertrauenswürdigen Phase konsequent verschärft wird. BYOC, lokale Ausführung oder umfassende GPU-Funktionen verschieben die Entscheidung weg von Vercel.

Docker Sandboxes passt, wenn Entwickler Codex, Claude Code, Copilot CLI, OpenCode oder Kiro lokal ausführen. Für riskante Repositorys empfiehlt sich der Klonmodus. Sobald Kundenjobs, hohe Parallelität, zentrale Verfügbarkeit oder Remote-APIs gefordert sind, kippt die Entscheidung zu einem verwalteten Tool.

Cloudflare Sandbox SDK ist sinnvoll, wenn Workers bereits die vertrauenswürdige Kontrollebene bildet und die meisten zugelassenen Aufrufe über HTTP laufen. Ein SDK vor Version 1.0 oder feste Container-Größen können jedoch mehr Risiko erzeugen, als sie beseitigen.

E2B eignet sich für eine unabhängige Firecracker-API oder BYOC auf AWS und GCP. Dagegen sprechen der schwer zu rechtfertigende Pro-Grundpreis von $150 bei eigenem Arbeitsspeicher oder der Wunsch, keinen externen Zugangsdaten-Proxy bauen zu müssen.

Daytona passt, wenn der Agent externe Dienste mit einem Secret aufrufen muss, das er nicht lesen darf, oder wenn Linux-VM-, Windows-VM- und GPU-Klassen hinter einer API benötigt werden. Sind alle Workloads einfache Linux-microVMs, können die zusätzlichen Laufzeitvarianten unnötige Komplexität schaffen.

Northflank ist die richtige Wahl, wenn Sandboxes neben privaten Diensten im eigenen Cloud-Konto liegen müssen. Die Entscheidung fällt dagegen aus, wenn eine Organisation nur zur Einsparung beim Verbrauchspreis erst ein Plattformteam aufbauen müsste.

Modal passt, wenn die Ausführung untrennbar mit Python, Notebooks, Modellinferenz, geplanten Funktionen oder GPUs verbunden ist. Geht es ausschließlich um potenziell schädlichen Code, führt eine stärker sicherheitsorientierte API mit weniger Richtlinienarbeit ans Ziel.

Wer vor der Laufzeitumgebung zunächst den Agenten auswählt, findet diese vorgelagerte Entscheidung im Vergleich der besten KI-Coding-Assistenten. Beide Fragen sollten getrennt bleiben: Der Assistent bestimmt, wie Arbeit erzeugt wird; die Sandbox legt fest, worauf diese erzeugte Arbeit zugreifen darf.

Welche Sandboxing-Tools sind zu vermeiden?

Ein Runner, dessen Sicherheitsdokumentation bei „isoliert“ endet: Der Einkauf braucht schriftliche Antworten zur Kernel-Grenze, Mandantentrennung, standardmäßigem Egress, Speicherort der Zugangsdaten, Protokollierung und Update-Verantwortung. Kann der Anbieter nicht alle sechs Punkte beantworten, gehören weder Produktivdaten noch Schlüssel in den Gast.

Ein einfacher Docker-Engine-Container, der mit Docker Sandboxes verwechselt wird: docker run ist nicht das sbx-microVM-Produkt und erbt weder dessen separaten Kernel noch den hostseitigen Netzwerk-Proxy, die Zugangsdaten-Injektion oder die Workspace-Grenze des Klonmodus. Namen ersetzen keine Architektur.

Docker Sandboxes im direkten Modus für ein unbekanntes Repository: Die VM schützt den Großteil des Hosts, doch der Agent bearbeitet den Arbeitsbaum unmittelbar. Ein veränderter Git-Hook oder ein Paketskript kann später auf dem Host ausgeführt werden. Deshalb --clone verwenden und jede Brücke aus der VM prüfen.

Ein Cloudflare Quick Tunnel ohne Authentifizierung auf Anwendungsebene: Der zufällige Hostname besitzt kein separates Zugriffstoken. Die URL ist als auffindbar zu behandeln; vor dem Freigeben einer sensiblen Vorschau muss der Dienst selbst eine Authentifizierung erhalten.

Ein Daytona-Secret ohne hosts: Fehlt das Feld, ist das Secret uneingeschränkt. Der Vermittler bietet nur dann einen Vorteil, wenn das zulässige Ziel ausdrücklich benannt ist.

Eine Einrichtungsphase, die auf allow-all stehen bleibt: Vercel dokumentiert das richtige Muster eindeutig: breiter Zugriff für die Einrichtung, danach eine beschränkte Ausführungsphase. Wird die Richtlinie niemals verschärft, begrenzt die microVM zwar eine Kompromittierung des Hosts, hindert den Code aber nicht an der Datenübertragung nach außen.

Genau dieser letzte Punkt trennt die Kategorie. Isolation beantwortet die Frage: „Kann der Code ausbrechen?“ Egress- und Zugangsdatenrichtlinien beantworten: „Was kann der Code tun, ohne auszubrechen?“ Beide Fehler können dasselbe Geschäftsergebnis haben: Produktivdaten verlassen das Unternehmen.

Der konkrete Schritt für Montag

Der Montag sollte nicht mit einer Anbieterdemo beginnen, sondern mit einer einseitigen Bestandsaufnahme aller Stellen, an denen modellgenerierter Code läuft.

1. Jeden Ausführungspfad benennen. Dazu zählen lokale Coding-Agenten, CI-Jobs, Browser-Agenten, Datenanalyse-Notebooks, Code-Interpreter und Preview-Builder für Kunden.
2. Die aktuelle Grenze einzeichnen. Zu dokumentieren sind Kernel- oder Laufzeitisolation, eingebundene Dateien, erreichbare Netzwerke und sämtliche Zugangsdaten, die dem Gast zur Verfügung stehen.
3. Secrets nach außen verlagern. API-Schlüssel gehören in eine vertrauenswürdige Orchestrierung, einen Worker, Host-Proxy oder Zugangsdatenvermittler des Anbieters. Eine Umgebungsvariable der Sandbox bleibt für den Code lesbar.
4. Egress standardmäßig sperren. Während der Einrichtung darf der Paket-Host erreichbar sein; vor dem Start des generierten Codes wird auf die kleinstmögliche Zielliste umgestellt.
5. Zwei Negativtests durchführen. Zuerst wird versucht, die Datei oder den Prozess eines anderen Mandanten zu lesen; danach soll ein präpariertes Token an einen nicht zugelassenen Host gesendet werden. Erforderlich sind sowohl eine Blockierung als auch ein brauchbarer Protokolleintrag.
6. Verantwortung und Limits festlegen. Eine benannte Person muss Richtlinienänderungen, fehlgeschlagene Grenztests, Images, Protokolle und Ausgaben prüfen. Laufzeit-, Parallelitäts-, CPU-, Arbeitsspeicher- und Monatslimits gehören festgelegt, bevor der Datenverkehr skaliert.

Erst wenn diese Seite vorliegt, sollte der Einkauf beginnen. Bei ausschließlich lokalem Risiko können Docker Sandboxes im Klonmodus ausreichen. Ein Vercel-Produktteam benötigt womöglich nur eine geänderte Netzwerkrichtlinie und vermittelte Secrets. Eine regulierte Plattform stellt vielleicht fest, dass Northflank oder E2B BYOC gerechtfertigt ist. Das Ergebnis für Montag ist eine Entscheidung über Schutzgrenzen und kein neues Abonnement.

Häufig gestellte Fragen

Welches KI-Tool bietet die beste Sicherheit?

Vercel Sandbox ist in diesem Vergleich die beste verwaltete Gesamtlösung, weil das Produkt eine Firecracker-microVM, laufzeitbasierte Egress-Richtlinien und Zugangsdatenvermittlung kombiniert. Für lokale Coding-Agenten ist Docker Sandboxes stärker; bei zwingender Bereitstellung in der eigenen Cloud liegen Northflank oder E2B vorn. Die erforderliche Vertrauensgrenze entscheidet über den Sieger.

Welche Trends prägen die KI-Sicherheit 2026?

Der praktische Trend geht zu separaten Kernels, außerhalb des Gasts injizierten Zugangsdaten, standardmäßig gesperrtem Egress und wiederkehrenden Grenztests. OpenAIs Empfehlung vom 10. August macht die betriebliche Folge deutlich: Leistungsfähige Agenten müssen von Produktivsystemen und dem offenen Internet isoliert und ihre Versuche anschließend überwacht werden.

Gibt es 2026 kostenlose KI-Sandbox-Tools?

Ja. Docker Sandboxes bietet eine CLI für $0 ohne Gebühr pro Arbeitsplatz. Vercel hat einen begrenzten Hobby-Tarif, E2B stellt einmalig $100 Guthaben bereit, Daytona bietet $200 Rechenguthaben, Northflank hat einen kostenlosen Sandbox-Tarif und Modal enthält $30 wiederkehrendes monatliches Starter-Guthaben. Cloudflare Sandbox setzt den Workers-Paid-Tarif für $5/Monat voraus.

Was ist eine KI Sandbox?

Eine KI Sandbox ist eine isolierte Ausführungsumgebung, in der ein Agent generierten Code ausführen kann, ohne umfassenden Zugriff auf den Host, andere Nutzer, Produktivsysteme, Secrets oder unbeschränkte Netzwerkpfade zu erben. Eine produktionsreife Sandbox umfasst sowohl eine Ausführungsgrenze als auch eine eigene Grenze für Egress und Zugangsdaten.

Checkliste für das Audit von KI-Geschäftsworkflows herunterladen, um aus der Sandbox-Entscheidung einen abgegrenzten Workflow mit verantwortlicher Person, Kontrollliste und Prüfintervall zu machen.