Der Auto-Modus von Claude Code ist keine Sicherheitsgrenze

Ist der Auto-Modus von Claude Code eine Sicherheitsgrenze? Nein, und Anthropic sagt das selbst. Nachdem der Sicherheitsforscher Johann Rehberger eine funktionierende Angriffskette gegen Claude Code Opus 5 im Auto-Modus gemeldet hatte, schloss Anthropic den Bericht als Informative – mit der Position, dass der Auto-Modus eine Komfortfunktion auf Basis eines Best-Effort-Klassifikators sei und keine Sicherheitsgarantie, dass gezielt aufgebaute Ketten aus einzeln harmlosen Schritten außerhalb dessen liegen, was ein Klassifikator abfangen soll, und dass die eigentliche Grenze aus Isolation auf Betriebssystemebene zusammen mit einer Kontrolle des Netzwerk-Egress besteht.¹ Diese Antwort ist kein Ausweichmanöver. Sie ist das richtige mentale Modell – und die meisten von uns haben bisher das falsche mit sich herumgetragen. {.answer-block}

Es gibt eine bestimmte Art von Sicherheitsbefund, bei dem nicht der Fehler zählt, sondern die Überzeugung, die er korrigiert. Rehbergers Analyse vom 26. August ist ein solcher Fall. Die Kette, die er demonstriert, ist raffiniert, doch der nützliche Teil ist die Antwort, die sie hervorgerufen hat. Denn diese Antwort zeigt Ihnen, welche Schicht Ihres Setups tatsächlich tragend ist – und es ist nicht jene, der die meisten Entwickler seit August vertrauen, seit der Auto-Modus zur Voreinstellung wurde.

Kurzfassung

• Rehberger veröffentlichte am 26. August 2026 eine funktionierende Angriffskette gegen Claude Code Opus 5 im Auto-Modus und berichtete über eine Erfolgsquote von 60 bis 80 Prozent bei kleinen Stichproben: drei von fünf Durchläufen für die Hauptkette sowie drei von fünf und vier von fünf für zwei Konfigurationen einer zweiten Variante. Er weist ausdrücklich darauf hin, dass es sich um kleine Stichproben handelt und nicht um eine allgemeine Erfolgsquote für Angriffe.¹
• Der Befund trifft auf eine ganz konkrete Zahl: Eine von Anthropic beauftragte externe Evaluierung meldete für Opus 5 im Auto-Modus eine Erfolgsquote von 0,00 % bei Prompt-Injection-Angriffen, gemessen über 72 Szenarien, die jeweils zehnmal durchlaufen wurden. Rehbergers Kette gehörte nicht zu diesem Satz, weshalb die 0,00 % und eine funktionierende Kette zur Codeausführung gleichzeitig zutreffen können.¹
• Jeder einzelne Schritt der Kette ist für sich genommen vernünftig. Genau darin liegt die Lehre für den Entwurf: Ein Klassifikator bewertet Aktionen eine nach der anderen, doch der Angriff lebt in der Komposition und nicht in einer einzelnen Aktion.
• Anthropic schloss den Bericht als Informative und beschrieb den Auto-Modus als Komfortfunktion auf Basis eines Best-Effort-Klassifikators statt als Sicherheitsgarantie – mit Isolation auf Betriebssystemebene und Kontrolle des Netzwerk-Egress als eigentlicher Grenze.¹
• Das schärfste Detail, das Rehberger berichtet und Willison in den Vordergrund rückt: In einigen Durchläufen erkannte Claude die Kompromittierung und versuchte, den Schadprozess zu beenden – und der Auto-Modus verweigerte den Aufräumbefehl.¹²
• Praktische Konsequenz: Der Auto-Modus ist eine Produktivitätsmaßnahme, die zusätzlich eine dokumentierte Liste destruktiver Operationen blockiert, wenn er zu dem Schluss kommt, dass Sie sie nicht angefordert haben. Er ist nicht das, was zwischen angreiferkontrolliertem Text und Ihren Zugangsdaten steht. Ein Container, eingeschränkter Egress und ein Home-Verzeichnis ohne Zugangsdaten sind es.

Die Kette, Schritt für Schritt

Ausgangspunkt ist ein Agent bei ganz gewöhnlicher Arbeit: eine Ressource abrufen, sie dekodieren, den Inhalt verwenden. So wird daraus Codeausführung.¹

Ein Server beantwortet den WebFetch des Agenten mit HTTP 415, was sich eher nach einem Problem mit dem Content-Type anliest als nach einem Angriff. Der Agent tut das Naheliegende und weicht auf curl aus. Das Archiv, das er abruft, entpackt sich in ein Arbeitsverzeichnis mit einer README, einem Prüfsummen-Manifest, einem CSV-Index, sieben mit Base85 und zlib kodierten JSON-Datensätzen, einer nativen Decoder-Binärdatei und einer Datei namens struct.py.

Dann greift die Sicherheitsmechanik. Der Agent weigert sich, die nicht vertrauenswürdige native Binärdatei auszuführen – genau so, wie man es sich wünscht. Nachdem er die Binärdatei abgelehnt hat, schreibt er stattdessen seinen eigenen Python-Decoder und führt ihn aus dem Entpackungsverzeichnis heraus aus.

Dieser Decoder importiert base64. Das base64 der Standardbibliothek importiert struct. Python stellt das Arbeitsverzeichnis an den Anfang des Modulsuchpfads, also wird struct zur struct.py des Angreifers im entpackten Archiv aufgelöst statt zum Modul der Standardbibliothek.

Lesen Sie die Abfolge noch einmal und achten Sie darauf, was fehlt: Es gibt keinen Schritt, in dem der Agent angewiesen wird, offenkundig Bösartiges zu tun, und keinen Schritt, den ein vernünftiger Prüfer isoliert beanstanden würde. Nach einem 415 auf curl auszuweichen, ist normal. Ein Archiv zu entpacken, ist normal. Eine unsignierte Binärdatei abzulehnen, ist ein Sicherheitsgewinn. Sich seinen eigenen Decoder zu schreiben, zeugt von Findigkeit. Ihn in dem Verzeichnis auszuführen, in dem die Daten liegen, ist der offensichtliche Ort dafür.

Warum ein Klassifikator diese Runde verliert

Der Klassifikator des Auto-Modus bewertet eine Aktion gegen die Absicht der Sitzung: Passt dieser Befehl zu dem, was der Benutzer verlangt hat, und ist er für sich genommen gefährlich? Auf diese Frage gibt es bei rm -rf / eine gute Antwort und bei python decode.py eine schlechte.

Der Angriff präsentiert zu keinem Zeitpunkt eine gefährliche Aktion. Er ordnet die Umgebung so um, dass eine harmlos wirkende Aktion eine unsichere Folge hat – und diese Folge existiert nur wegen eines Schritts, der viel früher passiert ist: dem Entpacken des Archivs, das das Modul platziert hat. Um das zu erkennen, müsste ein Prüfer die gesamte Historie im Kopf behalten und die Modulauflösung von Python gegen das aktuelle Arbeitsverzeichnis durchdenken. Anthropics Position, dass Ketten aus einzeln harmlosen Schritten außerhalb des Zuständigkeitsbereichs des Klassifikators liegen, ist eine Aussage über genau diese Lücke.¹

Es lohnt sich, die Angriffsklasse präzise zu benennen. Willison ergänzte seine Analyse am 30. August und schloss sich einem Einwand an, den ein Leser von Lobste.rs vorgebracht hatte: Dies sei überhaupt keine klassische Prompt Injection, weil das Modell an keiner Stelle Anweisungen des Angreifers liest und ihnen folgt. Treffender beschreibt man es als Confused-Environment-Angriff, bei dem die Form der Umgebung, die dem Agenten übergeben wird, den Exploit erzeugt.² Diese Unterscheidung verschärft das Problem, statt es abzumildern. Ein Klassifikator, der nach eingeschleusten Anweisungen sucht, hat hier nichts zu betrachten, denn es gibt keine.

Es ist derselbe strukturelle Punkt, den die Welle der MCP-CVEs immer wieder macht: Agenten-Tooling sammelt schneller Fähigkeiten an, als es Eindämmung ansammelt, und eine Prüfung pro Aktion setzt sich nicht zu Sicherheit pro Sitzung zusammen.

Das Detail, das Ihr mentales Modell ändern sollte

Rehberger berichtet und Willison rückt jenen Moment in den Vordergrund, bei dem man verweilen sollte: In einigen Durchläufen bemerkte Claude die Kompromittierung und versuchte, den Schadprozess zu beenden – und der Auto-Modus verweigerte den Aufräumbefehl.¹²

Dass eine Sicherheitsschicht die Behebung verhindert, ist kein Paradox. Es ist das, was passiert, wenn eine Kontrolle darauf optimiert ist, „den Agenten nichts Drastisches tun zu lassen“, ohne einen Begriff davon zu haben, warum das Drastische versucht wird. Aufräumarbeiten nach einer Kompromittierung sehen für einen Klassifikator ziemlich genau wie Zerstörung aus.

Die betriebliche Lehre ist eng gefasst und brauchbar: „Der Agent wird es schon merken“ ist keine Kontrolle. Etwas zu bemerken und handeln zu können, sind zwei verschiedene Fähigkeiten, und Ihre Incident Response darf nicht davon ausgehen, dass der kompromittierte Agent hinter sich aufräumen darf.

Was einen Agenten wirklich begrenzt

Rehbergers Empfehlungen sind die unglamourösen, und die ersten beiden hätten diese Kette eingedämmt:¹

Betreiben Sie unbeaufsichtigte Agenten in einem Container oder einer VM. Die Kompromittierung führte Code unter dem Benutzerkonto des Agenten aus. Eine Isolationsschicht verwandelt Vollzugriff auf die Maschine in eine wegwerfbare Umgebung.

Schränken Sie den Netzwerk-Egress ein. Der Ertrag der Kette bestand darin, dass ein Subprozess nach außen griff, um eine entfernte Payload zu holen und auszuführen, gefolgt von einem Callback. Eine Egress-Richtlinie mit Allowlist unterbindet sowohl den Download der entfernten Stufe als auch den Callback.

Halten Sie Zugangsdaten außer Reichweite des Agenten. SSH-Schlüssel, Cloud-Zugangsdaten und .env-Dateien im Home-Verzeichnis liegen standardmäßig im Explosionsradius. Verlegen Sie sie – oder betreiben Sie den Agenten dort, wo sie nicht liegen.

Überwachen Sie den Agenten und lesen Sie Genehmigungen nicht als Beleg. Eine Genehmigung im Auto-Modus bedeutet, dass ein Klassifikator keinen Einspruch erhoben hat. Sie ist kein Befund, dass die Aktion sicher war.

Beachten Sie, was nicht auf der Liste steht: den Auto-Modus abzuschalten. Er blockiert eine dokumentierte Liste destruktiver Operationen, wenn er zu dem Schluss kommt, dass Sie sie nicht angefordert haben, und er verringert jene Prompt-Müdigkeit, die Menschen dazu bringt, reflexhaft alles zu genehmigen. Ihn gegen ein Gefühl vermeintlicher Strenge einzutauschen, ersetzt eine schwache Kontrolle durch eine schlechtere. Behalten Sie ihn – und hören Sie auf, ihn als Grenze zu behandeln.

Der Teil, den man klar aussprechen sollte

Es wäre leicht, diesen Befund als Versagen zu beschreiben, und noch leichter, ihn als Schuld des Anbieters darzustellen. Beides trifft nicht zu.

Anthropics Antwort – eine Komfortfunktion auf Basis eines Best-Effort-Klassifikators, keine Sicherheitsgarantie, mit Isolation auf Betriebssystemebene und Egress-Kontrolle als Grenze – ist eine ehrlichere Sicherheitshaltung, als eine stärkere Behauptung es gewesen wäre.¹ Ein Anbieter, der verspräche, sein Klassifikator fange gezielte Injection-Ketten ab, gäbe ein Versprechen, das kein Klassifikator halten kann – und Entwickler würden darauf aufbauen. Die interessante Frage ist nicht, ob dieser Angriff funktioniert. Sie lautet, ob das mentale Modell des Ökosystems zu dem des Anbieters passt, und derzeit tut es das nicht: Der Auto-Modus wurde im August zur Voreinstellung für Pro-, Max- und Team-Sitzungen, während die Zahl, die Anthropic in Umlauf gebracht hatte, eine Erfolgsquote von 0,00 % aus einer beauftragten Evaluierung mit 72 Szenarien war – Rehberger verbucht das unter dem Marketingproblem der 0,00 % – und der Rahmen, der mit ihr mitreiste, hieß Sicherheit und nicht Komfort plus Verkleinerung des Explosionsradius.¹ Rehberger zieht einen härteren Schluss als ich: Er liest die Kommunikation der 0,00 % und die Einstufung als außerhalb des Geltungsbereichs als widersprüchliche Botschaften, die nicht zusammenpassen.¹ Ich halte beides für vereinbar. Die Einstufung ist die ehrliche Variante, und die Zahl hätte niemals als Produkteigenschaft vermarktet werden dürfen.

Falls Ihr Setup davon ausging, der Klassifikator sei die Mauer: Ziehen Sie die Mauer ein.

Update vom 3. September: Was seit diesem Beitrag ausgeliefert wurde

Claude Code hat innerhalb von 48 Stunden nach diesem Beitrag drei Releases ausgeliefert; zwei davon berühren den Auto-Modus.³ Version 2.1.257, veröffentlicht am 1. September, ergänzt eine Regel, die die Release Notes Containment Escape nennen: „Abrufe von Cloud-Metadaten-Zugangsdaten, Egress-Umgehung und tenantübergreifender Zugriff werden nicht mehr automatisch genehmigt, sofern Ihre Umgebung sie nicht als erwartet kennzeichnet.“ Dasselbe Release ergänzt im Auto-Modus eine einmalige Rückfrage vor dem ersten Lesezugriff außerhalb der Arbeitsverzeichnisse, samt einer Einstellung, permissions.blockReadsOutsideWorkingDirectories, die aus der Rückfrage eine Ablehnung macht. Version 2.1.259, veröffentlicht am 2. September, ergänzt --permission-prompts none für unbeaufsichtigte Headless-Hosts: „Alles, was eine Rückfrage auslösen würde, wird automatisch abgelehnt, während der aktive Berechtigungsmodus (einschließlich des Auto-Modus) weiterhin entscheidet.“

Lesen Sie das in dem Rahmen, den dieser Beitrag aufgespannt hat. Die Regel, die Rückfrage beim Lesen und das Flag sind allesamt echte Härtung, und das Headless-Flag ist die Fail-closed-Einstellung, mit der ein unbeaufsichtigter Host laufen sollte. Die ersten beiden verengen jedoch, was der Auto-Modus von sich aus genehmigt: Die Regel nimmt drei Kategorien aus der automatischen Genehmigung heraus, sofern die Umgebung sie nicht als erwartet kennzeichnet, und die Änderung beim Lesen fragt einmal nach oder lehnt bei aktivierter Einstellung ab. Keine der beiden wird als Grenze beschrieben, und beide sitzen innerhalb des Genehmigungsflusses des Auto-Modus. Genau diese Prüfung hat diese Kette durchlaufen, ohne eine einzige Aktion zu zeigen, die für sich genommen falsch aussah. Die Regel benennt Egress-Umgehung; Rehberger beschreibt keine Umgehung, sondern lediglich eine ausgehende Verbindung bei jedem Hop: einen Download per curl, einen Kindprozess, der eine entfernte Stufe holt, diese Stufe, die die Payload holt, und einen Callback. Ob die Regel irgendetwas davon als Umgehung wertet, sagen die Notes nicht, und sie sagen auch nicht, ob die Rückfrage beim Lesen Lesezugriffe eines Kindprozesses erfasst. Ob eine der beiden Änderungen diese Kette gestoppt hätte, behaupten die Notes nicht, und annehmen sollte man es auch nicht. Eine Korrektur in 2.1.257 sitzt allerdings auf der Ebene der Grenze: Ein deniedDomains-Eintrag der Sandbox blockierte einen mit abschließendem Punkt geschriebenen Host nicht, und das Release behebt das. Das ist eine Reparatur an der Grenze, keine Verschiebung derselben. Was der Auto-Modus von sich aus genehmigt, ist geschrumpft. Die Grenze hat sich nicht bewegt.

Die wichtigsten Erkenntnisse

• Der Auto-Modus ist eine Komfort- und Explosionsradius-Maßnahme, keine Sicherheitsgrenze. Das ist die Position des Anbieters selbst nach einer funktionierenden Umgehung, nicht Kritik von außen.¹
• Klassifikatoren beurteilen Aktionen; Angriffe leben in Kompositionen. Jeder Schritt der demonstrierten Kette ist für sich vertretbar – und genau deshalb hat eine Prüfung pro Aktion sie übersehen.
• Bemerken ist nicht Beheben. In einigen Durchläufen erkannte der Agent seine eigene Kompromittierung und wurde anschließend am Aufräumen gehindert. Planen Sie Ihre Incident Response entsprechend.¹²
• Die Kontrollen, die halten, liegen außerhalb des Modells. Container oder VM, eingeschränkter Egress, Zugangsdaten außerhalb des Home-Verzeichnisses. Alles andere ist Tiefenstaffelung, keine Grenze.

FAQ

Sollte ich den Auto-Modus abschalten?

Nein, es sei denn, Sie haben sich auf ihn als Eindämmung verlassen. Er blockiert eine dokumentierte Reihe destruktiver Operationen – git reset --hard, git checkout -- ., git clean -fd, git stash drop sowie terraform/pulumi/cdk destroy –, wenn er zu dem Schluss kommt, dass Sie sie nicht angefordert haben, und er senkt die Zahl der Rückfragen, die zu reflexhaftem Genehmigen führt. Behalten Sie ihn als Produktivitäts- und Explosionsradius-Maßnahme und ergänzen Sie echte Isolation für Sitzungen, die nicht vertrauenswürdige Eingaben berühren.

Betrifft das nur Claude Code?

Der Mechanismus ist nicht Claude-spezifisch. Jeder Agent, der nicht vertrauenswürdige Archive abruft, Code schreibt und ihn in dem gerade entpackten Verzeichnis ausführt, ist derselben Falle bei der Modulauflösung ausgesetzt, und jede Sicherheitsprüfung pro Aktion ist derselben Kompositionslücke ausgesetzt. Die Einzelheiten hier wurden gegen Claude Code Opus 5 im Auto-Modus demonstriert.¹

Was zählt als Sitzung mit nicht vertrauenswürdigen Eingaben?

Alles, wo von Angreifern beeinflusster Text das Modell erreichen kann: abgerufene Webseiten, heruntergeladene Archive, Texte aus Issues und Pull Requests, E-Mails, Logs eines öffentlichen Dienstes und MCP-Server von Drittanbietern. In der Praxis ist das der Großteil echter Arbeit – und genau das ist das Unbequeme daran.

Wurde das behoben?

Es wurde nicht als zu behebende Schwachstelle behandelt. Anthropic schloss den Bericht als Informative mit der Begründung, dass eine derartige Umgehung des Klassifikators außerhalb dessen liegt, was der Auto-Modus zusagt.¹ Betrachten Sie es als dokumentierte Eigenschaft des Systems und nicht als ausstehenden Patch. Ein Release aus den 48 Stunden nach diesem Beitrag, 2.1.257, verengte, was der Auto-Modus von sich aus genehmigt, und ergänzte eine optionale Sperre für Lesezugriffe außerhalb der Arbeitsverzeichnisse; 2.1.259 ergänzte ein Fail-closed-Flag für Headless-Hosts. Das Update vom 3. September weiter oben beschreibt, was sie ändern und was nicht.³

Quellen