Claude Code oder Managed Agents in einer isolierten Sandbox ausführen

Führen Sie Claude Code-ähnliche oder verwaltete Codierungs-Agenten in einer Sandbox aus, indem Sie jedem Agenten einen abgegrenzten Arbeitsbereich, explizite Dateiberechtigungen, kontrollierte Shell-Ausführung, eine Netzwerk- und Paketrichtlinie, klare Geheimnisgrenzen, dauerhafte Protokolle, erfasste Artefakte und eine menschliche Überprüfung zuweisen, bevor Änderungen zusammengeführt oder ausgeliefert werden. Der Agent kann weiterhin Code lesen, Dateien bearbeiten, Abhängigkeiten installieren, Tests ausführen und einen Patch erstellen, aber die Umgebung um ihn herum bestimmt, was er berühren, was er abrufen, welche Anmeldeinformationen er sehen und wann eine Person den nächsten Schritt genehmigen muss.

Was isoliert werden muss

Ein Codierungs-Agent ist nicht nur ein Chatbot, der an ein Repository angeschlossen ist. Sobald er Dateien bearbeiten und Befehle ausführen kann, beginnt er, sich wie ein Junior-Build-Worker mit Sprachmodell-Reasoning in der Schleife zu verhalten. Dieser Worker könnte npm test ausführen, generierte Dateien inspizieren, einen Dev-Server starten oder eine Paketinstallation versuchen, weil eine Fehlermeldung dies nahelegt. Wenn der Arbeitsbereich Ihr Laptop, ein gemeinsamer CI-Runner oder eine langlebige produktionsähnliche VM ist, ist der Schadensradius zu groß.

Das Isolationsziel ist die gesamte Agenten-Arbeitsschleife:

• Der Repository-Checkout und der Branch, den der Agent lesen oder ändern kann.
• Die Dateisystempfade, in die der Agent schreiben kann.
• Die Befehle, die er automatisch ausführen kann.
• Die Befehle, die eine Genehmigung erfordern.
• Die Paketregistrierungen, Domains und APIs, die er erreichen kann.
• Die Anmeldeinformationen, die der Sitzung zur Verfügung stehen.
• Die Protokolle, Diffs, Testausgaben, Screenshots und Artefakte, die für die Überprüfung aufbewahrt werden.
• Das Bereinigungsverhalten nach Erfolg, Fehlschlag oder Zeitüberschreitung.

Claude Code und andere verwaltete Codierungs-Agent-Produkte können eigene Berechtigungssysteme enthalten. Die Claude Code-Dokumentation von Anthropic beschreibt beispielsweise Berechtigungseinstellungen für erlaubte und verbotene Tools, Genehmigungsverhalten und Sandboxing-Richtlinien für die lokale Nutzung. Betrachten Sie diese Kontrollen als eine Schicht, nicht als die gesamte Grenze. Ein stärkeres Design platziert den Agenten zusätzlich in einer isolierten Laufzeitumgebung und wendet dann Tool-Berechtigungen innerhalb dieser Laufzeitumgebung an.

Referenzarchitektur

Ein praktischer Sandbox-Agent-Workflow hat vier Schichten:

Schicht	Zweck	Typische Kontrolle
Agent Controller	Entscheidet über den Aufgabenplan und Tool-Aufrufe	Modell-/Tool-Berechtigungen, Genehmigungsmodus, Aufgaben-Prompt
Sandbox-Laufzeit	Hostet den Arbeitsbereich, in dem Befehle ausgeführt werden	Isoliertes Dateisystem, Prozesslimits, Lebenszyklussteuerung
Richtlinien-Gateway	Entscheidet, welche Aktionen erlaubt sind	Befehlsregeln, Netzwerk-Ausgangsregeln, Paketrichtlinie, Geheimnisumfang
Überprüfungsoberfläche	Lässt Menschen Ergebnisse inspizieren	Diff, Protokolle, Testergebnisse, Artefakte, Pull Request

Halten Sie diese Schichten getrennt. Wenn der Agent Controller durch Prompt-Injection kompromittiert wird, sollten die Sandbox-Laufzeit und das Richtlinien-Gateway dennoch begrenzen, was passiert. Wenn eine Paketinstallation unerwarteten Code zieht, sollten das Netzwerk und die Artefaktprotokolle dies sichtbar machen. Wenn der Agent einen plausiblen Patch erstellt, sollte die Überprüfungsoberfläche dennoch genau zeigen, was geändert wurde und welche Tests gelaufen sind.

Ein konzeptionelles Richtlinienobjekt könnte so aussehen:

workspace:
  mode: ephemeral
  repo_ref: pull-request-branch
  writable_paths:
    - /workspace/project
  readonly_paths:
    - /workspace/reference
commands:
  auto_allow:
    - git status
    - npm test
    - npm run lint
    - pytest
  require_approval:
    - npm install
    - pip install
    - docker build
    - git push
  deny:
    - rm -rf /
    - curl ... | sh
network:
  default: deny
  allow:
    - registry.npmjs.org
    - pypi.org
    - files.pythonhosted.org
secrets:
  expose:
    - READ_ONLY_PACKAGE_TOKEN
  deny:
    - PRODUCTION_DATABASE_URL
    - CLOUD_ADMIN_TOKEN
artifacts:
  capture:
    - git diff
    - test-results/
    - screenshots/
    - command-log.jsonl

Dies ist bewusst kein SDK-Beispiel. Das genaue Richtlinienformat hängt von Ihrem Agent-Framework und Sandbox-Anbieter ab. Wichtig ist, dass Berechtigungen außerhalb des freiformigen Reasonings des Modells ausgedrückt und dann von der Laufzeit oder der Orchestrierungsschicht durchgesetzt werden.

Arbeitsbereich und Repository-Setup

Starten Sie jeden Agentenlauf aus einem sauberen Arbeitsbereich. Ein verwalteter Agent sollte nicht die Shell-Historie, den SSH-Agent, die Dotfiles, das Cloud-CLI-Login oder unverfolgte lokale Dateien eines Entwicklers erben, es sei denn, es gibt einen bewussten Grund.

Für Repository-Arbeiten verwenden Sie einen dedizierten Checkout:

• Klonen oder mounten Sie nur das Repository, das für die Aufgabe benötigt wird.
• Checken Sie einen neuen Aufgaben-Branch aus, anstatt den Standard-Branch zu bearbeiten.
• Fixieren Sie den Basis-Commit, damit die Überprüfung den Ausgangspunkt reproduzieren kann.
• Halten Sie Abhängigkeits-Caches von beschreibbaren Quellpfaden getrennt.
• Speichern Sie generierte Artefakte außerhalb des Quellbaums, es sei denn, sie sind Teil des beabsichtigten Diffs.

Branch-Isolation ist wichtig, weil Codierungs-Agenten oft mehrere Ansätze ausprobieren, bevor sie sich für einen entscheiden. Ein sauberer Aufgaben-Branch gibt Prüfern einen normalen Pull-Request-Diff, anstatt einen gemischten Arbeitsbereich mit temporären Experimenten. Wenn der Agent eine Referenzimplementierung vergleichen muss, mounten Sie diese Referenz schreibgeschützt.

Für langlebige verwaltete Agenten entscheiden Sie, ob die Sandbox ephemeral, pausiert oder gesnapshotet wird. Ephemere Arbeitsbereiche sind einfacher zu handhaben. Snapshots und Pause/Fortsetzen sind nützlich für lange Jobs, Browsersitzungen und teure Einrichtungsschritte, sollten aber dennoch eine klare Prüfspur bewahren: wann der Snapshot erstellt wurde, welche Dateien vorhanden waren und welche Anmeldeinformationen verfügbar waren.

Dateisystemberechtigungen

Der Dateisystemumfang sollte enger sein als „der Agent kann die gesamte Maschine lesen". Die meisten Codierungsaufgaben benötigen:

• Lese-/Schreibzugriff auf den Repository-Arbeitsbereich.
• Schreibgeschützten Zugriff auf ausgewählten Aufgabenkontext, Fixtures oder Dokumentation.
• Ein temporäres Verzeichnis für Build-Ausgaben und temporäre Dateien.
• Keinen Zugriff auf Host-Home-Verzeichnisse, nicht verwandte Repositories, Cloud-Anmeldeinformationen, Browserprofile oder Produktionsdaten-Dumps.

Schreibberechtigungen verdienen besondere Aufmerksamkeit. Ein Codierungs-Agent, der ein Repository bearbeiten kann, kann auch Skripte, Tests, Lockfiles, CI-Konfiguration und Bereitstellungsdateien bearbeiten. Das kann genau das sein, was die Aufgabe erfordert, aber es sollte in der Überprüfung sichtbar sein. Für sensible Pfade, wie .github/workflows/, Bereitstellungsmanifeste oder Paketveröffentlichungskonfiguration, erfordern Sie entweder einen stärkeren Genehmigungsschritt oder eine vom Menschen durchgeführte endgültige Überprüfung.

Verwenden Sie Datei-Allowlists, wenn die Aufgabe eng ist. Beispielsweise benötigt ein Dokumentations-Agent möglicherweise nur docs/ und ein generiertes Vorschauverzeichnis. Ein Abhängigkeitsaktualisierungs-Agent benötigt möglicherweise package.json, Lockfiles und Test-Snapshots. Eine umfassende Refaktorisierung benötigt breiteren Zugriff, aber die Überprüfung sollte dann einen größeren Diff und vollständigere Tests erwarten.

Shell-Ausführungsrichtlinie

Shell-Zugriff ist der Punkt, an dem Codierungs-Agenten nützlich und riskant werden. Sie benötigen Befehlsausführung, um Tests auszuführen, Code zu formatieren, Build-Fehler zu inspizieren und Korrekturen zu überprüfen. Sie benötigen keine uneingeschränkte Autorität, um jeden Befehl ohne Pause auszuführen.

Eine gute Shell-Richtlinie hat drei Kategorien:

Kategorie	Beispiele	Warum es wichtig ist
Automatisch erlaubt	git status, npm test, pytest, go test ./..., npm run lint	Hält normale Edit-Test-Schleifen schnell
Genehmigung erforderlich	Paketinstallationen, Migrationen, langlaufende Dienste, externe CLIs, git push	Fügt Reibung hinzu, wo sich Zustand, Kosten oder Netzwerkrisiko ändern
Verboten	Destruktive Host-Befehle, Credential-Dumping, unsicheres Shell-Piping, Schreiben außerhalb des Arbeitsbereichs	Blockiert Aktionen, die nicht delegiert werden sollten

Verlassen Sie sich nicht nur auf die Textübereinstimmung von Befehlen. Agenten können Befehle über Skripte, Paketmanager-Hooks oder verschachtelte Shells ausführen. Für risikoreichere Umgebungen kombinieren Sie die Befehlsrichtlinie mit Dateisystemgrenzen auf Runtime-Ebene, Ressourcenlimits und Netzwerkkontrollen.

Langlaufende Befehle benötigen ein Timeout-Verhalten. Ein Testserver, eine Browserautomatisierung oder ein Build-Watcher können am Leben bleiben, nachdem der Agent weitergezogen ist. Erfassen Sie Prozess-IDs, stdout, stderr, Exit-Status, Laufzeit und Beendigungsgrund. Wenn ein Befehl einen Vorschauport öffnet, zeichnen Sie das Port-Mapping auf und schließen Sie es während der Bereinigung.

Paketinstallationen und Netzwerk-Ausgang

Die Paketinstallation ist eine der nützlichsten Funktionen eines Agenten-Arbeitsbereichs und eine der einfachsten Stellen, an denen Risiken eindringen können. Ein Codierungs-Agent kann ein Paket installieren, weil ein Stack Overflow-Antwort, eine README oder ein modellgenerierter Plan dies vorgeschlagen hat. Das kann den Abhängigkeitsgraphen ändern, Installationsskripte ausführen und externe Registrierungen erreichen.

Für Implementierungsleitfäden und Produktions-Workflows beginnen Sie mit einer Standard-Verweigerungshaltung für das Netzwerk und erlauben Sie dann, was die Aufgabe benötigt:

• Paketregistrierungen wie npm oder PyPI, vorzugsweise über einen Registrierungs-Mirror oder Cache.
• Quell-Hosts, die für das Repository und die Submodule benötigt werden.
• Dokumentationsdomains, die für die Aufgabe benötigt werden.
• Interne APIs nur, wenn die Sandbox die richtige Datenklassifizierung hat.

Vermeiden Sie es, jedem Agenten standardmäßig breiten ausgehenden Internetzugang zu geben. Wenn für Forschung oder Browserautomatisierung breiter Zugriff erforderlich ist, trennen Sie diesen Lauf von Code-ändernden Läufen und kennzeichnen Sie das Artefakt entsprechend.

Für Paketinstallationen erfassen Sie:

• Den Paketmanager-Befehl.
• Den Registrierungs-Host.
• Lockfile-Änderungen.
• Heruntergeladene Paketnamen und -versionen, wenn verfügbar.
• Alle Installationsskripte, die ausgeführt wurden.
• Ob ein Mensch die Installation genehmigt hat.

Das macht beliebige Pakete nicht sicher. Es macht die Änderung überprüfbar.

Geheimnisgrenzen

Geheimnisse sollten auf die Aufgabe beschränkt, kurzlebig und standardmäßig nicht vorhanden sein. Die sicherste Sandbox ist nicht eine, die verspricht, dass ein Modell niemals ein Geheimnis preisgibt; es ist eine, in der das Geheimnis nicht vorhanden ist, es sei denn, die Aufgabe erfordert es wirklich.

Verwenden Sie diese Standardeinstellungen:

• Keine Produktionsdatenbank-Anmeldeinformationen in Agenten-Arbeitsbereichen.
• Keine Cloud-Admin-Tokens.
• Keine persönlichen SSH-Schlüssel oder Entwickler-Maschinen-Anmeldeinformationen.
• Schreibgeschützte Anmeldeinformationen, wo möglich.
• Separate Tokens für Paketlesevorgänge, Test-Fixtures oder reine Staging-APIs.
• Schwärzung in Protokollen, bevor Artefakte geteilt werden.

Wenn der Agent einen externen Dienst aufrufen muss, stellen Sie ein schmales Token bereit und zeichnen Sie auf, welches Tool oder welcher Befehl es verwendet hat. Vermeiden Sie es, breite Anmeldeinformationen in Dateien zu platzieren, die der Agent bearbeiten kann. Umgebungsvariablen sind praktisch, aber sie können dennoch von Befehlen ausgegeben, in Protokolle aufgenommen oder in generierte Dateien kopiert werden. Behandeln Sie sie als dem Agentenprozess ausgesetzt.

Protokolle, Artefakte und Prüfpfade

Die menschliche Überprüfung ist nur nützlich, wenn Prüfer sehen können, was passiert ist. Ein Sandbox-Codierungs-Agenten-Lauf sollte mehr als nur den endgültigen Patch bewahren.

Erfassen Sie mindestens:

• Die Aufgaben-Prompt oder Aufgabenbeschreibung.
• Den Basis-Commit und Branch.
• Gelesene und geschriebene Dateien, wenn Ihre Tooling dies aufzeichnen kann.
• Ausgeführte Befehle mit Zeitstempeln, Arbeitsverzeichnis, Exit-Status, stdout und stderr.
• Zusammenfassungen der Paketinstallation und des Netzwerkzugriffs.
• Test- und Build-Ergebnisse.
• Generierte Dateien, Screenshots, Berichte oder Vorschau-Links.
• Den endgültigen Diff.

Speichern Sie Protokolle in einer Überprüfungsoberfläche, die die Sandbox überdauert. Wenn die Sandbox sofort nach dem Lauf zerstört wird, sollten die Beweise dennoch im Pull Request, CI-Artefakt-Speicher oder der Agentenplattform-Aufzeichnung verfügbar sein.

Für Teams, die verwaltete Agenten verwenden, hilft dieser Prüfpfad auch beim Vergleich der Agentenleistung. Sie können sehen, ob Fehler auf fehlende Abhängigkeiten, einen verbotenen Befehl, einen unklaren Prompt, flaky Tests oder ein echtes Code-Problem zurückzuführen sind.

Bereinigung und Zurücksetzen

Die Sandbox-Bereinigung dient der Sicherheit und Kostenkontrolle, nicht nur der Haushaltsführung. Am Ende eines Laufs:

• Stoppen Sie Hintergrundprozesse.
• Schließen Sie offene Ports.
• Widerrufen Sie aufgabenbezogene Tokens.
• Exportieren Sie erforderliche Artefakte.
• Löschen Sie temporäre Dateien, die nicht Teil der Überprüfung sind.
• Zerstören, pausieren oder snapshoten Sie die Sandbox gemäß dem Lauftyp.

Das ephemere Zurücksetzen ist die sauberste Standardeinstellung für nicht vertrauenswürdige oder explorative Arbeiten. Für langlebige Agenten erstellen Sie Snapshots nur nach einem bekannten guten Einrichtungsschritt, nicht nach willkürlicher Agentenaktivität. Wenn ein fehlgeschlagener Lauf untersucht werden muss, bewahren Sie die Sandbox oder den Snapshot mit einer klaren Ablaufzeit auf.

Wo Novita Agent Sandbox passt

Novita Agent Sandbox ist für KI-Agenten-Ausführungsworkflows konzipiert, bei denen Code in isolierten Cloud-Arbeitsbereichen und nicht auf einem Entwickler-Laptop oder einem gemeinsam genutzten Host ausgeführt wird. Die Novita-Sandbox-Dokumentation beschreibt grundlegende Primitive, die dem Muster in diesem Leitfaden entsprechen: Sandbox-Lebenszyklusverwaltung, Dateisystemoperationen, Befehlsausführung, Vorlagen und Laufzeitverwaltung für Agenten-Workloads.

Das macht Novita zu einer geeigneten Lösung für Teams, die Codierungs-Agenten-, Datenanalyse-, Browser-Agenten-, Evaluierungs- oder langlebige Agenten-Workflows entwickeln, die eine Ausführungsumgebung zusammen mit Modell-APIs benötigen. Halten Sie die Grenze jedoch klar: Dieser Artikel ist ein allgemeines Implementierungsmuster für Claude Code-ähnliche und verwaltete Codierungs-Agenten. Es wird keine offizielle Claude Code-Integration, Partnerschaft oder universelle Kompatibilität mit jedem verwalteten Agentenprodukt behauptet.

Wenn Sie einen Novita-basierten Workflow entwerfen, verwenden Sie die Produktdokumentation für die genaue veröffentlichte API-Oberfläche und halten Sie Ihre Richtlinienebene explizit. Die Sandbox kann den isolierten Ausführungsarbeitsbereich bereitstellen; Ihre Anwendung sollte dennoch über Befehlsgenehmigungen, Netzwerkrichtlinien, Geheimnisumfang, Artefaktaufbewahrung und menschliche Überprüfungstoren entscheiden.

Sicherheitsüberprüfungs-Checkliste

Verwenden Sie diese Checkliste, bevor Sie einem Codierungs-Agenten erlauben, über ein Spielzeug-Repository hinaus zu arbeiten:

Frage	Worauf zu achten ist
Was ist die Isolationsgrenze?	Dedizierter Arbeitsbereich, Prozesslimits, Dateisystemtrennung und klare Anbieterdokumentation
Was kann der Agent lesen?	Standardmäßig nur Repository-Zugriff, kein Host-Home-Verzeichnis, keine nicht verwandten Repos
Was kann der Agent schreiben?	Beschreibbare Quellpfade sind explizit; sensible Konfigurationspfade erhalten zusätzliche Überprüfung
Welche Befehle laufen automatisch?	Test- und Formatierungsbefehle sind erlaubt; statusändernde Befehle erfordern Genehmigung
Welcher Netzwerkzugriff besteht?	Standardmäßig verweigern oder abgestufter Ausgang; Paketregistrierungen und Dokumentationsdomains sind beabsichtigt
Wie werden Paketinstallationen gehandhabt?	Lockfile-Änderungen, Registrierungs-Hosts und Installationsskripte werden protokolliert
Welche Geheimnisse sind vorhanden?	Nur aufgabenbezogene, kurzlebige, mit minimalen Rechten ausgestattete Anmeldeinformationen
Was passiert mit Protokollen?	Befehle, Ausgaben, Diffs und Artefakte überleben die Sandbox-Bereinigung
Wie wird die Bereinigung durchgesetzt?	Hintergrundprozesse, Ports, Tokens und temporäre Dateien werden geschlossen oder widerrufen
Wer genehmigt Merge oder Auslieferung?	Ein menschlicher Prüfer überprüft Code, Tests, sicherheitsrelevante Dateien und generierte Artefakte

Die wichtigste Regel ist einfach: Verwechseln Sie nicht „der Agent hat um Erlaubnis gefragt" mit „das System hat eine Grenze durchgesetzt". Das Modell kann helfen zu erklären, was es tun möchte. Die Laufzeit und die Richtlinienebene sollten entscheiden, was es tun darf.

FAQ

Kann man Claude Code in einer Sandbox ausführen?

Ja, wenn Ihr Setup den Claude Code-ähnlichen Agenten in einem abgegrenzten Arbeitsbereich platziert und Dateisystem-, Shell-, Netzwerk-, Geheimnis-, Protokollierungs- und Überprüfungsrichtlinien um ihn herum durchsetzt. Gehen Sie nicht davon aus, dass eine lokale Berechtigungsabfrage allein für Produktions- oder sensible Repositories ausreicht.

Ist ein Container für die Codierungs-Agenten-Isolation ausreichend?

Manchmal, aber die Antwort hängt von Ihrem Bedrohungsmodell ab. Container können für wiederholbare Builds und Abhängigkeitstrennung nützlich sein, aber sicherheitskritische Workloads sollten die Kernel-Grenze, Host-Mounts, Netzwerk-Standardeinstellungen, Laufzeitprivilegien und Anbieterdokumentation bewerten, bevor sie einen Container als vollständige Sandbox-Grenze betrachten.

Sollten Agenten Pakete installieren dürfen?

Sie können, aber Paketinstallationen sollten als kontrollierte Lieferkettenereignisse behandelt werden. Bevorzugen Sie Registrierungs-Allowlists oder Mirrors, Lockfile-Überprüfung, Installationsskript-Protokollierung und Genehmigung für neue Abhängigkeiten oder Befehle, die Remote-Code abrufen und ausführen.

Was sollte ein menschlicher Prüfer vor dem Merge überprüfen?

Überprüfen Sie den endgültigen Diff, ausgeführte Befehle, ausgeführte Tests, Paket- und Lockfile-Änderungen, berührte CI-/Bereitstellungsdateien, generierte Artefakte und alle abgelehnten oder genehmigungspflichtigen Aktionen. Für sicherheitskritische Repositories überprüfen Sie die Sandbox-Richtlinie selbst als Teil der Änderung.

Integriert Novita Agent Sandbox offiziell mit Claude Code?

Dieser Artikel behauptet dies nicht. Novita Agent Sandbox bietet isolierte Ausführungs-Primitive für Agenten-Workflows, während Claude Code und verwaltete Agentenprodukte ihre eigenen produktspezifischen Schnittstellen und Berechtigungsmodelle haben. Validieren Sie den genauen Integrationspfad anhand der aktuellen Produktdokumentation, bevor Sie ausführbare Befehle veröffentlichen.

Empfohlene Artikel

• Building a Coding Agent with Novita’s Agent Sandbox
• Run Harbor Agent Evaluations on Novita Agent Sandbox
• How to Use Codex with Novita AI Models