Sandboxed Execution für Coding Agents Wypróbuj

developer-aisecuritycoding-agentssandboxesleast-privilegedevexisolationapprovals

Überblick

Sandboxed Execution isoliert Coding Agents von der primären Entwicklermaschine, Credentials, Netzwerken und Produktionssystemen, während sie Packages installieren, Tools aufrufen oder Dateien ändern. OpenAI beschreibt die Codex Sandbox als die Boundary, die einem Agent autonomes Handeln ohne uneingeschränkten Maschinenzugriff erlaubt und definiert, welche Dateien modifiziert werden dürfen und ob Commands das Netzwerk nutzen dürfen (Codex sandboxing).

Sandboxing und Approvals sind getrennte Controls. Die Sandbox setzt technische Grenzen; die Approval Policy entscheidet, wann der Agent stoppen und fragen muss, bevor er diese überschreitet (Codex sandboxing). Das Muster ist besonders wichtig für Coding Agents, weil ihr Normalworkflow Shell Commands, Package Manager, Test Harnesses, Dateiänderungen und manchmal externe Systeme umfasst.

Der Grund für Trial: Sandboxing soll Standard-Control werden, Implementierungen sind aber noch uneinheitlich. Teams sollten Sandboxing für lokale Coding Agents, Cloud Agents, CI Agents und Developer Workstations testen und erst nach Validierung von Filesystem, Netzwerk, Secrets, Approvals, Logs und Escape Hatches standardisieren.

Adoptionssignale

  • Codex wendet Sandboxing automatisch im Default Permission Mode für lokale Commands in App, IDE Extension und CLI an, mit plattformnativer Enforcement auf macOS, Linux, WSL2 und native Windows (Codex sandboxing).
  • Codex definiert gängige Sandbox Modes: read-only, workspace-write und danger-full-access, plus Approval Policies wie untrusted, on-request und never (Codex sandboxing).
  • Codex stellt fest, dass gespawnte Commands wie git, Package Manager und Test Runner dieselben Sandbox Boundaries erben, nicht nur eingebaute File Operations des Agents (Codex sandboxing).
  • Claude Code dokumentiert ein sandboxed Bash Tool, bei dem Nutzer definieren, welche Dateien und Netzwerkdomains Commands berühren dürfen, und das Betriebssystem die Boundary für jeden Bash Command und Child Processes erzwingt (Claude Code sandboxing).
  • Claude Code unterstützt macOS Seatbelt und Linux/WSL2 bubblewrap mit Filesystem Controls für erlaubte und verweigerte Reads/Writes sowie Network Controls für erlaubte oder verweigerte Domains (Claude Code sandboxing).
  • Docker dokumentiert OpenCode in Docker Sandboxes mit sbx run opencode, Project-Directory-Isolation, gespeicherten Secrets, Credential Injection und Host-User-Level-Config-Isolation (Docker OpenCode sandbox).
  • OpenCode bietet ein Permission Model mit allow, ask und deny, inklusive Controls für File Reads, Edits, Bash Commands, Web Access, Subagents, Skills und External Directories (OpenCode permissions).
  • OWASPs Excessive Agency Guidance empfiehlt, Funktionen, Permissions und Autonomie für LLM-Systeme mit Tools oder Extensions zu begrenzen, inklusive Vermeidung offener Shell-Command-Tools, wo granularere Tools möglich sind (OWASP LLM06 Excessive Agency).

Risiken

  • Full-Access-Modi können die Boundary aufheben. Codex dokumentiert danger-full-access als Entfernen von Filesystem- und Netzwerk-Grenzen; Full Access kombiniert diesen Mode mit approval_policy = "never" (Codex sandboxing).
  • Network Allowlists sind schwer zu begründen. Claude Code warnt, dass breite erlaubte Domains Exfiltration-Pfade erzeugen und der eingebaute Proxy verschlüsselten Traffic nicht inspiziert; stärkere Garantien können einen custom TLS-inspecting Proxy erfordern (Claude Code sandboxing).
  • Credential Files und geerbte Environment Variables können leaken. Claude Code weist darauf hin, dass Credentials wie ~/.aws/credentials und ~/.ssh/ standardmäßig lesbar sind, sofern nicht verweigert, und sandboxed Bash Commands standardmäßig die Parent-Process-Environment erben (Claude Code sandboxing).
  • Docker-Zugriff kann Isolation brechen. Claude Code warnt, dass Zugriff auf /var/run/docker.sock effektiv Host-Zugriff über den Docker Socket gewährt (Claude Code sandboxing).
  • Permission Prompts sind nicht dasselbe wie OS Isolation. OpenCodes Permission Model kann fragen, erlauben oder verweigern, beschränkt aber nicht zwingend, was ein gespawnter Prozess auf OS-Ebene tut (OpenCode permissions).
  • Tool-Kompatibilität kann Ausnahmen erzwingen. Claude Code nennt Tools wie Docker, Watchman, bestimmte Go-CLIs oder Windows-Binaries unter WSL, die außerhalb der Sandbox laufen müssen und reviewte Exception Paths brauchen (Claude Code sandboxing).
  • Sandbox-Konfiguration kann pro Entwickler driften. Ist Sandboxing optional oder nur lokal konfiguriert, entstehen inkonsistente Safety Boundaries; Claude Code unterstützt Managed Settings, um Sandboxing zu erzwingen und unsandboxed Fallback zu verhindern (Claude Code sandboxing).
  • Sandboxing stoppt keine schlechten Commits. Eine Sandbox kann Execution Effects begrenzen, generierte Änderungen brauchen aber Human Review, Tests, Static Analysis, Dependency Scanning und Branch Protection vor dem Verlassen der Sandbox.

Vorteile & Nachteile

Vorteile

  • Gibt Coding Agents eine begrenzte Umgebung, in der sie Packages installieren, Dateien bearbeiten, Tests ausführen und Commands starten können, ohne uneingeschränkten Zugriff auf die Entwicklermaschine oder Produktionssysteme.
  • Reduziert Freigabe-Fatigue, indem sichere Aktionen innerhalb eines vorab freigegebenen Filesystem- und Netzwerkrahmens erlaubt sind und grenzüberschreitende Aktionen eskaliert werden.
  • Ermöglicht reproduzierbare und reviewbare Agent-Arbeit durch ephemere Umgebungen, explizite Secret Injection, resettbaren State, Artifact Review und klare Promotion-Pfade von Sandbox zu Branch oder Pull Request.

Nachteile

  • Sandboxing ist nicht einheitlich über Agents, Betriebssysteme und Deployment-Modi; Filesystem-, Netzwerk-, Secret- und Approval-Verhalten muss pro Tool verifiziert werden.
  • Breite Filesystem-Writes, Network Allowlists, Docker-Socket-Zugriff, geerbte Environment Variables oder unsandboxed Escape Hatches können eine Sandbox zur schwachen Boundary machen.
  • Sandboxes reduzieren Blast Radius, ersetzen aber nicht Code Review, Test Validation, Dependency Scanning, Prompt-Injection-Defenses oder Least-Privilege-Credentials für nachgelagerte Systeme.

Empfehlung

Testen Sie Sandboxed Execution als Baseline-Control für Coding Agents, bevor autonome Command Execution erlaubt wird. Starten Sie mit ephemeren oder resettbaren Umgebungen, auf den Workspace begrenzte Schreibzugriffe, keinem Host-Credential-Zugriff by default, Network Deny-by-Default mit engen Allowlists, expliziter Secret Injection, Resource Limits und Approval Gates für Aktionen außerhalb der Sandbox.

Validieren Sie die tatsächliche Boundary, nicht den Produktclaim. Prüfen Sie, ob der Agent SSH Keys, Cloud Credentials, Shell History, .env Files, Sibling Directories, Docker Sockets, Browser Profiles, interne Netzwerk-Endpunkte, Package-Manager-Lifecycle-Scripts und Production Deployment Credentials lesen kann. Bestätigen Sie, dass gespawnte Commands dieselbe Boundary erben und Logs zeigen, was ausgeführt wurde.

Promoten Sie Ergebnisse über reviewbare Artifacts. Agents sollten Diffs, Logs, Test Outputs und Summaries liefern, die Menschen vor Push, Merge, Deploy oder breiterem Zugriff prüfen. Wechseln Sie von Trial zu Adopt nur, wenn Sandbox Profiles, Secret Handling, Network Controls, Audit Logs und Exception Workflows über die Agent-Tools des Teams reproduzierbar sind.

Quellen