Coding Agent Sandbox: So führen Sie agentengenerierten Code sicher aus

Eine Coding-Agent-Sandbox ermöglicht es, dass agentengenerierte Befehle und Codeänderungen in einem abgegrenzten Arbeitsbereich ausgeführt werden, in dem Dateien, Prozesse, Netzwerkzugriff, Secrets, Logs und Überprüfungsartefakte kontrolliert werden können. Das praktische Ziel ist nicht, so zu tun, als ob beliebiger generierter Code harmlos wäre. Das Ziel ist es, den Agenten wie einen nicht vertrauenswürdigen Mitwirkenden zu behandeln, der einen einmaligen Entwicklungsrechner, klare Grenzen, beobachtbare Ausführung und einen menschlichen Prüfpfad hat, bevor etwas in die Produktion gelangt.

Was eine Coding-Agent-Sandbox isolieren muss

Ein Coding-Agent wird nützlich, wenn er ein Repository inspizieren, Dateien bearbeiten, Tests ausführen, Abhängigkeiten installieren und einen Patch zurückgeben kann. Genau diese Aktionen machen die Umgebung jedoch riskant. Eine per Prompt-Injection veranlasste Abhängigkeitsinstallation, ein destruktiver Shell-Befehl oder ein versehentlich offengelegtes Secret können mehr Schaden anrichten als eine schlechte Textantwort.

Entwerfen Sie die Sandbox anhand der Ressourcen, die ein Coding-Agent berühren kann:

Oberfläche	Was zu kontrollieren ist	Warum es wichtig ist
Repository-Checkout	Branch, Commit SHA, Schreibumfang, Submodule, generierte Dateien	Verhindert, dass der Agent den falschen Codebestand ändert oder Änderungen außerhalb des Prüfpfads versteckt.
Dateisystem	Arbeitsbereichsroot, gemountete Dateien, ignorierte Pfade, Ausgabeverzeichnisse	Verhindert breiten Zugriff auf Host-Dateien, Anmeldeinformationen, Caches und nicht zusammenhängende Projekte.
Shell-Ausführung	Erlaubte Befehle, Arbeitsverzeichnis, Timeout, Ausgabeerfassung, Freigabegates	Gibt dem Agenten genug Leistung zum Bauen und Testen, während risikoreiche Aktionen eingeschränkt werden.
Paketinstallationen	Registry-Richtlinie, Lockfiles, fixierte Versionen, Cache-Strategie, Installationslogs	Reduziert Lieferketten-Unklarheiten, wenn der Agent nach neuen Abhängigkeiten fragt.
Netzwerkzugriff	Standard-Ausgang, Whitelists, DNS-Verhalten, API-Ziele, Paket-Mirrors	Hilft, unbeabsichtigte Datenbewegungen zu verhindern und externe Aufrufe überprüfbar zu machen.
Secrets	Bereichsbezogene Anmeldeinformationen, kurzlebige Token, Schwärzung, keine Standard-Produktionsschlüssel	Verhindert, dass der Agent Anmeldeinformationen liest oder preisgibt, die er nicht benötigt.
Artefakte	Testergebnisse, Build-Ausgaben, Screenshots, generierte Dateien, Logs	Gibt Prüfern Beweise, ohne sich nur auf die Zusammenfassung des Agenten zu verlassen.
Lebenszyklus	Pause, Fortsetzen, Snapshot, Zurücksetzen, Bereinigung, Aufbewahrungsrichtlinie	Macht Agentenläufe wiederholbar und einmalig statt langlebiger undurchschaubarer Maschinen.

Verwenden Sie diese Tabelle als Design-Checkliste. Sie gilt unabhängig davon, ob Ihre Sandbox auf Containern, virtuellen Maschinen, MicroVMs, verwalteten Cloud-Sandboxen oder einem internen Runner basiert. Die genaue Isolationsschicht ist wichtig, aber die operativen Kontrollen um die Schicht herum sind es auch.

Referenz-Workflow zum Ausführen von agentengeneriertem Code

Der sicherste Coding-Agent-Workflow ähnelt weniger einem Chatbot und mehr einem kontrollierten Pull-Request-Pipeline.

1. Erstellen Sie einen neuen Arbeitsbereich für die Aufgabe.
2. Checken Sie das Ziel-Repository auf einem bestimmten Branch oder Commit aus.
3. Geben Sie dem Agenten eine enge Aufgabe, einen Testbefehl und einen Dateiumfang vor.
4. Lassen Sie den Agenten Dateien inspizieren und einen Plan vorschlagen.
5. Führen Sie risikoarme, schreibgeschützte Befehle automatisch aus.
6. Verlangen Sie eine Freigabe oder Richtlinienprüfungen für riskante Befehle.
7. Erfassen Sie jeden Befehl, Exit-Code, stdout, stderr, Dateischreibvorgang und generiertes Artefakt.
8. Führen Sie Tests, Typprüfungen, Linter, Builds oder gezielte Skripte innerhalb der Sandbox aus.
9. Exportieren Sie einen Patch, Diff, Testausgabe und Artefakt-Bundle.
10. Setzen Sie den Arbeitsbereich nach der Überprüfung zurück oder zerstören Sie ihn, es sei denn, ein Snapshot wird absichtlich gespeichert.

Das wichtige Detail ist, dass die Sandbox nicht nur ein Ort zur Codeausführung ist. Sie ist auch der Beweisrekorder. Ein Prüfer sollte beantworten können: Welches Repository wurde ausgecheckt, was wurde geändert, welche Befehle wurden ausgeführt, was ist fehlgeschlagen, was war erfolgreich, welche Dateien wurden erstellt und welche externen Ressourcen wurden kontaktiert.

Für einfache Agenten kann dies als eine Warteschlange von Aktionen mit Richtlinienprüfungen um jede Aktion implementiert werden. Für leistungsfähigere Agenten behalten Sie die gleichen Grenzen bei, machen Sie die Steuerungsebene jedoch expliziter: Eine Komponente entscheidet, was der Agent anfordern darf, eine Komponente führt genehmigte Aktionen aus, und eine Komponente zeichnet den Lauf auf.

Benutzeraufgabe
  -> Agent schlägt Dateilesevorgänge, Bearbeitungen und Befehle vor
  -> Richtlinienebene klassifiziert jede Aktion
  -> Sandbox führt genehmigte Aktionen aus
  -> Logs, Diffs und Artefakte werden erfasst
  -> Mensch prüft Patch vor Merge oder Deployment

Diese Trennung verhindert, dass das Modell sowohl der Planer als auch die endgültige Autorität über gefährliche Operationen ist.

Sicherheitscheckpoints vor der Befehlsausführung

Gehen Sie von der Annahme aus, dass generierte Befehle falsch, zu weitreichend oder durch Repository-Inhalte beeinflusst sein können. Ein Coding-Agent könnte eine bösartige Anweisung aus einer Test-Fixture, README, Issue-Beschreibung, Paketskript oder Webseite lesen. Die Sandbox sollte diese Fehler sichtbar und eingedämmt machen.

Definieren Sie vor der Shell-Ausführung Befehlsklassen:

Befehlsklasse	Beispiele	Standardrichtlinie
Schreibgeschützte Inspektion	pwd, ls, git status, rg, cat package.json	Normalerweise erlauben und protokollieren.
Lokale Verifikation	npm test, pytest, go test, cargo test	Erlauben mit Timeout und Ausgabeerfassung.
Build oder Generierung	npm run build, Codegenerierung, Dokumentationsgenerierung	Erlauben, wenn Ausgabepfade erwartet werden.
Abhängigkeitsänderungen	Paketmanager-Installation, Lockfile-Update	Richtlinienprüfungen oder Freigabe erforderlich.
Netzwerkbefehle	Abrufen von URLs, Aufrufen von APIs, Klonen zusätzlicher Repos	Zielrichtlinie und Protokollierung erforderlich.
Destruktive Befehle	Löschen, Force-Reset, Datenträgerbereinigung, breites chmod/chown	Blockieren oder explizite menschliche Freigabe erforderlich.
Secret-Zugriff	Lesen von Env-Dateien, Credential-Stores, Deployment-Konfigurationen	Blockieren, es sei denn, aufgabenspezifisch und abgegrenzt.

Dies erfordert keinen perfekten statischen Analyzer. Selbst einfache Kontrollen helfen: Arbeitsverzeichnisbeschränkungen, explizite Verweismuster, Befehlstimeouts, Ausgabegrößenlimits und eine Freigabeaufforderung für Befehle, die Abhängigkeiten mutieren, Anmeldeinformationen berühren oder externe Hosts kontaktieren.

Dateisystemgrenzen sollten ebenso konkret sein. Mounten Sie nur das Repository und die temporären Verzeichnisse, die der Agent benötigt. Vermeiden Sie es, das Home-Verzeichnis des Bedieners, SSH-Schlüssel, Cloud-Konfigurationen, Paketmanager-Anmeldeinformationen, Browserprofile oder Produktionsumgebungsdateien zu mounten. Wenn Caches aus Geschwindigkeitsgründen benötigt werden, bevorzugen Sie schreibgeschützte oder aufgabenspezifische Caches mit klarer Aufbewahrung.

Wie man Paketinstallationen und Netzwerkzugriff handhabt

Die Paketinstallation ist einer der schwierigsten Teile der Coding-Agent-Sandboxing, da sie sowohl nützlich als auch riskant ist. Agenten müssen Builds reproduzieren und Tests ausführen, aber Installationsskripte können Code ausführen, transitive Abhängigkeiten nachziehen und externe Infrastruktur kontaktieren.

Verwenden Sie eine strengere Richtlinie für Paketarbeit:

• Bevorzugen Sie lockfile-basierte Installationen gegenüber freier Abhängigkeitsauflösung.
• Protokollieren Sie Paketmanager-Befehl, Registry-URL, Paketnamen, Versionen und Lockfile-Änderungen.
• Leiten Sie Abhängigkeitsdownloads nach Möglichkeit über genehmigte Registries oder Mirrors.
• Behandeln Sie neue Abhängigkeitshinzufügungen als Codeänderungen, die eine Überprüfung erfordern.
• Blockieren Sie Installationsskripte für risikoreiche Workflows, es sei denn, das Projekt benötigt sie explizit.
• Halten Sie Abhängigkeits-Caches getrennt von Secrets und nicht zusammenhängenden Repositories.

Netzwerk-Ausgang verdient die gleiche Behandlung. Ein Coding-Agent benötigt möglicherweise Internetzugriff für Paketregistries, API-Dokumentationen, Browser-Checks oder Integrationstests. Das bedeutet nicht, dass er uneingeschränkten ausgehenden Zugriff benötigt.

Definieren Sie mindestens die Standardeinstellung:

Netzwerkfrage	Sicherere Standardeinstellung
Kann die Sandbox das Internet erreichen?	Nein, es sei denn, die Aufgabe erfordert es.
Kann sie beliebige DNS-Namen auflösen?	DNS und Zielhosts einschränken oder protokollieren.
Kann sie Produktions-APIs aufrufen?	Standardmäßig Staging-Endpunkte oder Mock-Dienste verwenden.
Kann sie Paketabhängigkeiten abrufen?	Genehmigte Registries, Mirrors und Lockfiles verwenden.
Kann sie Dateien oder Logs hochladen?	Blockieren, es sei denn, das Ziel ist erwartet und überprüft.

Beschreiben Sie diese Kontrollen nicht als Garantie dafür, dass Exfiltration oder Kompromittierung von Abhängigkeiten nicht stattfinden kann. Die realistische Behauptung ist enger gefasst: Richtlinie, Isolation, Protokollierung und Überprüfung reduzieren die Schadensauswirkung und machen riskantes Verhalten leichter erkennbar, bevor der Patch vertrauenswürdig ist.

Diffs, Artefakte und Logs zur menschlichen Überprüfung

Die menschliche Überprüfung ist am effektivsten, wenn die Sandbox ein kompaktes Überprüfungspaket produziert, nicht ein langes Chat-Protokoll.

Erfassen Sie für jeden Lauf:

• Die Repository-URL, den Branch und den Commit-SHA, die für den Checkout verwendet wurden.
• Die Aufgabenaufforderung oder Problemzusammenfassung.
• Gelesene und geschriebene Dateien.
• Jeden Befehl, das Arbeitsverzeichnis, Startzeit, Endzeit, Exit-Code, stdout und stderr.
• Paketinstallationsbefehle und Lockfile-Änderungen.
• Testergebnisse, Lint-, Typprüfungs- und Build-Ergebnisse.
• Generierte Artefakte wie Screenshots, Berichte, Coverage, Binärdateien oder Vorschau-URLs.
• Endgültigen Diff in einem Standard-Patch- oder Pull-Request-Format.

Der Prüfer sollte zuerst den Diff inspizieren, dann Logs und Artefakte verwenden, um gezielte Fragen zu beantworten. Wurden die Tests wirklich ausgeführt? Hat der Agent Dateien außerhalb des angeforderten Umfangs geändert? Hat er eine Abhängigkeit hinzugefügt? Hat er generierte Dateien überschrieben? Hat er einen Netzwerkdienst aufgerufen? Hat er große oder sensible Artefakte hinterlassen?

Für Produktionsteams machen Sie das Überprüfungs-Gate explizit:

• Der Agent kann einen Patch vorschlagen.
• Die Sandbox kann die Verifikation ausführen.
• Das System kann einen Pull-Request öffnen.
• Ein Mensch oder eine genehmigte Richtlinie muss entscheiden, ob gemerged, deployed oder breitere Berechtigungen erteilt werden.

Diese Grenze ist besonders wichtig für Repositories, die Infrastruktur, Abrechnung, Authentifizierung, Deployment oder Kundendatenpfade enthalten.

Wo Novita Agent Sandbox passt

Novita Agent Sandbox ist für isolierte, zustandsbehaftete Ausführungsumgebungen konzipiert, in denen Agenten Code ausführen, Abhängigkeiten installieren, auf Dateien zugreifen, Browser-Workflows verwenden und den Ausführungszustand über Sitzungen hinweg bewahren können. Die Agent Sandbox Übersicht beschreibt drei Kernbausteine: Sandboxen für isolierte Aufgabenausführung, Vorlagen für vorbereitete Umgebungen und Snapshots zur Wiederverwendung konfigurierter Zustände.

Für Coding-Agent-Workflows lassen sich diese Grundelemente natürlich auf einen kontrollierten Entwicklungsarbeitsbereich abbilden:

Coding-Agent-Anforderung	Sandbox-Muster
Von einer bekannten Umgebung aus starten	Eine Vorlage mit der erwarteten Laufzeit und den Werkzeugen verwenden.
Befehle und Tests fernab des Hosts ausführen	Innerhalb eines sandbox-spezifischen Dateisystems und einer Laufzeitumgebung ausführen.
Einen vorbereiteten Setup wiederverwenden	Einen Snapshot speichern, nachdem genehmigte Abhängigkeiten oder Projektwerkzeuge installiert wurden.
Langlaufende Agentenarbeit debuggen	Zustand über Sitzungen hinweg bewahren, wenn der Workflow Kontinuität benötigt.
Nach der Überprüfung bereinigen	Sandbox zurücksetzen, stoppen oder verwerfen gemäß Ihrer Aufbewahrungsrichtlinie.

Halten Sie Produktnutzung und Sicherheitsrichtlinie getrennt. Novita Agent Sandbox kann die isolierte Ausführungsumgebung für Code-ausführende Agenten bereitstellen, aber Ihre Anwendung muss dennoch Repository-Zugriff, Befehlspolitik, Secret-Bereich, Netzwerkregeln, Artefaktaufbewahrung und menschliche Freigabegates definieren. Diese Entscheidungen hängen von Ihrem Bedrohungsmodell ab und sollten vor dem öffentlichen Produktionseinsatz von Ihren Engineering- und Sicherheitsverantwortlichen überprüft werden.

Entwickler, die ein praktisches Beispiel wünschen, können auch die Novita-Anleitung zum Erstellen eines Remote Code Execution MCP-Servers mit Novita Sandbox lesen. Für die Produktdokumentation beginnen Sie mit der Novita Agent Sandbox Dokumentation und der SDK- und CLI-Installationsanleitung.

FAQ

Ist eine Coding-Agent-Sandbox ausreichend, um generierten Code sicher zu machen?

Nein. Eine Sandbox ist eine Kontrollebene. Sie benötigen weiterhin abgegrenzten Repository-Zugriff, Befehlspolitik, Abhängigkeitskontrollen, Netzwerkbeschränkungen, Secret-Handling, Logs, Artefaktüberprüfung und menschliche Freigabe vor Merge oder Deployment.

Sollten Coding-Agenten Internetzugriff haben?

Nur wenn die Aufgabe es erfordert. Viele Code-Review-, Refactoring- und Test-Workflows können ohne allgemeinen Internetzugriff ausgeführt werden, nachdem Abhängigkeiten vorbereitet wurden. Wenn Internetzugriff erforderlich ist, protokollieren Sie die Ziele und bevorzugen Sie erlaubte Paketregistries, Dokumentationsseiten, Staging-APIs oder Mocks.

Sollten Agenten Produktions-Secrets erhalten?

Vermeiden Sie es, Coding-Agenten standardmäßig Produktions-Secrets zu geben. Verwenden Sie abgegrenzte, kurzlebige Anmeldeinformationen für die spezifische Aufgabe, bevorzugen Sie Staging-Dienste, schwärzen Sie Logs und halten Sie Secret-Zugriff aus dem Repository-Arbeitsbereich heraus, es sei denn, es gibt einen überprüften Grund.

Was sollte überprüft werden, bevor ein Agenten-Patch vertrauenswürdig ist?

Überprüfen Sie den Diff, geänderte Abhängigkeiten, generierte Dateien, das Befehlslog, Testergebnisse, Netzwerkaktivität und alle Artefakte. Achten Sie besonders auf Änderungen bei Authentifizierung, Autorisierung, Deployment, Abrechnung, Infrastruktur, Datenzugriff und Paketverwaltung.

Wann sollte eine Sandbox zurückgesetzt werden?

Setzen Sie den Arbeitsbereich nach jeder Aufgabe zurück oder zerstören Sie ihn, es sei denn, Sie speichern absichtlich einen Snapshot. Ein persistenter Zustand ist für langlaufende Workflows nützlich, sollte aber eine bewusste Entscheidung mit Eigentums-, Aufbewahrungs- und Bereinigungsregeln sein.

Empfohlene Artikel

• Erstellen eines Remote Code Execution MCP-Servers mit Novita Sandbox und der mcp-use-Bibliothek
• Erstellen eines Coding-Agents mit Novitas Agent Sandbox
• Novita Agent Runtime: AgentCore-kompatible KI-Agenten-Infrastruktur