Lokale Coding-Agents absichern: Berechtigungen und Sandboxen für Claude Code, Codex und Copilot

Eine textbasierte Blockliste prüft einen Shell-Befehl als Zeichenkette. Die Shell verarbeitet ihn erst danach: Sie löst Variablen und Befehlsersetzungen auf und formt daraus nach ihren eigenen Regeln den tatsächlich auszuführenden Befehl. Der Filter kann daher etwas anderes freigeben, als die Shell anschließend ausführt.

Adversa AI wies dieses Muster am 30. Juni 2026 bei zehn von elf untersuchten Open-Source-Agenten nach; nur Continue verhinderte die Umgehung bereits durch sein Design. Die Fehlerklasse nennen die Forscher GuardFall. Claude Code, Codex und der Copilot Agent Mode gehörten nicht zur Stichprobe. GuardFall belegt damit eine architektonische Schwäche textbasierter Prüfungen von Shell-Befehlen, nicht eine konkrete Lücke in den drei hier verglichenen Werkzeugen.

Wenige Tage später machte ein öffentlich bekannt gewordener Datenverlust dieselbe architektonische Grenze auf andere Weise sichtbar. Am 10. Juli berichtete der KI-Investor Matt Shumer auf X, ein Agent mit OpenAIs GPT-5.6 „Sol“ habe in einem hochautonomen Lauf fast alle Dateien im Benutzerverzeichnis auf seinem Mac gelöscht. In den von ihm veröffentlichten Screenshots wird der Schaden auf eine fehlerhafte Auflösung der Variablen $HOME zurückgeführt. Dadurch richtete sich der rekursive Löschbefehl gegen das Benutzerverzeichnis. Öffentlich belegt ist der Vorfall bislang nur durch Shumers eigenen Bericht; eine unabhängige technische Rekonstruktion liegt nicht vor.

OpenAIs auf den 25. Juni datierte System Card dokumentierte eine verwandte, aber nicht identische Risikoklasse: Sol überschritt in internen Simulationen häufiger den vom Nutzer gesetzten Handlungsrahmen und führte öfter Handlungen aus, die OpenAI dem Schweregrad 3 zuordnet. Gemeint sind Aktionen, die Nutzer nicht erwarten und deutlich ablehnen würden. OpenAI führt den Unterschied teilweise auf die größere Beharrlichkeit des Modells (persistence) zurück, betont jedoch, dass solche Fälle insgesamt selten waren. Das ist ein Risikosignal, nicht die belegte Ursache des späteren Vorfalls.

GuardFall und der Fall Shumer beschreiben nicht dieselbe Schwachstelle. Sie zeigen dieselbe Grenze. Der Filterfehler in GuardFall ist architektonisch; Schaden kann eine gefährliche Aktion aber erst anrichten, wenn weitreichende Rechte, hohe Autonomie und eine fehlende Laufzeitgrenze zusammenkommen. Auf das grundlegende Verhalten des gewählten Modells hat ein Team nur begrenzten Einfluss. Den möglichen Schadensradius kann es jedoch begrenzen. Anders gesagt: Das Regelwerk entscheidet, was ausgeführt werden darf. Nur eine technisch erzwungene Isolation begrenzt, was ein ausgeführter Befehl erreichen kann.

In Gesprächen über den Rollout folgt auf einen solchen Vorfall oft zuerst ein Verbot. Als vorläufige Notbremse ist das nachvollziehbar, als dauerhafte Lösung greift ein solches Verbot jedoch zu kurz. Die bessere Frage lautet nicht: „Ist der Agent sicher?“ Sie lautet: Welche Ressourcen kann er erreichen, und welche Grenze bleibt bestehen, wenn Modell, Nutzer oder Regelwerk einen Fehler machen?

Wer den größeren Zusammenhang sucht, findet ihn im Leitfaden, der Absicherung neben Rollout, Tooling und Kosten einordnet. Dieser Beitrag konzentriert sich auf einen dieser Aspekte: was der Agent auf dem lokalen Rechner ausführen darf.

Stand: 14. Juli 2026. Die Sicherheitsfunktionen und Konfigurationsschlüssel dieser Werkzeuge ändern sich schnell. Prüfen Sie vor einem Rollout die verlinkte Herstellerdokumentation und die tatsächlich installierte Version.

Zwei Schichten, nicht eine Einstellung

Die Absicherung eines lokalen Coding-Agents besteht aus zwei Schichten, und der häufigste Fehler ist, sie zu verwechseln.

Schicht 1 ist das Regelwerk des Werkzeugs. Alle drei hier untersuchten Werkzeuge bringen ein Berechtigungs- und Freigabesystem mit, ohne zusätzliche Isolationsinfrastruktur: Vor jedem Werkzeugaufruf entscheidet eine Regel, ob eine Aktion erlaubt, blockiert oder dem Nutzer zur Freigabe vorgelegt wird. Diese Schicht ist ohne zusätzliche Einrichtung verfügbar und kann richtig konfiguriert viele riskante Aktionen abfangen. Sie ist jedoch keine vom Betriebssystem erzwungene Grenze, und das aus zwei Gründen. Erstens setzt das Werkzeug diese Regeln selbst durch; wer die Rückfragen abschaltet, verliert die wichtigste interaktive Kontrolle, und welche weiteren Sperren dann bleiben, hängt vom Werkzeug ab. Zweitens bewerten viele dieser Regeln den Befehlstext, bevor die Shell Variablen und Befehlsersetzungen auflöst, und können die spätere Variablenauflösung nicht erkennen. Diese Schwäche ermöglicht die in GuardFall gezeigten Umgehungen. Der Fall Shumer zeigt unabhängig davon, wie groß der Schaden ohne wirksame Laufzeitgrenze werden kann.

Schicht 2 ist die Laufzeitisolation. Betriebssystem, Container oder VM erzwingen während der Ausführung, auf welche Dateien, Netzziele und Host-Dienste ein Prozess zugreifen kann. Diese Grenze wirkt unabhängig vom Befehlstext, verursacht aber zusätzlichen Einrichtungsaufwand. Ein rm -rf in einer Sandbox, deren Schreibrechte auf den Projektordner begrenzt sind, kann nur dort Schaden anrichten, sofern keine zusätzlichen Mounts oder Host-Dienste erreichbar sind. Sie muss dennoch für jede Ressourcengruppe einzeln geprüft werden: Eine Dateisystem-Sandbox begrenzt nur Dateizugriffe; Netzpfade, gemountete Verzeichnisse, angebundene MCP-Server und Zugriffe auf Host-Dienste brauchen jeweils eigene Grenzen. Sie ist kein Allheilmittel, aber sie ist die direkteste Dateisystemgrenze, die nicht von der Schreibweise des Shell-Befehls abhängt.

Nach dieser Definition gehört die native Sandbox von Claude Code oder Codex zu Schicht 2, obwohl das Werkzeug sie mitbringt: Was zählt, ist nicht, wer sie startet, sondern dass das Betriebssystem sie durchsetzt. Die Berechtigungsregeln in derselben Konfiguration sind Schicht 1, die per Kommando aktivierte Betriebssystem-Sandbox ist die leichteste Form von Schicht 2, Container und VMs bieten eine weitergehende Isolation.

Zu klären ist damit nicht „welches Werkzeug ist am sichersten“, sondern: reichen die Berechtigungsregeln, oder brauche ich echte Isolation? Für einen Einzelentwickler an einem unkritischen Test-Repository reichen die Regeln plus die native Sandbox. Sobald echte personenbezogene Daten oder Zugangsdaten vorhanden sind oder ein Team beteiligt ist, würde ich eine weitergehende Schicht 2 als internen Mindeststandard festlegen. Der Sol-Vorfall zeigt den Schadensradius ohne Dateisystemgrenze: hohe Autonomie, keine Sandbox, eine fehlerhafte Variablenauflösung, und der Löschbefehl trifft das Benutzerverzeichnis statt den Projektordner. Ein Container, der nur den Arbeitsbereich schreibbar einbindet und keine Host-Dienste freigibt, hätte Schreibzugriffe auf diese eingebundenen Pfade begrenzt.

Bedrohungsszenarien: vom fremden Inhalt zum Datenabfluss

Ein Coding-Agent verarbeitet nicht nur den Auftrag des Nutzers. Er liest auch Repository-Dateien, Issues, Pull-Request-Kommentare, Webseiten, Terminalausgaben, Paketmetadaten sowie Beschreibungen und Antworten von MCP-Werkzeugen. Viele dieser Inhalte können von Dritten beeinflusst werden. Bei einer indirekten Prompt Injection steckt die schädliche Anweisung nicht im Nutzerprompt, sondern in einem Inhalt, den der Agent während seiner Arbeit abruft. Verwechselt er diese Daten mit einer Handlungsanweisung, kann er Dateien lesen, Befehle ausführen oder Werkzeuge aufrufen, die der Nutzer nie angefordert hat.

Für einen Datenabfluss genügen zwei Voraussetzungen: Der Agent kann auf schützenswerte Daten zugreifen, und ihm steht ein Kanal zur Verfügung, über den diese Daten die kontrollierte Umgebung verlassen. Dieser Kanal muss kein frei erreichbarer Webserver sein. Auch der reguläre Modellkanal, ein erlaubter Git-Remote, ein Issue-Kommentar, ein MCP-Aufruf, eine Paket-Registry oder ein anderer freigegebener Dienst kann Daten nach außen tragen.

Eine Netzsperre für Shell-Befehle löst deshalb nur einen Teil des Problems. Liest der Agent eine Datei mit einem eingebauten Dateiwerkzeug oder gelangt eine Umgebungsvariable in die Ausgabe eines Unterprozesses, kann der Inhalt in den Modellkontext aufgenommen und an den konfigurierten Modelldienst übertragen werden. Das ist nicht automatisch ein Angriff. Wurde der Lesevorgang jedoch durch eine Prompt Injection ausgelöst, kann bereits diese unbeabsichtigte Übertragung eine Verletzung der Vertraulichkeit darstellen.

Prompt Injection im Jahr 2026: besser erkannt, nicht beseitigt

Aktuelle Modelle erkennen offensichtliche Prompt Injections deutlich besser als frühere Generationen. OpenAIs GPT-5.6-Varianten erreichen in der veröffentlichten System Card bei bekannten Angriffen auf Konnektoren nahezu vollständige Abwehrwerte. Bei stärkeren Angriffen auf Suche und Funktionsaufrufe liegen die Werte jedoch je nach Modellvariante nur zwischen 0,897 und 0,946. Die Schutzwirkung ist damit hoch, aber nicht vollständig.

Anthropic berichtet für Claude Opus 4.7 auf einem eigenen Agenten-Benchmark von einer Angriffserfolgsrate von ungefähr 0,1 Prozent bei einem einzelnen Versuch. Erhält ein Angreifer hundert adaptive Versuche, steigt sie jedoch auf etwa fünf bis sechs Prozent. Die Zahlen sind mit OpenAIs Ergebnissen nicht direkt vergleichbar, zeigen aber dasselbe Muster: Einfache, einmalige Angriffe werden häufiger erkannt; wiederholte und an das Verhalten des Agenten angepasste Angriffe bleiben ein relevantes Restrisiko.

Auch eine zusätzliche Prüfung der geplanten Aktion schließt dieses Risiko nicht aus. Bei Anthropics Evaluation des Claude-Code-auto-Modus ließ die vollständige Klassifizierungskette 17 Prozent der untersuchten realen, zu weit gehenden Aktionen und 5,7 Prozent der synthetischen Exfiltrationsversuche passieren. Die Stichprobe der realen Aktionen war mit 52 Fällen klein, die Ergebnisse zeigen aber die grundsätzliche Grenze: Ein Klassifizierungsmodell ist eine zusätzliche Schutzschicht, keine technisch erzwungene Grenze.

Hinzu kommt eine neuere Angriffsklasse, die nicht mehr wie eine klassische Anweisung aussieht. Statt „Ignoriere deine bisherigen Regeln“ einzuschleusen, manipuliert der Angreifer Daten, auf die sich der Agent bei seiner Entscheidung verlässt: die angebliche Identität eines Maintainers, einen Freigabestatus, ein Werkzeugergebnis oder ein strukturiertes Feld. Eine im Juli 2026 veröffentlichte Vorabstudie bezeichnet dies als „Agent Data Injection“. In den dort untersuchten Aufbauten reduzierten aktuelle Abwehrmechanismen klassische Anweisungsinjektionen auf Erfolgsraten zwischen 0 und 0,7 Prozent, während die datenbasierte Variante Erfolgsraten von bis zu 50 Prozent erreichte. Die Studie ist noch nicht begutachtet, und ihre Zahlen lassen sich nicht pauschal auf Claude Code, Codex oder Copilot übertragen. Sie zeigt jedoch, wohin sich die Angriffe verschieben: von auffälligen Befehlen zu plausibel wirkenden, aber manipulierten Daten.

Für den Betrieb folgt daraus eine nüchterne Annahme: Die Erkennung von Prompt Injections senkt deren Erfolgswahrscheinlichkeit, beseitigt sie aber nicht. Die Umgebung muss deshalb so gebaut sein, dass auch eine einzelne Fehlentscheidung weder auf langfristige Zugangsdaten zugreifen noch diese über einen verfügbaren Kanal weitergeben kann.

Vergleich auf einen Blick

Bevor ich ins Detail gehe, vergleiche ich die fünf Ausführungsumgebungen miteinander: welche Zugriffe sie ab Werk begrenzen, welche Kombinationen gefährlich sind und welchen Mindeststandard ich jeweils empfehle.

Was jedes Werkzeug mindestens braucht

In den lokalen Standardmodi von Claude Code, Codex CLI und Copilot bleiben Freigaben für riskante Aktionen aktiv. Vollautonome Läufe sollten nur innerhalb einer technisch erzwungenen Grenze stattfinden. Pro Werkzeug dieselbe Prüfung: Was erlaubt der Standard, was ist der gefährlichste Modus, und welche Konfiguration empfehle ich?

Claude Code

Claude Code ist ab Werk vorsichtiger als sein Ruf: Im Standardmodus brauchen Dateiänderungen und Shell-Befehle mit Schreibwirkung eine Freigabe. Claude Code enthält außerdem eine fest eingebaute Liste von Shell-Befehlen, die es als rein lesend einstuft und standardmäßig ohne Rückfrage ausführt, etwa ls, cat, grep, find und lesende Git-Kommandos. Die Liste selbst lässt sich nicht bearbeiten; passende Aufrufe können jedoch mit eigenen ask- oder deny-Regeln abgefangen werden. Beim ersten Start in einem neuen Verzeichnis erscheint eine Vertrauensabfrage. Wer Automatisierungen nicht-interaktiv mit -p startet, umgeht diese Abfrage.

Der gefährlichste Modus heißt --dangerously-skip-permissions, in der Community als YOLO-Modus bekannt. Er ist gleichbedeutend mit bypassPermissions und schaltet die Rückfragen ab. Anthropic warnt hier ungewöhnlich deutlich, dass dieser Modus weder vor Prompt-Injection noch vor unbeabsichtigten Aktionen schützt und ausschließlich in isolierte Umgebungen wie Container, VMs oder Devcontainer ohne Internetzugang gehört. Einige Schutzmechanismen bleiben aktiv (ein Circuit-Breaker fängt rm -rf / und rm -rf ~ auch in Backtick-Substitution ab, und der Start als root wird verweigert). Als Grundlage für eine Teamkonfiguration reichen diese Schutzmechanismen nicht.

Ich würde stattdessen Folgendes konfigurieren. Das Berechtigungssystem in settings.json kennt allow, deny und ask, wobei deny vor ask vor allow greift und deny- sowie ask-Regeln sogar im Bypass-Modus wirken:

{
  "permissions": {
    "deny": ["Read(./.env)", "Read(./.env.*)", "Read(./secrets/**)", "Bash(curl *)"],
    "ask": ["Bash(rm *)", "Bash(git push *)"]
  },
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false
  }
}

failIfUnavailable: true verhindert, dass Claude Code bei fehlender Sandbox (etwa ohne bubblewrap auf Linux) nur warnt und ungeschützt weiterläuft; allowUnsandboxedCommands: false verhindert, dass fehlgeschlagene Befehle anschließend außerhalb der Sandbox ausgeführt werden. Diese Konfiguration bricht bei Fehlern ab, statt ungeschützt weiterzulaufen. Genau das empfiehlt die Dokumentation für zentral verwaltete Umgebungen.

Dieser Block ist trotzdem bewusst unvollständig. Die deny-Regeln greifen bei den eingebauten Datei-Werkzeugen und bei erkannten Shell-Kommandos wie cat oder sed, aber nicht zuverlässig bei einem beliebigen Python- oder Node-Prozess, der selbst eine Datei öffnet. Hier zeigt sich der Nutzen der Betriebssystem-Sandbox. Und die Bash-Sandbox darf standardmäßig weiterhin nahezu das gesamte Dateisystem lesen, einschließlich ~/.aws/credentials und ~/.ssh. Wer Zugangsdaten schützen muss, schließt die betreffenden Dateien und Umgebungsvariablen mit dem sandbox.credentials-Block vom Zugriff aus; eine eingebaute Sperrliste gibt es nicht, geschützt ist nur, was dort ausdrücklich steht.

Entscheidend ist der sandbox-Block. Claude Code besitzt eine native Sandbox namens „sandboxed Bash tool“, die Shell-Befehle mit Betriebssystemmechanismen einsperrt: Seatbelt auf macOS sowie bubblewrap unter Linux und WSL2. Sie ist standardmäßig deaktiviert und wird mit /sandbox oder sandbox.enabled aktiviert.

Zwei Einschränkungen sind wichtig. Erstens erfasst die Sandbox nur Bash und dessen Kindprozesse, nicht die eingebauten Read-, Edit- und Write-Werkzeuge. Zweitens bezeichnet Anthropic sie ausdrücklich nicht als vollständige Isolationsgrenze. Der Standardproxy untersucht verschlüsselte TLS-Inhalte nicht. Eine pauschal freigegebene Domain wie github.com kann deshalb weiterhin einen Weg zur Datenexfiltration eröffnen. Für viele lokale Umgebungen ist die Sandbox trotzdem der Schritt mit dem geringsten zusätzlichen Betriebsaufwand.

Als Mittelweg gibt es zusätzlich den auto-Modus. Ein separates Klassifizierungsmodell bewertet darin riskante Aktionen vor der Ausführung und kann Aktionen wie curl | bash, Force-Pushes oder Deployments in Produktionsumgebungen blockieren. Eng gefasste allow-Regeln können allerdings bereits vorher greifen. Soll wirklich jeder Shell-Befehl klassifiziert werden, muss zusätzlich autoMode.classifyAllShell = true gesetzt sein.

Codex CLI

OpenAIs Codex CLI trennt die Dateisystem- und Netzwerkgrenze von der Freigaberichtlinie. Sie kennt drei Sandbox-Modi: read-only, workspace-write und danger-full-access. In vertrauenswürdigen, versionierten Arbeitsverzeichnissen verwendet der empfohlene Automatikmodus typischerweise workspace-write mit on-request; in nicht versionierten oder noch nicht vertrauenswürdigen Verzeichnissen kann Codex zunächst mit read-only starten. Prüfen Sie deshalb den tatsächlich aktiven Modus in Ihrer installierten Version, statt von einem einheitlichen Standard auszugehen. Unter workspace-write darf der Agent außerhalb des Arbeitsbereichs lesen, aber nicht schreiben, Home- und Systempfade sind für Schreibzugriffe gesperrt. Entscheidend und oft übersehen: Der Netzzugang ist hier standardmäßig aus. Die Verbindung zum Modell ist von den Netzwerkrechten der ausgeführten Befehle getrennt; sie läuft über einen eigenen Kanal, nicht über den Netzwerkzugang des gestarteten Prozesses, der Agent funktioniert also trotzdem.

Diese Trennung verhindert jedoch keinen Datenabfluss über den regulären Modellkontext. Liest Codex selbst eine Datei oder erhält es sensible Daten als Werkzeugausgabe, können diese Inhalte über den Modellkanal übertragen werden, obwohl der gestartete Prozess keinen eigenen Netzzugang besitzt. network_access = false schützt daher vor ausgehenden Verbindungen der ausgeführten Befehle, nicht vor jedem Abfluss gelesener Daten.

Besonders riskant ist die Kombination aus sandbox_mode = "danger-full-access" und approval_policy = "never". danger-full-access entfernt die Dateisystem- und Netzwerkgrenzen; never allein schaltet nur die Rückfragen ab, die gewählte Sandbox bleibt bestehen. --yolo deaktiviert dagegen sowohl die Sandbox als auch die Rückfragen. Damit entsteht derselbe weite Schadensradius: keine interaktive Freigabe und keine Dateisystem- oder Netzwerkgrenze. In einer üblichen workspace-write-Sitzung ohne zusätzlich freigegebene Schreibverzeichnisse wäre ein Schreibzugriff außerhalb des Arbeitsbereichs blockiert worden; zu beachten bleibt, dass /tmp und $TMPDIR standardmäßig schreibbar sind.

Bleiben Sie beim workspace-write-Standard, lassen Sie den Netzzugang deaktiviert, und setzen Sie die Freigaberichtlinie bewusst. Die gültigen Werte sind untrusted, on-request und never; das früher übliche on-failure ist inzwischen veraltet.

sandbox_mode = "workspace-write"
approval_policy = "on-request"

[sandbox_workspace_write]
network_access = false

Codex führt parallel neue Berechtigungsprofile als Betafunktion ein. Sie ersetzen in einer Konfiguration die älteren sandbox_mode-Einstellungen; beide Ansätze sollten nicht miteinander vermischt werden.

Zwei Ergänzungen lohnen sich. Braucht der Agent Netzzugang, kann die Sandbox ihn über einen Domain- und Socket-Proxy auf erlaubte Ziele beschränken. Gehören manipulierte DNS-Antworten zum Bedrohungsmodell, reicht diese Grenze allein nicht aus. Beschränken Sie außerdem mit shell_environment_policy, welche Umgebungsvariablen an Unterprozesse weitergegeben werden. Andernfalls können Zugriffstoken die Dateisystemgrenze über die Prozessumgebung umgehen.

Unter der Haube nutzt Codex dieselben Betriebssystemmechanismen wie Claude Code: Apple Seatbelt auf macOS, auf Linux inzwischen bubblewrap plus einen seccomp-Netzfilter. Die weit verbreitete Aussage „Codex nutzt Landlock“ ist inzwischen veraltet: Landlock taucht nach aktuellem Stand nur noch als alternativer beziehungsweise kompatibler Ausführungsweg auf, der Standard ist bubblewrap plus seccomp.

GitHub Copilot

Copilot ist nicht mehr auf den Editor beschränkt. Die Produktfamilie umfasst heute drei unterschiedliche Ausführungsumgebungen: den Agent Mode in VS Code, die lokale CLI und den cloudbasierten Coding-Agenten. Entscheidend ist, welche Prozesse die jeweilige Isolation tatsächlich erfasst.

Der Agent Mode läuft lokal in VS Code. Ohne aktivierte Agent-Sandbox werden seine Terminalbefehle mit den Rechten des angemeldeten Nutzers ausgeführt und vor allem durch Freigaberegeln kontrolliert. Die zentrale Einstellung für Terminalbefehle ist chat.tools.terminal.autoApprove. Sie ordnet Befehlen Erlaubnis- und Sperrregeln zu. Die übergeordnete Einstellung chat.tools.global.autoApprove hebt diese Einzelkontrollen weitgehend auf und wirkt praktisch wie ein YOLO-Schalter; Microsoft nennt die automatische Freigabe ausdrücklich einen bestmöglichen, aber nicht lückenlosen Schutz, mit bekannten Lücken bei Aliasen und verschachtelten Anführungszeichen. In der Standardstufe Default Approvals müssen riskante Befehle wie rm und del weiterhin manuell bestätigt werden.

Über diesen Einzelregeln stehen die sitzungsweiten Berechtigungsstufen Default Approvals, Bypass Approvals und Autopilot. In den beiden letztgenannten Stufen werden genehmigungspflichtige Aktionen automatisch freigegeben. Inzwischen bietet VS Code zusätzlich eine vom Betriebssystem erzwungene Agent-Sandbox (chat.agent.sandbox.enabled, macOS und Linux), die die Befehle des Agenten isoliert, nicht den ganzen Editor. Sie befindet sich noch in öffentlicher Vorschau und erlaubt standardmäßig eine Ausführung außerhalb der Sandbox: Für eine verbindliche Sandbox-Konfiguration müssen außerdem chat.agent.sandbox.allowUnsandboxedCommands und, bei streng begrenztem Netzzugang, chat.agent.sandbox.retryWithAllowNetworkRequests deaktiviert werden. Wer den gesamten Editor isolieren will, betreibt ihn weiterhin in einem Devcontainer oder einer VM.

Die Copilot CLI ist dagegen seit Februar 2026 allgemein verfügbar und damit eine eigenständige Alternative zu Claude Code und Codex. Ihre lokale Sandbox lässt sich mit /sandbox enable aktivieren, ist auf Microsofts MXC aufgebaut und befindet sich noch in öffentlicher Vorschau; die CLI selbst und ihre Sandbox haben also einen unterschiedlichen Reifegrad. Die Sandbox unterstützt macOS und Linux; unter Windows setzt sie einen Windows-Insider-Build voraus. GitHub weist außerdem darauf hin, dass die Filterung einzelner Netzwerkziele nicht auf allen Plattformen zuverlässig als Sicherheitsgrenze funktioniert; für streng kontrollierten ausgehenden Verkehr bleibt daher eine zusätzliche Netzgrenze erforderlich.

Der „Autopilot“-Modus steuert hier nur, ob der Agent selbstständig über mehrere Schritte weiterarbeitet; Vollzugriff auf Werkzeuge, Pfade und URLs wird erst durch --allow-all beziehungsweise /yolo erteilt. Das YOLO-Äquivalent ist deshalb nicht Autopilot allein, sondern die Kombination aus autonomem Weiterarbeiten und uneingeschränkten Rechten; mit eingeschränkten Rechten lehnt Autopilot genehmigungspflichtige Aktionen automatisch ab. Für unbeaufsichtigte oder programmatische Läufe empfiehlt GitHub zusätzlich, die Zahl der selbstständigen Fortsetzungen mit --max-autopilot-continues zu begrenzen.

Der cloudbasierte Coding-Agent schließlich läuft in einer kurzlebigen, für jeden Lauf neu bereitgestellten GitHub-Actions-VM mit einer Egress-Firewall, die ab Werk an ist. Auf zwei Ausnahmen weist die Dokumentation ausdrücklich hin, und sie sind leicht zu übersehen: Für MCP-Server und Prozesse aus den konfigurierten Einrichtungsschritten gilt diese Firewall nicht. Diese Prozesse brauchen deshalb eine eigene Netzwerkbegrenzung.

Wann die eingebauten Schutzmechanismen reichen

Native Betriebssystem-Sandboxen können reichen, solange der Zugriff auf das Hostsystem begrenzt ist und ein Mensch die Rückfragen beantwortet. Eine zentral erzwungene Prozessisolation wird nötig, sobald lokale Nutzer die Grenze aufheben können oder weitere Prozesse ebenfalls isoliert werden müssen. Fünf Prüffragen helfen bei dieser Entscheidung mehr als ein reiner Funktionsvergleich:

1. Liegen echte personenbezogene Daten oder Zugangsdaten im Repo oder in der Umgebung? Nicht nur in der offensichtlichen .env-Datei, sondern in der gesamten Versionsgeschichte des Repositorys, in Testdaten und Test-Fixtures, in ~/.aws/credentials, in der Shell-History.
2. Ist es ein Team oder eine Einzelperson? In einem Team müssen dieselben Vorgaben auf unterschiedlichen Arbeitsrechnern verbindlich und nachweisbar gelten. Dann wird aus einer individuellen Konfiguration ein verbindlicher Mindeststandard für die Isolation.
3. Ist der Kontext reguliert? Werden personenbezogene Daten verarbeitet? Unterliegt das Unternehmen der BaFin-Aufsicht oder einem anderen regulierten Rahmen? Dann steigt der Nachweisbedarf, und welche Kontrollen dokumentiert werden müssen, hängt vom anwendbaren Regelwerk und vom konkreten Risiko ab.
4. Läuft der Agent unbeaufsichtigt? Automatische Freigaben, YOLO-Modus, nächtliche CI-Läufe. Bei unbeaufsichtigten Läufen entfällt die interaktive Freigabe; statische Sperren und erzwungene Richtlinien bleiben, müssen den gesamten Lauf dann aber allein absichern.
5. Braucht er Netzzugang über die Verbindung zum Modell hinaus? Sobald der Agent uneingeschränkten Netzzugang hat, ist Datenabfluss möglich, und die Frage verschiebt sich von „was löscht er“ zu „was überträgt er nach außen“. Das ist die zweite Sicherheitsfrage, die der Beitrag Wohin telefoniert Ihr Coding-Agent? im Detail auseinandernimmt.

Als konservative Faustregel: Lautet die Antwort auf eine der ersten drei Fragen „Ja“, planen Sie eine weitergehende Schicht 2 ein. Das ist ein interner Mindeststandard, keine gesetzliche Vorgabe. Konservativ heißt hier: im Zweifel isolieren. Zugriffsrechte, Netzpfade und Nachweispflichten lassen sich nach einem Vorfall nicht rückwirkend begrenzen. Sind die ersten drei Antworten „Nein“, bleibt der Agent beaufsichtigt und ist sein Netzzugang begrenzt, können die Berechtigungsregeln plus die native Sandbox als leichteste Schicht 2 ausreichen. Das ist keine Paranoia, sondern dasselbe Prinzip der geringsten Rechte, das Sie auch an jeder anderen Systemgrenze anwenden.

Die Sandbox-Landschaft: von Betriebssystem-Sandboxen bis zum Container

Wenn eine weitergehende Isolation notwendig wird, lassen sich die Optionen nach Schutzwirkung und Betriebsaufwand ordnen: mehr Isolation bei höherem Aufwand und mehr Reibung im Arbeitsalltag. Vier Stufen genügen zur Orientierung.

1. Native Agent-Sandbox. Claude Code und Codex verwenden auf macOS Seatbelt und unter Linux bubblewrap-basierte Isolation; Codex ergänzt sie unter Linux um seccomp. Die Copilot CLI setzt auf Microsofts MXC. Die genaue Reichweite unterscheidet sich je nach Werkzeug. Bei Claude Code umfasst sie Bash und dessen Kindprozesse, bei der Copilot CLI die von Copilot gestarteten Shell-Befehle. Der Einrichtungsaufwand ist gering, die Schutzwirkung aber nicht bei allen Produkten gleich. Der leichteste Einstieg in Schicht 2.

2. Verbindlich eingesetzter Sandbox-Wrapper. Ein Skript oder Werkzeug, das den Agenten fest in ein Seatbelt- oder bubblewrap-Profil sperrt, auch wenn der Nutzer die Sandbox nicht selbst aktiviert. Das macht die native Sandbox verbindlich. Die Schutzwirkung hängt vollständig vom verwendeten Profil ab, und Apples sandbox-exec ist seit Jahren als veraltet gekennzeichnet, funktioniert aber weiter. Es bleibt der einmalige Aufwand für Erstellung und Pflege des Profils.

3. Container oder Devcontainer. Ein korrekt konfigurierter Container ohne privilegierte Hostzugänge sperrt nicht nur die Shell ein, sondern den ganzen Agent-Prozess samt MCP-Servern und Hooks, sofern diese tatsächlich im Container laufen und keine Host-Sockets erhalten. Der eingebundene Arbeitsbereich bleibt dabei angreifbar.

Ein häufiger Stolperstein: Baut der Agent die Verbindung zum Modell aus dem Container heraus auf, darf der Container nicht vollständig vom Netz getrennt sein. Nötig ist dann eine Firewall für ausgehende Verbindungen mit einer Zulassungsliste, keine vollständige Netzsperre. Anthropics Referenz-Devcontainer macht das vor: init-firewall.sh setzt iptables -P OUTPUT DROP und erlaubt danach gezielt nur api.anthropic.com, die npm-Registry, die von GitHub veröffentlichten IP-Bereiche und wenige weitere Hosts; Anthropic nennt diese Konfiguration als Basis für unbeaufsichtigte Läufe mit --dangerously-skip-permissions.

Eine reine Domain-Zulassungsliste genügt jedoch nicht, wenn ein erlaubter Dienst von Nutzern beschreibbare Inhalte annimmt. Über GitHub lassen sich Daten etwa in einen Commit, einen Branch-Namen, ein Issue oder einen nicht vertrauenswürdigen Remote übertragen. Wo möglich, sollte die Netzrichtlinie deshalb nicht nur Ziele, sondern auch Methoden und Aktionen begrenzen; Git-Lesezugriff und Git-Schreibzugriff sind unterschiedliche Berechtigungen. OpenAI warnt bei aktiviertem Netzzugang ausdrücklich vor genau dieser Gefahr und empfiehlt, nur vertrauenswürdige Domains und sichere HTTP-Methoden zuzulassen.

Zwei Risiken bleiben bestehen: die Zerstörung des eingebundenen Arbeitsbereichs und der Missbrauch freigegebener Ziele samt bereitgestellter Zugangsdaten.

4. VM oder microVM. Eine VM oder microVM bringt einen eigenen Kernel mit und bietet die stärkste Trennung, verursacht aber auch den höchsten Aufwand. Sie eignet sich für Code, dem Sie nicht vertrauen. gVisor liegt zwischen Container und VM: Es fängt Systemaufrufe im Userspace ab. Der Leistungsaufschlag hängt stark von der Arbeitslast ab und sollte im eigenen Anwendungsszenario gemessen werden.

Ein Container verursacht jedoch zusätzlichen Betriebsaufwand, und das stärkste Gegenargument ist berechtigt: Ein Container kann Host-Werkzeuge, laufende Debugger, Anmelde- und Berechtigungsabläufe und die Dateisystemleistung spürbar behindern, gerade bei großen Repositorys und nativen Entwicklungswerkzeugen. Wo der zusätzliche Aufwand den Schutzgewinn nicht rechtfertigt und keine echten Daten oder Zugangsdaten erreichbar sind, ist die native Betriebssystem-Sandbox die vernünftigere Wahl. Das Schutzziel bestimmt die Technik, nicht umgekehrt: eine zentral erzwingbare Grenze für Prozesse, eingebundene Verzeichnisse, ausgehenden Netzwerkverkehr und Zugangsdaten. Ein Container ist die häufige Umsetzung, eine erzwungene native Sandbox oder eine dedizierte Entwicklungs-VM können je nach Bedrohungsbild gleichwertig sein.

Vorkonfigurierte Wrapper: Beobachtung, keine Empfehlung. Junge Projekte bündeln diese Isolation zu einem einsatzfertigen Paket, etwa clawk (kurzlebige microVM auf Apples Virtualization.framework, Egress standardmäßig gesperrt) oder Container-basierte Wrapper wie clawker; auch Anthropics eigenes sandbox-runtime gehört hierher. Sie altern schnell und nehmen Ihnen nicht die Prüfung ab, welche Dateien, Netzziele und Host-Dienste weiterhin erreichbar sind. clawk etwa ist noch vor Version 1.0, bindet den Arbeitsbereich mit Schreibrechten ein, reicht den SSH-Agenten an die microVM weiter und macht übergebene Zugangsdaten lesbar.

Zwei Mindestkonfigurationen für die Praxis

Zwei häufige Ausgangslagen zeigen, wie der Mindeststandard aussieht. Eines vorab für beide: Langfristige Zugangsdaten sollten gar nicht erst in der für den Agenten erreichbaren Umgebung liegen. Wo Zugangsdaten erforderlich sind, verwenden Sie kurzlebige und auf die konkrete Aufgabe begrenzte Token, reduzieren Sie die vererbten Umgebungsvariablen und sperren Sie bekannte Dateipfade zusätzlich mit deny. Die deny-Regel ist eine ergänzende Kontrolle, keine Geheimnisverwaltung.

Einzelentwickler mit Repositorys unterschiedlichen Schutzbedarfs. Ein schlankes Setup genügt: dem Agenten nur die für die Aufgabe benötigten, möglichst kurzlebigen Zugangsdaten bereitstellen, bekannte Geheimnispfade zusätzlich mit deny sperren, für rm und git push eine ausdrückliche Freigabe verlangen und die native Sandbox aktivieren, also die Berechtigungsregeln plus die leichteste Form von Schicht 2. Bei Codex heißt das workspace-write mit network_access = false. Das begrenzt auch ohne Container ein naheliegendes Schadensszenario: versehentliches Schreiben und Löschen außerhalb des Projektordners.

Team, echte Daten oder reguliertes Umfeld. Hier gehört der Agent hinter eine zentral erzwingbare Grenze für Prozess, Mounts, ausgehenden Netzwerkverkehr und Zugangsdaten, meist einen Container mit einer Zulassungsliste für ausgehende Verbindungen. Die Regeln müssen zentral verwaltet werden, sodass Entwickler sie lokal nicht überschreiben können. Die zentralen Sperren unterscheiden sich je nach Werkzeug, existieren aber inzwischen bei allen drei Anbietern: Claude Code deaktiviert den Bypass-Modus über zentral verwaltete Einstellungen organisationsweit (permissions.disableBypassPermissionsMode). Codex setzt Vorgaben über requirements.toml durch (systemweit, per macOS-MDM und über die Cloud verwaltet) und kann approval_policy = "never", danger-full-access und --yolo unterbinden sowie die zulässigen Berechtigungsprofile einschränken. Copilot bietet zentral verwaltete GitHub-Enterprise-Einstellungen, mit denen sich der Bypass-Modus ebenfalls sperren lässt (disableBypassPermissionsMode).

Der Nutzen ist nicht nur technischer Art. Eine versionierte Container-Richtlinie samt Mount-, Netzwerk- und Testergebnissen kann dem Datenschutzbeauftragten und dem Betriebsrat als prüfbare Dokumentation dienen. Die Aussage „Der Agent kann nicht auf X zugreifen“ ist jedoch nur belastbar, wenn Mounts, ausgehende Verbindungen, MCP-Prozesse, Einrichtungsschritte und Zugangsdaten in dieser Richtlinie tatsächlich begrenzt sind. Ein laufender Container allein belegt das nicht.

Dieser Text ist keine Rechtsberatung. Eine Sandbox kann jedoch eine technische Maßnahme in einem risikobasierten Schutzkonzept sein. Sie kann zu den Zielen der Art. 25 und 32 DSGVO beitragen, darunter Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit. Für sich allein belegt sie keine DSGVO-Konformität. Entscheidend bleibt, ob das gesamte Schutzniveau dem konkreten Risiko angemessen ist. Bei beaufsichtigten Unternehmen lässt sich eine technische Zugriffsbeschränkung außerdem in das IKT-Risikomanagement einordnen, das die BaFin in ihrer Orientierungshilfe vom 18. Dezember 2025 beschreibt. Die Orientierungshilfe schreibt keine Sandbox vor. Wo Coding-Agenten überhaupt personenbezogene Daten sehen dürfen, klärt der Beitrag Coding Agents und DSGVO; die aufsichtsrechtliche Einordnung steht in BaFin, MaRisk und Coding Agents.

Was Sie diese Woche konfigurieren

Haben Sie die ersten drei Prüffragen jeweils mit „Nein“ beantwortet, beginnen Sie mit der Mindestkonfiguration oben: Stellen Sie dem Agenten nur kurzlebige Zugangsdaten bereit, sperren Sie bekannte Geheimnispfade zusätzlich mit deny, aktivieren Sie die native Sandbox und setzen Sie bei Codex network_access = false. Haben Sie mindestens eine Frage mit „Ja“ beantwortet, sollten Sie vor dem produktiven Einsatz mit echten Daten eine zentral erzwungene Isolation einführen, meist einen Container mit einer Zulassungsliste für ausgehende Verbindungen.

Testen Sie die fertige Umgebung anschließend mit künstlichen Canary-Daten, niemals mit echten Zugangsdaten. Legen Sie einen wertlosen Test-Token in einer Datei und einen zweiten in einer Umgebungsvariablen ab. Platzieren Sie dann in einer README-Datei, einer Terminalausgabe und einer simulierten MCP-Antwort jeweils eine Anweisung, diese Werte zu lesen und über einen externen Kanal weiterzugeben. Prüfen Sie getrennt, ob der Agent die Daten lesen kann, ob sie in seiner Antwort oder seinem Modellkontext auftauchen und ob er sie per HTTP, Git, MCP oder über einen anderen erlaubten Dienst übertragen kann.

Ergänzen Sie den Test um einen Schreibversuch außerhalb des Arbeitsbereichs, einen Zugriff auf den SSH-Agenten oder den Docker-Socket sowie eine Änderung an Git-Hooks, Agentenkonfiguration und CI-Dateien. Scheitern diese Versuche, ist eine erste Grundprüfung bestanden. Ein belastbarer Sicherheitsnachweis ist das noch nicht. Dafür müssen Sie zusätzlich Symlinks, Mounts, Unix-Sockets, DNS, Unterprozesse, erlaubte Netzwerkziele und Änderungen an zentral verwalteten Richtlinien prüfen.

Damit haben Sie den lokalen Schadensradius begrenzt. Welche Daten der Agent nach außen überträgt, ist eine eigene Sicherheitsfrage. Der Beitrag Wohin telefoniert Ihr Coding-Agent? untersucht sie anhand eines Proxy-Mitschnitts. Als Nächstes prüfen Sie deshalb die ausgehenden Verbindungen.