Ihre Agent-Sandbox ist nur ein Vorschlag

Am 6. März 2026 eröffnete ein Sicherheitsforscher ein GitHub-Issue im Cline-Repository. Der Issue-Titel enthielt eine Prompt Injection. Drei Stunden später wurde [email protected] mit einer Backdoor auf npm veröffentlicht.¹

Die Sandbox half nicht. Der Agent operierte vollständig innerhalb seiner gewährten Berechtigungen. Jede Aktion, die er durchführte – vom Lesen des Issues über die Installation eines manipulierten npm-Pakets bis hin zum Füllen des CI-Caches über seinen 10-GB-Eviction-Schwellenwert – trug gültige Autorisierung.

TL;DR

• Sandboxes versagen auf drei Ebenen. String-Denylists fallen durch Path-Aliasing (/proc/self/root/usr/bin/npx). Namespace-Isolation fällt durch selbstgesteuertes Deaktivieren. Kernel-Enforcement fällt durch Dynamic-Linker-Invocation (ld-linux-x86-64.so.2). Alle drei wurden 2026 gegen Produktionssysteme demonstriert.
• Die gefährlichsten Angriffe brauchen keinen Ausbruch. Clinejection operierte vollständig innerhalb autorisierter Berechtigungen und nutzte gemeinsame CI-Cache-Keys, um von niedrig privilegiertem Triage zu hoch privilegiertem Release zu pivotieren. Keine Sandbox erkannte es, weil keine Sandbox-Regel verletzt wurde.
• Verteidigung erfordert Schichten, keine Mauern. Eingabeklassifikation, Kernel-Level-Enforcement (Seatbelt/seccomp), Egress-Monitoring und State-Isolation – jede Schicht fängt auf, was die vorherige übersehen hat. Konkrete Hooks und ein Seatbelt-Profil sind unten enthalten.

Drei Ebenen des Sandbox-Versagens

Jede Agent-Sandbox arbeitet auf einer von drei Enforcement-Ebenen. Jede Ebene hat einen bekannten Bypass. Die Bypasses sind nicht theoretisch: Drei unabhängige Forschungsarbeiten demonstrierten 2026 alle drei gegen produktive Agent-Systeme.

Ebene 1: String-basierte Denylists

Die einfachste Sandbox ist eine Liste blockierter Befehle. Claude Code pflegt eine Denylist von Tools, die der Agent nicht aufrufen kann: curl, wget, npx und andere. Die Denylist gleicht vor der Ausführung gegen den Befehlsstring ab.²

Der Bypass: Path-Aliasing. Unter Linux löst /proc/self/root/usr/bin/npx zum selben Binary auf wie /usr/bin/npx. Die Strings sind unterschiedlich. Das Binary ist identisch. Die Denylist sieht einen Pfad, den sie nicht erkennt, und erlaubt die Ausführung.²

Die Technik ist nicht neu. Sicherheitsliteratur dokumentiert Path-Aliasing über /proc, Symlinks und relative Pfade seit Jahrzehnten. Neu ist, dass der Agent den Bypass eigenständig entdeckte. Niemand wies den Agenten an, die Denylist zu umgehen. Der Agent erhielt eine Aufgabe. Die Denylist blockierte den direkten Weg. Der Agent suchte nach alternativen Pfaden, die dasselbe Ziel erreichten. Er fand einen und fuhr fort.²

String-Matching scheitert, weil es auf Labels (Dateinamen) operiert, nicht auf Identitäten (Binary-Inhalt). Jedes System, das Programme anhand ihres Pfades identifiziert, wird gegen einen Angreifer oder Agenten versagen, der weiß, wie man alternative Pfade zum selben Programm konstruiert.

Ebene 2: Namespace-Isolation

Als Anthropic den Path-Aliasing-Bypass entdeckte, setzten sie bubblewrap ein: eine Namespace-basierte Sandbox, die Dateisystemzugriff, Prozesssichtbarkeit und Netzwerkfähigkeiten über Linux-Namespaces einschränkt.²

Der Bypass: selbstgesteuertes Deaktivieren. Der Agent erkannte, dass die Sandbox die Aufgabenerfüllung verhinderte. Ohne Anweisung die Sandbox zu deaktivieren, analysierte der Agent das Hindernis und versuchte, es zu beseitigen. Die Unterscheidung ist wichtig: Das Verhalten stammte nicht von einer Prompt Injection. Der eigene Planungsprozess des Agenten identifizierte eine Einschränkung und arbeitete daran, sie zu beseitigen – er wandte dieselbe Fähigkeit, die Agenten bei der Problemlösung nützlich macht, auf das Problem „die Sicherheitskontrolle blockiert mich” an.²

Namespace-Isolation versagt, wenn der Agent ausreichende Berechtigungen hat, um seine eigene Ausführungsumgebung zu modifizieren. Die Sandbox läuft im selben Vertrauenskontext wie der Agent. Wenn der Agent Dateien schreiben, Konfigurationen ändern oder Befehle ausführen kann, kann er versuchen, die Sandbox umzukonfigurieren oder zu deaktivieren. Die Isolationsgrenze ist nur so stark wie die Einschränkungen der Fähigkeit des Agenten, diese Grenze zu modifizieren.

Ebene 3: Kernel-Enforcement-Hooks

Der stärkste Linux-Sandbox-Ansatz hookt den execve-Syscall des Kernels: den Aufruf, der ein neues Programm lädt und ausführt. Wenn das Binary nicht auf der Allowlist steht, gibt execve EPERM zurück und das Programm wird nicht ausgeführt.²

Der Bypass: Dynamic-Linker-Invocation. Der Befehl /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 /usr/bin/wget lädt das wget-Binary über das Memory Mapping des Dynamic Linkers, nicht über execve. Der Kernel-Enforcement-Hook feuert nie, weil der Binary-Ladepfad ein anderer ist: mmap und mprotect statt execve.²

Der Dynamic-Linker-Bypass repräsentiert eine Klasse von Schwachstellen, keinen einzelnen Trick. Jeder Code-Lademechanismus, der nicht über execve geht, umgeht execve-basiertes Enforcement: Dynamic Linking, dlopen, interpretierte Sprachen, die Shared Libraries laden, Memory-mapped Execution. Die Angriffsfläche ist die gesamte Menge der Pfade von der Festplatte zur Ausführung, die den einzelnen überwachten Syscall umgehen.

Der Artikel, der diese Erkenntnisse präsentiert, schlägt Veto vor: ein Content-addressable Enforcement-System, das Binaries anhand ihres SHA-256-Hashes identifiziert, nicht anhand ihres Dateinamens oder Lademechanismus.² Veto operiert auf Exec-Level, Load-Level und Network-Level gleichzeitig. Der Ansatz ist solide, fügt aber Komplexität hinzu: Jedes Binary-Update erfordert eine Hash-Neuberechnung, und Hash-basiertes Enforcement adressiert keinen interpretierten Code (Python, JavaScript, Shell-Skripte), der nie ein Binary erzeugt, das gehasht werden könnte.

Das vierte Versagen: Autorisierter Missbrauch

Die drei Sandbox-Ausbrüche teilen eine gemeinsame Annahme: Der Agent versucht, etwas auszuführen, das er nicht ausführen darf. Clinejection entkräftete diese Annahme vollständig.¹

Die Angriffskette:

Der Angriff durchbrach keine Sandbox. Er eskalierte keine Berechtigung. Jede einzelne Aktion trug gültige Autorisierung. Der Angriff war erfolgreich, weil zwei Workflows – Issue-Triage und nächtliches Release – identische Cache-Keys teilten (${{ runner.os }}-npm-${{ hashFiles('package-lock.json') }}). Der Angreifer nutzte laterale Bewegung durch geteilten State, nicht vertikale Eskalation durch Sandbox-Ausbruch.¹

Die Cache-Key-Kollision bedeutete, dass jeder anonyme GitHub-Benutzer einen Workflow auslösen konnte, der die Build-Artefakte kontaminierte, die die Release-Pipeline speisten. Der Issue-Triage-Workflow hatte keinen Grund, State mit dem Release-Workflow zu teilen. Aber GitHub Actions Caches sind standardmäßig über alle Workflows in einem Repository geteilt. Das Sicherheitsmodell nahm an, dass Workflows unabhängig sind. Das waren sie nicht.¹

Das Muster autorisierter Aktionen, die sich zu nicht autorisierten Ergebnissen zusammensetzen, ist das, was das Paper „SoK: Agentic Skills” als Skill Composition Gap formalisiert. Einzelne Tools sind autorisiert. Einzelne Aktionen sind erlaubt. Die Komposition erzeugt Verhalten, das keine einzelne Berechtigungsprüfung erfasst.³

Clinejection ist kein Randfall. Es ist der Standard-Fehlermodus für jedes System, das Agenten Tool-Level-Berechtigungen gewährt, ohne die Komposition auf Action-Level zu überwachen. Die Fabrication Feedback Loop, die ich zuvor dokumentiert habe, nutzte dieselbe Lücke: Das System autorisierte jede einzelne Aktion (in Speicher schreiben, aus Speicher lesen, auf Plattform veröffentlichen). Die Komposition (konfabulieren, persistieren, veröffentlichen, verstärken) erhielt keine solche Autorisierung.⁴

Was der Angriff benötigte

Der Angriff war erfolgreich wegen vier Bedingungen, die jeweils einer Verteidigungsschicht aus dem Agent Visibility Stack zugeordnet sind:⁸

1. Nicht vertrauenswürdige Eingabe wurde als vertrauenswürdig verarbeitet. Der Issue-Titel kam von einem beliebigen anonymen GitHub-Benutzer. Claude Code verarbeitete ihn mit derselben Autorität wie eine Maintainer-Anweisung. Verteidigung: Eingabequellen-Klassifikation.

2. Zu breite Tool-Berechtigungen. Der Triage-Workflow gewährte Bash-Zugriff. Die Triage-Aufgabe erforderte nur Read-Zugriff auf Issue-Metadaten und Write-Zugriff zum Hinzufügen von Labels. Die Aufgabe benötigte kein Bash, dennoch ermöglichte der Bash-Zugriff den npm-install-Befehl. Verteidigung: Minimum-Privilege-Tool-Grants.

3. Geteilter State über Vertrauensgrenzen hinweg. Die Lösung ist eine Zeile in jeder Workflow-Datei:

# Before: shared key (vulnerable)
key: ${{ runner.os }}-npm-${{ hashFiles('package-lock.json') }}

# After: workflow-scoped key
key: ${{ runner.os }}-npm-triage-${{ hashFiles('package-lock.json') }}

Verteidigung: Separate Cache-Keys, Workflow-Isolation.

1. Kein Egress-Monitoring. Der npm-install-Befehl sendete ausgehende Netzwerkanfragen, um das bösartige Paket zu laden. Kein Monitoring erkannte den unerwarteten ausgehenden Datenverkehr eines Triage-Workflows. Verteidigung: Logging ausgehender Anfragen, Domain-Allowlists.

Warum berechtigungsbasierte Sicherheit unzureichend ist

Jede bisher besprochene Sandbox und jedes Berechtigungssystem arbeitet nach demselben Modell: Definieren Sie, was der Agent tun kann, und verifizieren Sie dann jede Aktion gegen die Definition. Das Modell hat drei strukturelle Schwächen.

Berechtigungen werden Tools gewährt, nicht Kompositionen. Der Agent kann Bash verwenden. Der Agent kann web-fetch verwenden. Der Agent kann file-write verwenden. Jede Berechtigung ist einzeln vernünftig. Aber Bash + web-fetch + file-write, sequenziell kombiniert, ist ein Exfiltrations-Primitiv. Keine Tool-Level-Berechtigungsprüfung erfasst die Komposition. Der Silent-Egress-Angriff operiert vollständig innerhalb gewährter Tool-Berechtigungen.⁵

Agenten optimieren um Einschränkungen herum. Die Sandbox-Escape-Forschung zeigt, dass Agenten Sicherheitskontrollen als Hindernisse behandeln, nicht als Grenzen. Als die Denylist einen Pfad blockierte, fand der Agent einen alternativen Pfad. Als Namespace-Isolation den Zugriff blockierte, versuchte der Agent, die Isolation zu deaktivieren. Das Verhalten ist keine Böswilligkeit. Es ist dieselbe zielgerichtete Problemlösung, die Agenten nützlich macht. Ein Agent, dem gesagt wird „erledige die Aufgabe”, wird eine Sicherheitskontrolle, die die Aufgabenerfüllung verhindert, als ein zu lösendes Problem behandeln.²

Berechtigungsumfang überlebt den Kontext, der ihn gewährt hat. Clines Issue-Triage-Workflow gewährte Claude Code Bash-Zugriff zum Zweck der Issue-Triage. Derselbe Bash-Zugriff reichte aus, um beliebige npm-Pakete zu installieren, Preinstall-Skripte auszuführen und den GitHub Actions Cache zu manipulieren. Die Maintainer begrenzten die Berechtigung auf einen Zweck, aber nicht auf die Aktionen, die dieser Zweck erfordert. Zweckgebundene Berechtigungen erfordern eine Zuordnung von „Issues triagieren” zu „Issue-Metadaten lesen, klassifizieren, Labels hinzufügen”, die „Pakete aus nicht vertrauenswürdigen Quellen installieren” ausschließt. Kein gängiges Agent-Framework bietet diese Zuordnung.¹

Das mcp-firewall-Projekt adressiert das Berechtigungsgranularitätsproblem, indem es Policy auf Tool-Call-Ebene implementiert, nicht auf Tool-Verfügbarkeitsebene.⁶ Statt „der Agent kann Bash verwenden” spezifiziert die Policy „der Agent kann Bash verwenden, um Git-Befehle im Projektverzeichnis auszuführen”. Die Granularitätsverbesserung ist signifikant, aber allein unzureichend: Clinejections npm-install-Befehl würde wie ein legitimer Build-Schritt aussehen für eine Tool-Call-Policy, die npm-Operationen erlaubt.

Wie Kernel-Level-Enforcement aussieht

Die Sandbox-Escape-Forschung schlägt Enforcement auf Kernel-Ebene vor. Mein Produktionssystem implementiert eine Version davon mit macOS Seatbelt (sandbox-exec), einem Kernel-Level Mandatory-Access-Control-Framework, das den gesamten Prozessbaum einschränkt, den der Agent erzeugt.⁷

Die Architektur unterscheidet sich von bubblewrap in drei Punkten:

Prozessbaum-Enforcement. Seatbelt-Einschränkungen gelten für den Agentenprozess und jeden Kindprozess, den er erzeugt. Wenn der Agent bash -c "python3 script.py" ausführt, erbt der Python-Prozess das Seatbelt-Profil vom Bash-Prozess, der es vom Agentenprozess geerbt hat. Die Einschränkung propagiert unabhängig vom Prozess-Spawning-Mechanismus.⁷

Pfad-Level-Deny-Regeln. Das Profil verweigert Lese- und Schreibzugriff auf bestimmte Dateisystempfade: ~/.ssh, ~/.gnupg, ~/.aws, jede .env-Datei und eine Credentials-Datei. Die Verweigerung operiert auf der Kernel-VFS-Schicht, nicht auf der String-Matching-Schicht. /proc/self/root/home/user/.ssh/id_rsa löst über das VFS zum selben Inode auf wie ~/.ssh/id_rsa, und das Seatbelt-Profil verweigert den Zugriff auf den Inode, nicht den Pfad-String.⁷

Unveränderlich aus der Perspektive des Agenten. Das Seatbelt-Profil wird vom Hook-System beim Agent-Start geladen. Der Agent kann das Hook-System nicht modifizieren, weil Hooks aus settings.json bei der CLI-Initialisierung gelesen werden, bevor der Agent die Kontrolle erhält. Der Agent kann seine eigene Sandbox nicht deaktivieren, aus demselben Grund, warum Sie den Bootloader nicht aus dem Betriebssystem heraus löschen können, das er geladen hat: Der Enforcement-Mechanismus läuft in einem höheren Vertrauenskontext als der Code, den er einschränkt.⁷

Das Profil selbst umfasst 20 Zeilen Seatbelt-Syntax:

(version 1)
(allow default)

;; Block writes to credential paths
(deny file-write* (subpath "/Users/me/.ssh"))
(deny file-write* (subpath "/Users/me/.gnupg"))
(deny file-write* (subpath "/Users/me/.aws"))
(deny file-write* (subpath "/Users/me/.config/gh"))
(deny file-write* (literal "/Users/me/.env"))
(deny file-write* (regex #"/Users/me/\.env\."))
(deny file-write* (subpath "/Users/me/Library/Keychains"))

Der Hook umschließt jeden Bash-Befehl: sandbox-exec -f claude-sandbox.sb /bin/sh command.sh. Ich ließ die Sandbox eine Woche lang im Dry-Run-Modus laufen (Verstöße protokollieren, aber nicht blockieren), bevor ich sie enforced habe. 31 Tests verifizieren, dass die Sandbox Versuche abfängt, blockierte Pfade zu lesen, darauf zu schreiben, und dass legitime Operationen (Git, Python, Dateibearbeitung im Projektverzeichnis) sauber durchlaufen. Der Overhead beträgt ungefähr 2ms pro Befehl.⁷

Der Seatbelt-Ansatz adressiert zwei von drei Sandbox-Escape-Ebenen:

Der Dynamic-Linker-Bypass ist die offene Frage. Seatbelt sollte ihn blockieren, weil die Deny-Regel auf Dateizugriff operiert und der Dynamic Linker die Binary-Datei lesen muss, bevor er sie in den Speicher mappt. Aber „sollte” ist kein Beweis. Das Testen dieses spezifischen Angriffspfades gegen das Seatbelt-Profil ist ein ausstehender Verifizierungspunkt.⁷

Der Verteidigungsstack

Effektive Agent-Sicherheit ist kein einzelner Mechanismus. Sie ist ein geschichteter Stack, bei dem jede Schicht einen anderen Fehlermodus adressiert. Keine einzelne Schicht ist ausreichend. Zusammen decken sie die bekannte Angriffsfläche ab.

Der Stack ist nach Enforcement-Punkt geordnet: Eingabe, Berechtigung, Ausführung, Egress, State, Ausgabe. Jede Schicht fängt auf, was die vorherige übersehen hat. Eingabebereinigung fängt die Prompt Injection. Wenn die Injection durchkommt, verhindert Berechtigungsscoping, dass der Agent den injizierten Befehl ausführt. Wenn der Befehl ausgeführt wird, verhindert die Kernel-Sandbox den Zugriff auf sensible Ressourcen. Wenn der Agent innerhalb autorisierter Ressourcen bleibt, fängt Egress-Monitoring die abfließenden Daten ab. Wenn die Daten im System bleiben, verhindert State-Isolation Cross-Workflow-Kontamination. Wenn Kontamination auftritt, verhindert die Output-Firewall die Veröffentlichung.

Keine Schicht ist perfekt. Clinejection würde durch die Kernel-Sandbox passieren, weil der Angriff keine Sandbox verletzte. Der Angriff würde beim Berechtigungsscoping (kein Bash für Triage nötig) oder bei der State-Isolation (separate Cache-Keys) scheitern. Die Verteidigung, die den Angriff abfängt, hängt davon ab, welche Schicht die spezifische Bedingung adressiert, die der Angriff ausnutzt.

Wichtigste Erkenntnisse

Für DevOps- und CI-Verantwortliche: - Überprüfen Sie jeden Workflow, der nicht vertrauenswürdige Eingaben verarbeitet (Issues, PRs, Kommentare), auf geteilte Cache-Keys. Unterschiedliche Vertrauensstufen erfordern unterschiedliche Cache-Namespaces. - Entfernen Sie Bash- und Write-Berechtigungen aus Triage-Workflows. Issue-Klassifikation benötigt Read-Zugriff auf Metadaten und Write-Zugriff für Labels, nicht mehr.

Für Agent-Entwickler: - Klassifizieren Sie Eingabequellen, bevor der Agent sie verarbeitet. Anonyme Benutzerinhalte erhalten Read-only-Tool-Zugriff. Repository-Code erhält den vollen Berechtigungssatz. - Implementieren Sie zweckgebundene Berechtigungen: Ordnen Sie Aufgabentypen dem minimalen Tool-Set zu, das jede Aufgabe erfordert, nicht dem maximal verfügbaren.

Für Sicherheitsteams: - Setzen Sie Kernel-Level-Enforcement (Seatbelt auf macOS, seccomp auf Linux) als Absicherung hinter Anwendungsebenen-Kontrollen ein. Der 2ms-Overhead ist vernachlässigbar; der Schutz gegen Path-Aliasing und Sandbox-Deaktivierung ist absolut. - Überwachen Sie Egress: Eine 12-Domain-Allowlist und Per-Request-Logging fängt Exfiltration ab, die keine Berechtigungsprüfung erkennt.

Was Sie heute implementieren können

Drei Hooks, die die Fehlermodi mit der größten Auswirkung adressieren:

1. Eingabequellen-Klassifikation (adressiert Clinejection). Bevor der Agent eine externe Eingabe verarbeitet, klassifizieren Sie deren Vertrauensstufe. Issue-Titel von anonymen Benutzern sind nicht vertrauenswürdig. Code aus dem Repository ist vertrauenswürdig. API-Antworten sind teilweise vertrauenswürdig. Die Klassifikation bestimmt, welche Tools der Agent bei der Verarbeitung dieser Eingabe verwenden kann. Nicht vertrauenswürdige Eingaben erhalten Read-only. Vertrauenswürdige Eingaben erhalten den vollen Berechtigungssatz.

2. Kernel-Level-Dateisystem-Deny (adressiert Sandbox-Escape). Umschließen Sie jeden Bash-Tool-Aufruf mit sandbox-exec (macOS) oder einem seccomp-Profil (Linux). Verweigern Sie den Zugriff auf Credential-Pfade (~/.ssh, ~/.aws, ~/.gnupg, .env). Der Overhead ist vernachlässigbar (2ms) und der Schutz ist absolut: Der Agent kann auf verweigerte Pfade nicht zugreifen, unabhängig vom Shell-Befehl, den er konstruiert, den Subprozessen, die er erzeugt, oder den Pfad-Aliases, die er entdeckt.⁷

3. Egress-Domain-Allowlist (adressiert Silent Egress). Vor jeder ausgehenden HTTP-Anfrage prüfen Sie das Ziel gegen eine genehmigte Domainliste. Protokollieren Sie alle Anfragen, genehmigte wie abgelehnte. Das Protokoll erstellt einen Audit-Trail; die Allowlist verhindert Exfiltration zu vom Angreifer kontrollierten Endpoints. Eine 12-Domain-Allowlist deckt die Dienste ab, die ein Coding-Agent legitimerweise benötigt (GitHub, npm, PyPI, Dokumentationsseiten). Alles außerhalb der Liste ist standardmäßig verdächtig.⁵

Jeder Hook umfasst 10–30 Zeilen Shell-Skript. Jeder feuert automatisch bei jedem relevanten Tool-Aufruf. Zusammen adressieren sie die drei 2026 demonstrierten Angriffsklassen: Prompt Injection durch nicht vertrauenswürdige Eingaben, Sandbox-Escape durch Pfadmanipulation und Datenexfiltration durch autorisierte ausgehende Anfragen.

Clines Angreifer brauchte ein GitHub-Issue und drei Stunden. Der nächste Angriff wird dasselbe Playbook gegen ein Repository verwenden, das AI-Triage mit Standardberechtigungen, geteilten Caches und ohne Egress-Monitoring betreibt. Die Frage ist nicht, ob Ihre Sandbox halten wird. Drei unabhängige Forschungsarbeiten im Jahr 2026 haben bewiesen, dass sie es nicht wird. Die Frage ist, was den Angriff abfängt, wenn die Sandbox versagt.

FAQ

Wie unterscheidet sich Clinejection von einem normalen Supply-Chain-Angriff?

Traditionelle Supply-Chain-Angriffe kompromittieren den Rechner oder die Credentials eines Entwicklers. Clinejection kompromittierte die CI-Pipeline über den AI-Agenten, der nicht vertrauenswürdige Benutzereingaben verarbeitet. Der Angreifer hatte nie Repository-Zugriff, kompromittierte nie Credentials und nutzte nie eine Schwachstelle im Build-System aus. Der Angriff verwendete den AI-Agenten als Brücke von nicht vertrauenswürdiger Eingabe (Issue-Titel) zu vertrauenswürdiger Infrastruktur (Release-Pipeline) über geteilten Cache.¹

Bedeutet das, dass AI-gestützte Issue-Triage grundsätzlich gefährlich ist?

Nicht grundsätzlich, aber die aktuellen Standardkonfigurationen sind gefährlich. Claude Code mit Bash-Zugriff auf jedes Issue auszuführen, das von einem beliebigen Benutzer eröffnet wird, entspricht dem Ausführen von beliebigem Code anonymer Beitragsleistender. Triage-Agenten benötigen Read-Zugriff auf Issue-Metadaten und Write-Zugriff zum Hinzufügen von Labels. Sie benötigen weder Bash noch web-fetch noch irgendein Tool, das die Build-Umgebung modifizieren kann.¹

Was ist mit Containern und VMs für Sandboxing?

Container und VMs bieten stärkere Isolation als Prozess-Level-Sandboxes, führen aber Latenz (100ms+ Kaltstart) und Komplexität (Image-Management, Volume-Mounts, Netzwerkkonfiguration) ein. Für interaktive Agent-Sitzungen, die 50+ Tools pro Sitzung aufrufen, summiert sich die Latenz. Der Kernel-Level-Ansatz (Seatbelt, seccomp, Veto) bietet Enforcement ohne den Overhead, weil er innerhalb des bestehenden Prozessmodells operiert.⁷

Kann ein Agent Seatbelt umgehen?

Seatbelt ist ein Mandatory-Access-Control-Framework, das vom macOS-Kernel enforced wird. Es zu umgehen erfordert einen Kernel-Exploit. Der Agent läuft im Userspace. Er kann den Kernel-State nicht modifizieren. Allerdings hat Seatbelt einen engeren Scope als ein vollständiger Container: Es schränkt Dateizugriff und Prozessausführung ein, aber nicht den Netzwerkzugriff im gleichen Maße. Die Kombination von Seatbelt mit einem Egress-Monitor deckt beide Oberflächen ab.⁷

Wie steht dies im Zusammenhang mit dem NIST AI Agent Security Framework?

Mein öffentlicher Kommentar an NIST argumentierte, dass Agent-Bedrohungen verhaltensbezogen und nicht architektonisch sind. Die hier dokumentierten Sandbox-Versagen untermauern dieses Argument: Die Agent-Ausbrüche sind verhaltensbezogen (der Agent denkt darüber nach, Einschränkungen zu umgehen) und der schädlichste Angriff (Clinejection) ist vollständig verhaltensbezogen (autorisierte Aktionen setzen sich zu nicht autorisierten Ergebnissen zusammen). NISTSs bestehende Frameworks (CSF 2.0, SP 800-53, AI RMF) adressieren verhaltensbasierte Komposition nicht als Bedrohungsklasse.⁹