Open-Source-KI-Agenten-Sandbox-Optionen: Was vor dem Self-Hosting zu prüfen ist

Teams, die Open-Source-KI-Agenten-Sandboxes evaluieren, sollten zuerst die tatsächliche Isolationsgrenze, das Persistenzmodell des Workspace, die Egress- und Paketkontrollen, das Secret-Handling, die Auditierbarkeit und den Betriebsaufwand prüfen, der für den sicheren Betrieb erforderlich ist. Die richtige Wahl hängt weniger davon ab, einen universellen Gewinner zu finden, sondern vielmehr davon, ein Sandbox-Modell an Ihr Bedrohungsmodell, Ihre Agenten-Workload, Compliance-Anforderungen und Ihre Engineering-Kapazitäten anzupassen.

Was gilt als KI-Agenten-Sandbox?

Eine KI-Agenten-Sandbox ist eine Ausführungsumgebung, in der ein Agent Code ausführen, Dateien inspizieren, einen Browser automatisieren, Tools aufrufen oder eine Aufgabe erledigen kann, ohne breiten Zugriff auf den Host-Rechner oder das Produktionsnetzwerk zu erhalten. Sie ist die Grenze zwischen Modell-Argumentation und realen Nebenwirkungen.

Diese Grenze ist wichtig, weil moderne Agenten mehr tun, als nur Text zu schreiben. Ein Code-Agent kann ein Repository klonen, Abhängigkeiten installieren, Tests ausführen, Vorschau-Ports öffnen und einen Pull-Request schreiben. Ein Browser- oder Daten-Agent kann Skripte ausführen, Zustände halten, Dateien herunterladen und Screenshots erstellen. Diese Aktionen benötigen eine Laufzeitumgebung, und die Laufzeitumgebung benötigt Kontrollen.

Für eine Evaluierung trennen Sie vier Ebenen:

Ebene	Was sie bestimmt	Warum sie wichtig ist
Agenten-Framework	Wie das Modell plant, Tools aufruft und auf Ergebnisse reagiert	Ein gutes Framework erzeugt nicht automatisch eine sichere Laufzeit
Sandbox-Laufzeit	Wo Befehle, Dateien, Browser-Sitzungen und Prozesse ausgeführt werden	Dies ist die wichtigste Isolations- und Lebenszyklusgrenze
Policy-Ebene	Was die Sandbox lesen, abrufen, installieren, bereitstellen oder behalten darf	Dies bestimmt, ob die Sandbox zu Ihrem Risikomodell passt
Prüfebene	Welche Logs, Diffs, Artefakte und Genehmigungen nach dem Lauf verfügbar sind	Dies bestimmt, ob ein Mensch überprüfen kann, was passiert ist

Self-Hosted- und Open-Source-Optionen können Teams mehr Kontrolle über diese Ebenen geben. Sie verlagern auch mehr Verantwortung auf das Team, das sie betreibt.

Wann ist Self-Hosting sinnvoll?

Self-Hosting kann sinnvoll sein, wenn Ihr Team die direkte Kontrolle über den Bereitstellungsort, Netzwerkpfade, Basis-Images, Aufbewahrungsregeln, Protokollierungssysteme oder interne Sicherheitsüberprüfungen benötigt.

Es ist weniger attraktiv, wenn die eigentliche Anforderung einfach darin besteht, „einen Agenten sicher Code ausführen zu lassen“. In diesem Fall kann eine verwaltete Sandbox einfacher zu betreiben sein, da der Anbieter die Bereitstellung, Skalierung, Laufzeit-Updates, Verfügbarkeit und Teile der Entwicklererfahrung übernimmt.

Nutzen Sie Self-Hosting, wenn mindestens eine der folgenden Bedingungen zutrifft:

• Ihre Richtlinie erfordert die Ausführung innerhalb eines bestimmten Cloud-Kontos, VPC, einer Region oder eines privaten Netzwerks.
• Ihre Agenten benötigen benutzerdefinierte Basis-Images, interne Paket-Mirrors, private Quellsysteme oder interne Browser-Ziele.
• Ihr Sicherheitsteam möchte den Isolations-Stack, den Egress-Pfad, das Aufbewahrungsmodell und die Logs inspizieren.
• Sie haben die Engineering-Kapazität, um Laufzeitkomponenten zu patchen, Missbrauchssignale zu überwachen, Secrets zu rotieren und Fehler zu beheben.

Vermeiden Sie Self-Hosting standardmäßig, wenn Sie die betriebliche Arbeit nicht personell stemmen können. Sandboxes sehen in Demos einfach aus, weil ein einzelner Container oder eine VM einen Befehl ausführen kann. Die Produktion ist anders: Sie benötigen Nebenläufigkeitsgrenzen, Ressourcenkontingente, Image-Bereinigung, Paket-Cache-Strategie, Netzwerkrichtlinien, Secret-Scoping, Telemetrie, Incident Response und einen klaren Upgrade-Pfad.

Zu evaluierende Open-Source-Sandbox-Optionen

Die Open-Source-Landschaft entwickelt sich schnell, daher behandeln Sie dies als eine datierte Orientierung und nicht als eine dauerhafte Feature-Matrix. Stand 24. Juni 2026 sind die folgenden Projekte und Tools nützliche Beispiele, die Sie inspizieren sollten, wenn Sie Self-Hosted- oder Open-Source-Agenten-Sandbox-Pfade vergleichen.

Option	Was zuerst prüfen	Self-Hosting-Frage
E2B	Open-Source-Sandbox-/Runtime-Komponenten, SDKs, Vorlagen und Firecracker-basierte Sandbox-Positionierung	Welche Teile sind Open Source, welche Bereitstellungsmodi werden heute unterstützt und welche betriebliche Arbeit bleibt für Ihr Team?
Daytona	Workspace- und Sandbox-Infrastruktur für Entwicklungs- und KI-Agenten-Anwendungsfälle mit Open-Source-Repositories und Dokumentationspfaden für Self-Hosting	Passt das Workspace-Modell, die API-Oberfläche und die Bereitstellungsarchitektur zu Ihrer Agenten-Workload und Sicherheitsrichtlinie?
OpenHands	Agenten-Plattform mit einer dokumentierten Laufzeitarchitektur, die sandboxierte Umgebungen zur Ausführung von Agentenaktionen verwendet	Übernehmen Sie die vollständige Agenten-Plattform oder leihen Sie sich nur das Laufzeitmuster aus?
SWE-ReX	Open-Source-Laufzeitschnittstelle, die in der Software-Engineering-Agentenforschung und Evaluierungs-Workflows verwendet wird	Passt seine Abstraktion zu Ihren Produktionsanforderungen oder ist es hauptsächlich für kontrollierte Evaluierungsumgebungen nützlich?
Modal Sandbox	Verwaltete Sandbox-API anstelle einer Open-Source-Self-Hosted-Laufzeit	Nützlich als Vergleichspunkt für API-Ergonomie, Prozessausführung, Dateisystem und Timeout-Verhalten, nicht als Self-Hosted-Option

Wählen Sie nicht allein anhand einer Tabelle aus. Lesen Sie für jedes Projekt die aktuellen Dokumentationen, überprüfen Sie die neuesten Versionshinweise und führen Sie einen kleinen Proof-of-Concept mit Ihrer eigenen Workload durch. Die Evaluierung sollte beantworten: Was kann ausgeführt werden, was ist isoliert, was bleibt bestehen, was kann das Netzwerk erreichen, was kann Secrets sehen und welche Beweise bleiben nach der Aufgabe zurück.

Isolationsgrenze: Container, MicroVMs und vollständige VMs

Die erste Frage ist nicht „ist es sicher?“. Die nützliche Frage ist: „Was ist die Isolationsgrenze?“

Container sind attraktiv, weil sie schnell, vertraut und einfach um Docker-Images herum zu bauen sind. Sie können für vertrauenswürdige interne Aufgaben, CI-ähnliche Arbeiten, kurzlebige Analysen und Entwicklungsworkflows geeignet sein, bei denen das Bedrohungsmodell moderat ist. Aber Container teilen sich den Host-Kernel, daher müssen Teams, die mit nicht vertrauenswürdigem Code oder Multi-Tenant-Workloads umgehen, die Kernel-Exposition, seccomp/AppArmor-Profile, Benutzernamensräume, eingehängte Volumes, privilegierten Modus und die Reaktion auf Ausbrüche evaluieren.

MicroVMs, wie die Firecracker-artige Isolation, fügen eine stärkere VM-Grenze hinzu, während sie Startzeit und Dichte näher an Container-Workflows als an traditionellen VMs halten. Sie sind in Agenten-Sandbox-Diskussionen üblich, weil sie jeder Sitzung einen separaten Kernel und eine engere Ressourcengrenze geben können. Das entbindet nicht von der Notwendigkeit von Netzwerkrichtlinien, Secret-Kontrollen, Patchen oder Host-Härtung; es klärt lediglich die Laufzeit-Isolationsebene.

Vollständige VMs können für strengere Unternehmensumgebungen, Desktop-Automation oder Workflows geeignet sein, die eine breitere OS-Oberfläche benötigen. Der Kompromiss sind schwerfälligerer Start, Image-Verwaltung und Kapazitätsplanung.

Stellen Sie diese Fragen, bevor Sie self-hosten:

Prüfung	Was zu verifizieren ist
Kernel-Grenze	Teilt die Sandbox einen Kernel mit anderen Workloads oder erhält jede Sitzung einen separaten Kernel?
Tenant-Grenze	Können zwei Kundensitzungen jemals Host-Level-Ressourcen, Volumes, Caches, Browser-Profile oder Netzwerk-Namensräume gemeinsam nutzen?
Privilegienmodell	Führt die Sandbox privilegierte Container, Root-Benutzer, eingehängte Docker-Sockets oder Host-Pfade aus?
Escape-Posture	Wie werden Kernel-, Laufzeit-, Container- und Hypervisor-Schwachstellen gepatcht und ausgerollt?
Ressourcenkontrollen	Werden CPU, Speicher, Festplatte, Prozessanzahl, offene Dateien und Laufzeitdauer pro Sitzung durchgesetzt?
Seitenkanäle	Erfordert Ihr Risikomodell eine Abschwächung von gemeinsam genutzter CPU, Cache, Festplatte oder „lauter Nachbar“-Verhalten?

Wenn ein Projekt sich selbst als „isoliert“ beschreibt, lesen Sie weiter, bis Sie den Mechanismus kennen.

Zustand, Dateien und Workspace-Lebenszyklus

Die Arbeit von Agenten ist zustandsbehaftet, selbst wenn die Sandbox kurzlebig ist. Der Agent kann Dateien erstellen, Pakete installieren, ein Browser-Profil behalten, Hintergrundprozesse ausführen oder pausieren, während ein Mensch ein Artefakt überprüft. Ihre Sandbox benötigt ein klares Workspace-Modell.

Beginnen Sie mit dem Lebenszyklus:

1. Erstellen einer Sandbox aus einem Basis-Image oder einer Vorlage.
2. Einhängen oder Klonen des erlaubten Workspace.
3. Ausführen von Setup-Befehlen unter Richtlinie.
4. Lassen Sie den Agenten Befehle, Browser-Aktionen und Dateioperationen ausführen.
5. Extrahieren von Ausgaben: Diffs, Logs, Screenshots, Berichte oder heruntergeladene Dateien.
6. Stoppen, Pausieren, Snapshot, Archivieren oder Zerstören der Sandbox.

Der entscheidende Punkt ist, dass Persistenz beabsichtigt sein sollte. Persistente Workspaces sind nützlich für langlebige Agenten, mehrstufige Codierungsaufgaben und Human-in-the-Loop-Überprüfungen. Sie sind auch der Ort, an dem veraltete Anmeldeinformationen, zwischengespeicherte Abhängigkeiten, Browser-Cookies, generierte Daten und Teil-Arbeiten über Sitzungen hinweg durchsickern können, wenn die Bereinigung schwach ist.

Definieren Sie vor dem Self-Hosting:

• Ob jede Agentenaufgabe ein neues Dateisystem erhält.
• Ob Paket-Caches geteilt, gescoped oder neu aufgebaut werden.
• Ob Browser-Profile zwischen Läufen bestehen bleiben.
• Ob Benutzer-Uploads kopiert, eingehängt oder gestreamt werden.
• Ob Snapshots Secrets, Tokens, Cookies oder interne Logs enthalten.
• Wie lange Logs und Artefakte aufbewahrt werden.
• Wer eine pausierte Sitzung wieder öffnen kann.

Eine gute Sandbox macht den Standard-Lebenszyklus langweilig. Sie sollten erklären können, was vor dem Start der Aufgabe existiert, was sich während der Aufgabe ändert und was nach der Bereinigung übrig bleibt.

Netzwerk, Pakete und Egress-Richtlinie

Netzwerkzugriff ist der Bereich, in dem viele Sandbox-Designs vage werden. Agenten brauchen oft das Internet, aber „Internetzugriff“ ist nicht eine einzige Berechtigung.

Ein Code-Agent benötigt möglicherweise Paket-Repositories, öffentliche Dokumentationen, Git-Remotes und eine Vorschau-URL. Ein Browser-Agent benötigt möglicherweise eine Testanwendung, eine Staging-API und Screenshot-Speicher. Ein Daten-Agent benötigt möglicherweise Objektspeicher, eine Datenbank-Replica oder eine eingeschränkte SaaS-API. Dies sind unterschiedliche Berechtigungen mit unterschiedlichen Risiken.

Verwenden Sie Kategorien:

Egress-Typ	Typischer Bedarf	Policy-Frage
Paket-Repositories	npm, pip, apt, cargo, Modell-/Tool-Abhängigkeiten	Sind Repositories auf eine Whitelist gesetzt, zwischengespeichert, gescannt und protokolliert?
Öffentliches Web	Dokumentationssuche, Browser-Aufgaben, Sammlung öffentlicher Daten	Ist willkürliches Surfen erlaubt, per Proxy geleitet, ratenbegrenzt und prüfbar?
Git-Zugriff	Repos klonen, Branches pushen, Submodule abrufen	Sind Tokens nach Möglichkeit schreibgeschützt und auf die Aufgabe beschränkt?
Interne APIs	Staging-Dienste, Test-Apps, private Paket-Mirrors	Ist der Zugriff auf Umgebung, Dienst, Route und Berechtigungsnachweis beschränkt?
Vorschau-Ingress	Menschliche Überprüfung lokaler Web-Apps oder generierter Berichte	Welcher Port wird freigegeben, für wen, wie lange und mit welcher Authentifizierung?
Webhooks	Agent-Callbacks, CI-Ereignisse, externe Tool-Integration	Kann die Sandbox ausgehende Callbacks an beliebige Hosts senden?

Paketrichtlinien verdienen besondere Aufmerksamkeit. Viele Agentenaufgaben scheitern ohne Abhängigkeitsinstallationen, aber Paketinstallationen bringen Post-Install-Skripte, native Binärdateien, Repository-Kompromittierung, Typosquatting-Risiko und lange Cache-Lebensdauern mit sich. Bevorzugen Sie Lockfile-basierte Installationen, genehmigte Repositories, kurzlebige Tokens und Installationsprotokolle.

Entscheiden Sie bei selbst gehosteten Systemen auch, wer für DNS-Logs, Proxy-Konfiguration, Zertifikatsspeicher und Netzwerk-Incident-Response zuständig ist.

Secrets, Logs und Prüfpfade

Eine Agenten-Sandbox sollte nicht zu einem Ort werden, an dem rohe Anmeldeinformationen für das Modell leicht auszugeben, zu kopieren oder zu exfiltrieren sind.

Das sicherste Muster ist der aufgabenbezogene Zugriff. Geben Sie der Sandbox die minimalen Anmeldeinformationen, die für den Job erforderlich sind, und entfernen Sie sie, wenn der Job endet. Eine Codierungsaufgabe benötigt möglicherweise ein schreibgeschütztes Repository-Token und ein Pull-Request-Token. Eine Browser-Aufgabe benötigt möglicherweise ein Testkonto, keinen Produktionsbenutzer. Eine Datenaufgabe benötigt möglicherweise eine temporäre signierte URL, keine dauerhaften Cloud-Anmeldeinformationen.

Vermeiden Sie Secrets in Dateien, die der Agent beiläufig lesen kann. Umgebungsvariablen sind praktisch, aber viele Debugging-Befehle geben den Umgebungszustand aus. Wenn die Plattform vermittelte Aktionen unterstützt, verwenden Sie diese: Lassen Sie die Sandbox eine enge Operation ausführen, ohne die rohen Anmeldeinformationen der Modellschleife auszusetzen.

Die Protokollierung sollte stark genug für Überprüfung und Incident Response sein:

• Angeforderte, genehmigte, abgelehnte und ausgeführte Befehle.
• Arbeitsverzeichnis, Exit-Code, stdout, stderr, Timeout und Ressourcennutzung.
• Von der Aufgabe erzeugte Dateiartefakte.
• Netzwerkziele in der Granularität, die Ihre Richtlinie unterstützt.
• Paketnamen, Versionen, Repositories und Installationsausgabe.
• Entscheidungen zur Schwärzung von Secrets und Fehler bei der Schwärzung.
• Menschliche Genehmigungen für riskante Aktionen.

Das Ziel ist nicht, Prüfer mit Logs zu ertränken. Das Ziel ist, rekonstruieren zu können, was passiert ist, wenn ein Agent ein überraschendes Ergebnis liefert, sich eine Abhängigkeit ändert oder der Verdacht auf Offenlegung eines Tokens besteht.

Zurücksetzen, Snapshots und Multi-Tenant-Risiko

Das Zurücksetzungsverhalten ist ein Produktionsmerkmal, kein Bereinigungsskript am Ende einer Demo.

Ephemere Sandboxes sind einfacher zu durchdenken: Erstellen, Ausführen, Artefakte extrahieren, zerstören. Sie funktionieren gut für kurze Codeausführung, einmalige Browser-Aktionen und Evaluierungsjobs. Persistente Sandboxes helfen bei längeren Workflows, benötigen aber Eigentums-, Ablauf- und Überprüfungskontrollen.

Snapshots und Vorlagen liegen zwischen diesen Modellen. Sie können den Start beschleunigen, indem sie eine vorbereitete Umgebung bewahren, aber sie bewahren auch alles, was sich im Snapshot befindet. Überprüfen Sie, ob sie Folgendes enthalten:

• Installierte Pakete und Caches.
• Shell-Verlauf oder Prozesszustand.
• Browser-Cookies, lokalen Speicher und Downloads.
• Temporäre Dateien und generierte Ausgaben.
• Anmeldeinformationen oder Konfigurationsdateien.
• Logs von vorherigen Aufgaben.

Fragen Sie bei Multi-Tenant-Systemen, wie der Scheduler Workloads platziert, ob Caches gemeinsam genutzt werden, wie Festplatten gelöscht werden und wie Host-Level-Ressourcen überwacht werden. Fragen Sie auch, was bei Fehlern passiert. Eine Sandbox, die abstürzt, ein Timeout hat oder ihren Controller verliert, benötigt dennoch Bereinigung und Artefaktbehandlung.

Entwicklerzugriff und Debugging-Pfade

Selbst gehostete Sandboxes benötigen eine praktische Debugging-Geschichte. Wenn ein Agent fehlschlägt, müssen Entwickler wissen, ob das Problem das Modell, der Tool-Aufruf, die Laufzeit, das Image, der Paket-Mirror, der Netzwerkpfad oder die Zielanwendung ist.

Nützliche Debugging-Pfade umfassen:

• Eine Möglichkeit, Befehle vom selben Basis-Image aus wiederzugeben.
• Strukturierte Logs für die Befehlsausführung und Tool-Aufrufe.
• Herunterladbare Artefakte und Screenshots.
• Explizite Timeout- und Ressourcenbegrenzungsfehler.
• Eine kontrollierte Möglichkeit für einen Entwickler, sich mit einer Live-Sitzung zu verbinden, wenn die Richtlinie es erlaubt.
• Versionsverwaltete Vorlagen oder Images, sodass Fehler einer Umgebungsversion zugeordnet werden können.
• Klare Trennung zwischen benutzersichtbarer Ausgabe und internen Laufzeit-Logs.

Seien Sie vorsichtig mit Notzugriff. Breiter Shell-Zugriff auf Live-Sandboxes kann dieselben Isolationsannahmen verletzen, für deren Durchsetzung die Sandbox gebaut wurde. Definieren Sie, wer sich verbinden kann, was sie sehen können, ob Secrets geschwärzt werden und wie der Zugriff protokolliert wird.

Wo die Novita Agent Sandbox passt

Novita Agent Sandbox ist eine verwaltete Agentenlaufzeit für Codeausführung, Browser-Automation, Computer-Use-artige Workflows, Datenanalyse, Evaluierungen und langlebige Agenten-Workflows. Die Novita Agent Sandbox-Dokumentation beschreibt eine zustandsbehaftete Sandbox-Umgebung mit SDK- und CLI-Pfaden für Lebenszyklus, Befehle, Dateien, Browser-Sitzungen und zugehörige Workflow-Primitiven.

Das macht Novita zu einer geeigneten Option zur Evaluierung, wenn Ihr Team eine Agenten-Ausführungsinfrastruktur wünscht, ohne von Anfang an die volle Self-Hosted-Betriebslast zu übernehmen.

Halten Sie die Grenze klar:

• Verwenden Sie Open-Source- oder Self-Hosted-Laufzeiten, wenn die Kontrolle über die Bereitstellung, die Anpassung auf Quellcode-Ebene oder das Eigentum an der internen Infrastruktur Priorität hat.
• Verwenden Sie eine verwaltete Sandbox, wenn schnellere Einführung, vom Anbieter verwaltete Laufzeitoperationen und ein API-First-Workflow wichtiger sind als der Besitz jeder Ebene.
• Evaluieren Sie in beiden Fällen Isolation, Egress, Paketinstallationen, Secrets, Logs, Persistenz und Prüfschritte gegen Ihre eigene Richtlinie.

Behandeln Sie keinen Anbieternamen als Sicherheitsgarantie. Behandeln Sie ihn als eine Laufzeitwahl, die dennoch eine Architekturüberprüfung benötigt.

Self-Hosting-Checkliste

Verwenden Sie diese Checkliste, bevor Sie eine Open-Source-KI-Agenten-Sandbox in die Produktion überführen.

Bereich	Mindestfrage vor der Produktion
Isolation	Ist die Grenze Container, MicroVM, vollständige VM oder etwas anderes, und ist das für die Workload ausreichend?
Workspace	Startet jede Aufgabe von einem bekannten Dateisystemzustand und kann zurückgesetzt werden?
Persistenz	Sind Pause, Fortsetzung, Snapshots und Aufbewahrung explizit und nicht versehentlich?
Netzwerk	Sind Paketabrufe, Surfen, API-Aufrufe, Git, Webhooks und Vorschau-Ingress separat gesteuert?
Pakete	Sind Lockfiles, Repositories, Post-Install-Skripte, native Binärdateien und Caches geregelt?
Secrets	Sind Anmeldeinformationen aufgabenbezogen, geschwärzt, rotiert und für nicht zusammenhängende Befehle nicht verfügbar?
Logs	Kann ein Prüfer Befehle, Ausgaben, Dateiänderungen, Netzwerkpfade und Genehmigungen rekonstruieren?
Multi-Tenancy	Sind Host-Sharing, Cache-Sharing, Festplattenbereinigung, Kontingente und „lauter Nachbar“-Verhalten verstanden?
Debugging	Können Ingenieure Fehler reproduzieren, ohne das Sicherheitsmodell zu umgehen?
Betrieb	Wer patcht Images, Laufzeiten, Kernel, Abhängigkeiten und Sandbox-Controller?
Missbrauchskontrollen	Werden Timeouts, Ressourcengrenzen, Ratenbegrenzungen und Kill-Pfade durchgesetzt?
Exit-Pfad	Können Artefakte exportiert und überprüft werden, selbst wenn die Sandbox abstürzt oder ein Timeout hat?

Wenn mehrere Antworten unklar sind, behalten Sie das Projekt in einer Prototyp-Phase. Eine Sandbox, die ihre Grenzen nicht erklären kann, ist nicht bereit, nicht vertrauenswürdige Agentenarbeit in großem Maßstab auszuführen.

FAQ

Was ist die beste Open-Source-KI-Agenten-Sandbox?

Es gibt keine einzelne beste Open-Source-KI-Agenten-Sandbox für jedes Team. Die richtige Wahl hängt von Ihren Isolationsanforderungen, Ihrem Bereitstellungsmodell, Ihrer Agenten-Workload, Ihrer Egress-Richtlinie, Ihren Persistenzanforderungen und Ihrer Betriebskapazität ab. Vergleichen Sie Optionen, indem Sie Ihre eigene Aufgabe in jeder Kandidatenlaufzeit ausführen.

Ist Docker für eine KI-Agenten-Sandbox ausreichend?

Docker kann für vertrauenswürdige interne Automatisierung, lokale Entwicklung und CI-ähnliche Jobs ausreichend sein, aber möglicherweise nicht für nicht vertrauenswürdigen Code oder strenge Multi-Tenant-Workloads. Überprüfen Sie Kernel-Sharing, Berechtigungen, eingehängte Volumes, Netzwerkzugriff, Secrets und die Reaktion auf Ausbrüche, bevor Sie sich allein auf Container verlassen.

Sind MicroVMs sicherer als Container für Agenten-Workloads?

MicroVMs können eine stärkere Isolationsgrenze bieten, da jede Sandbox mit einem separaten Kernel ausgeführt werden kann. Das löst nicht automatisch Probleme mit Egress, Paketen, Secrets, Protokollierung, Patchen oder Multi-Tenant-Betrieb. Behandeln Sie MicroVMs als einen Teil der Architektur, nicht als das gesamte Sicherheitsmodell.

Was sollte ich testen, bevor ich eine Agenten-Sandbox self-host?

Testen Sie eine reale Workload, die Dateien klont oder einhängt, Abhängigkeiten installiert, Befehle ausführt, Secrets behandelt, genehmigte Netzwerkziele erreicht, Artefakte erzeugt, ein Timeout hat und zurückgesetzt wird. Testen Sie auch Fehlerpfade: fehlgeschlagene Paketinstallation, Browser-Absturz, Netzwerkverweigerung, Ressourcengrenze und Sandbox-Bereinigung nach einem Controller-Fehler.

Wann sollte ich eine verwaltete Sandbox anstelle von Self-Hosting verwenden?

Verwenden Sie eine verwaltete Sandbox, wenn Ihr Team die Agenten-Ausführungs-API und Prüfartefakte wünscht, ohne selbst für Laufzeit-Patching, Skalierung, Kapazitätsplanung und Infrastrukturbetrieb zuständig zu sein. Self-Hosten Sie, wenn die Kontrolle über die Bereitstellung oder die Anpassung auf Quellcode-Ebene wichtig genug ist, um diese Arbeit zu rechtfertigen.

Empfohlene Artikel

• Run Codex or a Coding Agent in a Secure Sandbox
• How Agent Sandboxes Power Secure, Scalable AI Innovation
• Building a Coding Agent with Novita’s Agent Sandbox