Was eine Agenten-Sandbox wirklich einsperrt — und was nicht

Prompt Injection ist das Sicherheitsproblem, das bei AI-Agenten bleibt: Fremder Inhalt — eine Webseite, eine E-Mail, ein Dokument — schiebt der AI Anweisungen unter, und irgendein Versuch kommt irgendwann durch. Der Blick geht dabei fast immer nur auf das LLM: welches Modell, wie robust gegen Manipulation. Dabei ist der Harness die wichtigere Ebene — die Struktur aus Sandbox, Netz-Kontrollen und Freigaben, in der das Modell arbeitet. War eine Injection erfolgreich, schützt das Modell nicht mehr; dann schützt nur noch der Harness.

Um zu verstehen, was dort wirklich schützt, habe ich den Claude-Harness von innen untersucht: Cowork, Claude Code und die Cloud-Sessions, aus der Sandbox heraus, in der so ein Agent seinen Code ausführt — statt aus Marketing-Folien.

Urteil vorweg: eine extrem starke technische Architektur, durchdachter als das meiste, was ich in Enterprise-Umgebungen an Eigenbau sehe. Genau deshalb taugt sie als Blaupause: An einer starken Struktur sieht man, welche Schutzschicht wogegen hilft; an einer schwachen nur, dass etwas fehlt.

Das Titelbild zeigt eine Cowork-Cloud-Session; Claude Code funktioniert anders und bekommt unten sein eigenes Bild. Der Text hat zwei Teile: die Kurzfassung für Entscheider, danach die Mechanik als vier Tests, jeder mit dem Kommando, das ihn belegt.

Management Summary

Was ich gemacht habe, in einem Satz: die Schutzschichten einzeln angefasst — nicht gelesen, was sie versprechen, sondern geprüft, was sie tun. Die Leitfrage: Welche davon stoppt eine hereingelegte AI tatsächlich?

So ist das Ganze aufgebaut. Cowork und Claude Code teilen sich den Kern, aber nicht die Grenzen — die wichtigste Unterscheidung im ganzen Text.

Cowork kapselt ausgeführten Code immer in einer eigenen virtuellen Maschine. Standardmäßig läuft die Sitzung in der Cloud: Denken und Code-Ausführung auf Anthropic-Servern, in einer Wegwerf-VM pro Sitzung. An den eigenen Rechner kommt sie nur über die Desktop-App — nur in freigegebene Ordner, nur solange die App offen ist; Kommandos auf dem Gerät laufen wieder in einer eigenen lokalen VM, nicht im Betriebssystem. Die lokale Variante behält beides auf dem Gerät.

Claude Code, das Entwickler-Werkzeug fürs Terminal, arbeitet ohne VM direkt auf dem Rechner. Gesandboxt sind nur die Shell-Kommandos; das Programm selbst, seine Datei-Zugriffe und alle angebundenen Zusatz-Werkzeuge laufen ungeschützt, und lesen darf es standardmäßig fast alles. Die Cloud-Variante steckt dagegen komplett in einer Anthropic-VM — dort ist meine Untersuchung entstanden.

Quer durch beide Produkte gibt es zwei Arten von Schutz. Guardrails, die halten, egal ob sich die AI vernünftig verhält: freigegebene Ordner, freigeschaltete Netz-Ziele, Zugangsdaten außer Reichweite, Löschen nur mit Zustimmung — nachgeprüft, sie haben gehalten. Und Urteilsvermögen, das einschätzt: Der Modus „Automatisch genehmigen" ist eine zweite AI, die jede Aktion bewertet — meist klüger als manuelles Durchklicken, aber eine Einschätzung, keine Garantie. Wer beides verwechselt, sichert das Falsche ab.

Gegen Prompt Injection trägt deshalb nur eine Antwort: Man verhindert nicht zuverlässig, dass die AI hereingelegt wird — man baut so, dass eine hereingelegte AI nichts anrichten kann. Das leisten die Guardrails, und genau so ist dieser Harness gebaut.

Zwei Dinge noch für den Rollout. Cloud-Sitzung heißt Cloud-Verarbeitung: Der freigegebene Ordner begrenzt, was der Agent sieht, nicht, wo Inhalte landen — wer Daten im Haus halten muss, braucht die lokale Ausführung. Und: Die Liste erlaubter Netz-Ziele gilt nur für den ausgeführten Code. Die Lese-Wege der AI — Websuche, angebundene Dienste — laufen serverseitig und werden in den Organisations-Einstellungen gesteuert. Zwei Kanäle, zwei Stellschrauben; wer beides mit einer Liste erledigt glaubt, hat eine offen.

Das reicht als Entscheidungsgrundlage. Der Rest zeigt, wie ich zu diesen Aussagen komme.

Ab hier wird es technisch — und ehrlich gesagt liest das kaum jemand

Kein Vorwurf: Die Zusammenfassung oben trägt die Entscheidung, dafür muss man den Rest nicht kennen. Wer weiterliest, sieht, woran ich „untersucht" von „geglaubt" unterscheide, Kommando für Kommando. Über die paar, die bleiben, freue ich mich ehrlich.

Cowork und Claude Code — gleiche Engine, andere Grenzen

Vor den Tests die Abgrenzung, ohne die man sie falsch einordnet. Das Titelbild zeigt Cowork: Ausführung immer in einer VM, in der Cloud oder lokal per Hypervisor; die Desktop-App ist der einzige, consent-pflichtige Weg zu lokalen Dateien. Claude Code sieht anders aus:

Die CLI hat keine VM. Ihre Sandbox — Seatbelt auf macOS, bubblewrap auf Linux — umfasst nur Bash-Kommandos samt Kindprozessen. Der Agent-Prozess mit den Datei-Tools läuft außerhalb, MCP-Server und Hooks laufen mit vollen Nutzerrechten auf dem Host, der Lese-Default ist der ganze Rechner minus Deny-Pfade. Fehlt bubblewrap, läuft die CLI ungesandboxt weiter und warnt nur — sandbox.failIfUnavailable: true gehört in jedes ernsthafte Deployment, und unbeaufsichtigte Läufe bekommen eine eigene Grenze: Container, VM oder Anthropics Sandbox-Runtime srt.

Die Cloud-Sessions beider Produkte sehen gleich aus: Agent-Loop und Ausführung zusammen in einer Anthropic-VM. Dort lief meine Untersuchung — Engine 2.1.245, ein Tag, eine Region. Belastbare Beobachtungen, keine Produktzusagen; die Kommandos stehen dabei zum Gegenprüfen.

Test 1 — Was ist die Sandbox überhaupt?

Umgebung: Cloud-Session, Ausführung in der Sandbox. Frage: Worin läuft mein Code?

Die Doku sagt „isolierte, temporäre Sandbox" und lässt offen, was das technisch ist. Von innen ist es auslesbar:

Linux version 6.18.44-fc-v21 (builder@sandboxing)
Command line: ... rdinit=/process_api -- --firecracker-init
              --block-local-connections --listen-vsock-port 2024
Hypervisor detected: KVM
ACPI: XSDT ... (v01 FIRECK FCMVXSDT ...)

Das ist eine Firecracker-microVM auf KVM: eigener Kernel-Build, Firecrackers ACPI-Kennung FIRECK, und als erster Prozess kein Init-System, sondern ein Control-Plane-Binary am vsock-Kanal zum Host. Kein Docker, kein systemd, keine Overlay-Dateisysteme. Agent, Skills und Runner kommen als versionierte, schreibgeschützte Block-Devices in die VM — Immutable Infrastructure auf Sandbox-Ebene: Der Softwarestand ist am Hash festgenagelt und von innen nicht manipulierbar.

Was der Test belegt: eine echte Virtualisierungsgrenze, kein geteilter Container-Kernel. Was er nicht belegt: dass das überall so ist — Anthropic dokumentiert Firecracker für die eigenen Sandboxes nirgends, und die Proxy-CA nennt sich selbst staging. Eine belastbare Einzelbeobachtung, mehr nicht. Diese Grenze zwischen „untersucht" und „bewiesen" muss man ziehen, sonst verkauft man eine Vermutung als Plattform-Zusage.

Test 2 — Kommt der Code nach draußen?

Umgebung: Sandbox mit Netzwerkzugriff. Frage: Was darf raus, und wie streng?

Der Egress hat zwei Ebenen. In der VM ein Proxy auf 127.0.0.1, verdrahtet über HTTPS_PROXY und rund zwei Dutzend toolchain-spezifische Varianten, mit Diagnose-Endpunkt für abgewiesene Verbindungen. Dahinter ein Policy-Gateway, das TLS aufbricht — eine eingespielte CA (CN = CCR Upstream Proxy CA) macht das für jedes Werkzeug zwingend. Gefiltert wird also nicht nur nach Hostname, sondern im Klartext. Das ist der Gegenentwurf zu Claude Code lokal, wo TLS per Default nicht terminiert wird: Die Flanke ist zu, um den Preis, dass Anthropic den Klartext sieht.

Das Aufbrechen hat einen Zweck: Credential-Injection. In der VM stehen Zugangsdaten nur als Platzhalter.

env | grep -E 'TOKEN|ACCESS_KEY'
GH_TOKEN=proxy-injected
AWS_ACCESS_KEY_ID=proxy-injected
AWS_SECRET_ACCESS_KEY=proxy-injected

Echte Credentials existieren in der Sandbox nie; das Gateway setzt sie beim Verlassen ein, inklusive Neu-Signieren von AWS-Requests, weil die Signatur nach dem Ersetzen sonst bräche. Wer die Sandbox kompromittiert, findet keine Schlüssel, weil keine da sind. Die Wirkung, direkt getestet:

curl -w '%{http_code}' docs.claude.com      → 301   (allowlisted)
curl -w '%{http_code}' example.com          → 403   (Policy verweigert)
curl -w '%{http_code}' support.claude.com    → 403   (selbst Anthropic-Subdomains)
curl 169.254.169.254 --noproxy '*'          → 403   (Metadata-Endpoint, transparent geblockt)

Die letzte Zeile zählt: Auch am Proxy vorbei bleibt der Cloud-Metadata-Endpoint zu. Der Intercept ist transparent, die Umgebungsvariablen sind Komfort. So gehört das gebaut — die Grenze hängt nicht daran, dass sich der Code brav an eine Konfiguration hält.

Test 3 — Wofür die Allowlist gilt, und wofür nicht

Umgebung: dieselbe Session. Frage: Deckt der Egress-Filter alles ab, was die AI mit dem Netz macht?

Nein, und zwar absichtlich. support.claude.com war für curl 403; denselben Artikel hat das WebFetch-Werkzeug Sekunden später geliefert. Keine Lücke, sondern Aufbau: WebFetch, WebSearch und MCP-Connector-Traffic laufen serverseitig bei Anthropic, nicht in der Sandbox — die Doku sagt das ausdrücklich. Die Asymmetrie ergibt Sinn: Diese Wege lesen in erster Linie, der Egress-Filter kontrolliert das Senden aus der Sandbox — den Kanal, über den gestohlene Daten abfließen würden.

Festhalten muss man die Governance-Konsequenz: Die Allowlist regelt den Code-Kanal. Was Connectors lesen und wohin sie schreiben dürfen, steuern die Org-Einstellungen. Zwei Kanäle, zwei Stellschrauben — ein Review, das nur die Allowlist prüft, hat den zweiten nicht angeschaut.

Test 4 — Ist „Automatisch genehmigen" eine Kontrolle?

Umgebung: dieselbe Session, Blick auf die Konfiguration. Frage: Was passiert technisch, wenn ich Aktionen automatisch freigeben lasse?

In der Session stehen drei Umgebungsvariablen mit der Policy des Auto-Modus — kein Regelwerk, sondern Fließtext für ein Classifier-Modell: blockiere Ordner-Anfragen, wenn der Pfad breiter ist als das, worauf der Nutzer sich bezog, oder wenn er zuerst in Datei- oder Web-Inhalt auftauchte statt in einer Nutzer-Nachricht; bewerte den Prompt geplanter Aufgaben „wie eine Sub-Agent-Delegation", weil er unbeaufsichtigt läuft.

Durchdachte Policy — aber eine Bewertung, kein fester Kontrollpunkt. Anthropics eigene Zahl: rund 0,1 % Injection-Erfolg pro Einzelversuch, 5 bis 6 % nach hundert adaptiven Versuchen. Ein Angreifer versucht es hundertmal.

Dass der Auto-Modus trotzdem meist die richtige Voreinstellung ist, hat Anthropic gut begründet: Wer jede Aktion einzeln freigibt, klickt nach dem zehnten Dialog reflexhaft — der Classifier prüft auch die hundertste aufmerksam. An der Kategorie ändert das nichts: beides Urteilsvermögen, keine Garantie. Was unabhängig davon hält, ist die Umgebung: Egress-Gateway, Ordner-Scope, Lösch-Prompt, MDM-Keys. Erst einsperren, dann steuern — nie die Steuerung mit der Grenze verwechseln.

Der Weg von der Cloud auf das Gerät

Ein letzter Punkt, weil er die häufigste Verwechslung auflöst. Eine Cloud-Session erreicht lokale Dateien nur über die Anthropic-vermittelte Verbindung zur Desktop-App, und nur solange die App offen ist. In der Session ist das ein Werkzeug-Vertrag: Verzeichnisse lesen, Dateien hochladen und zurückschreiben (mit Zeitstempel-Prüfung gegen das Überschreiben neuerer Änderungen), dazu eine Shell in der lokalen VM des Desktops, nicht im Host-Betriebssystem. Löschen braucht einen eigenen Zustimmungs-Flow, sonst scheitert rm mit „Operation not permitted".

Die Bau-Regel daraus: Arbeit an Nutzerdateien passiert dort, wo sie liegen — per Shell in der lokalen VM. Jeder Transfer kostet Sekunden und Tokens und erzeugt eine zweite Kopie, die driften kann; er lohnt nur, wenn die Cloud etwas kann, was das Gerät nicht kann.

Was daraus folgt

Nebeneinandergelegt ergeben die vier Tests mehr als das Urteil, dass hier jemand sauber gebaut hat — sie ergeben ein Prinzip: Eine Struktur ist genau so sicher wie ihre deterministische Ebene, der Teil, der hält, egal was das Modell tut. Alles, was auf einer Bewertung beruht, ist Steuerung — nützlich, um Wahrscheinlichkeiten zu verschieben, wertlos als Zusage.

Die Konsequenzen stehen oben in der Kurzfassung; der Wert steckt im Verfahren: nicht der Doku glauben, sondern die Grenze anfassen. Jede Kontrolle deckt genau den Kanal ab, für den sie gebaut ist — welcher das ist, steht selten in der Marketing-Zusammenfassung und immer in einem Kommando, das man selbst absetzt.

Diese Trennung — Containment in der Umgebung zuerst, Verhaltenssteuerung im Modell danach — ist die Arbeit, die ich in regulierten Umgebungen und beim Aufsetzen von Agenten-Guardrails mache. Die Werkzeuge ändern sich im Quartalstakt, das Prinzip nicht.