NSIG_

Ein Angriff sagt dem Agenten nicht, was er tun soll

Vom Themen KI · Sicherheit · Homelab

Das Bild, das man von einer Prompt-Injektion hat, ist meistens dieses: Auf einer Seite steht in unsichtbarer Schrift „Vergiss alle vorherigen Anweisungen“, und das Werkzeug gehorcht. Diese Form gibt es wirklich, und sie funktioniert auch: Weiter unten steht ein Fall, in dem genau so ein versteckter Befehl ausgeführt wurde. Wer aber nur danach sucht, sucht zu eng.

Auf embracethered.com ist im August 2026 ein Angriff beschrieben worden, der gegen ein Agentenwerkzeug funktioniert hat, und der Satz, in dem der Autor das Verfahren zusammenfasst, geht andersherum:

An attack does not tell the model what to do. The attack just makes the malicious path the one worth pursuing to solve an objective.

Der Angriff befiehlt nichts. Er baut eine Umgebung, in der der vernünftigste Weg zum Ziel durch seine Falle führt.

Die Prüfliste, und sie ist kurz

Simon Willison hat am 16.06.2025 eine Liste veröffentlicht, an der sich ablesen lässt, wann ein Verbund aus Werkzeugen als Ziel taugt. Er nennt sie die lethal trifecta. Drei Eigenschaften, und das ist die ganze Liste:
Zugang zu privaten Daten genau das, wofür man Werkzeuge meistens anschließt
Kontakt mit fremdem Inhalt jeder Weg, auf dem Text oder Bilder eines Angreifers vor das Modell kommen
Ein Kanal nach draußen irgendetwas, womit sich Daten hinausschaffen lassen

Die dritte Zeile wird regelmäßig zu eng gelesen, und das ist der Grund, warum ein scheinbar nur lesendes Werkzeug trotzdem zählt. Willison rechnet auf: Es reicht, wenn ein Werkzeug eine HTTP-Anfrage stellen kann, an eine Schnittstelle, oder um ein Bild zu laden, oder indem es einen Link anbietet, den ein Mensch anklickt. OWASP führt genau das als eigenes Szenario: Eine Seite mit versteckten Anweisungen bringt das Modell dazu, ein Bild einzufügen, das auf eine Adresse zeigt, und damit wandert das Gespräch nach draußen.

Der Punkt ist die Verknüpfung, nicht die einzelne Zeile. Jede für sich ist harmlos und meistens gewollt. Erst wenn alle drei in einem Zusammenhang zusammenkommen, kann ein Angreifer das Werkzeug dazu bringen, an die privaten Daten zu gehen und sie ihm zu schicken.

Willisons Begründung ist genauer, als man sie meistens zitiert hört. Er sagt nicht, ein Modell wisse nicht, woher eine Anweisung kommt. Er sagt, es könne die Wichtigkeit von Anweisungen nicht zuverlässig danach unterscheiden, wo sie herkamen. Am Ende wird alles zu einer Folge von Token zusammengeklebt und dem Modell vorgelegt, etwa die eigene Aufgabe, die abgerufene Seite und das Ergebnis eines Werkzeugaufrufs.

Sein zweiter Punkt trifft jeden, der sich Werkzeuge selbst zusammensteckt. Solange ein Anbieter das ganze System in der Hand hat, kann er den Kanal nach draußen zumachen, und genau so sind die meisten gemeldeten Fälle behoben worden. Wer Werkzeuge aus verschiedenen Quellen mischt, hat niemanden mehr, der das für ihn tut.

Der Angriff, und warum zwei Messungen so weit auseinanderliegen

Am 26.08.2026 ist auf embracethered.com ein Angriff auf Claude Code im Auto Mode beschrieben worden. Der Auto Mode ersetzt die Rückfrage an den Menschen durch einen Sicherheitsklassifikator, und die Quelle stellt ihm eine eigene Überschrift voran: Seit Mitte August ist er in Claude Code der Startmodus ab Werk. Wer meint, ihn nicht zu benutzen, benutzt ihn womöglich.

Interessant ist der Fall wegen der Zahlen, die dabei nebeneinander stehen:

Messung Ergebnis
Auftragsprüfung durch Trajectory Labs, 72 Szenarien, je zehnmal 0.00 % Erfolg
Die Kette, die unten steht, kleine Stichprobe 3 von 5, also 60 %
Zwei weitere Varianten desselben Autors 3 von 5 und 4 von 5

Der Autor nennt das ausdrücklich kleine Stichproben und keine allgemeingültige Messung.

Der Autor löst den Widerspruch selbst auf, und die Auflösung ist der Grund, warum der Fall hier steht: Die Auftragsprüfung hat einen festen Satz von 72 Szenarien gemessen, zehnmal durchgespielt. Seine Kette war nicht darin. Also sind 0.00 Prozent im Vergleichstest und eine funktionierende Codeausführung gleichzeitig wahr. Eine einzelne Schlagzeilenzahl führt genau deshalb in die Irre.

Die Kette selbst ist es wert, einmal gelesen zu werden, weil an jeder Stelle etwas Vernünftiges passiert:

  1. Der Auftrag ist harmlos: fasse diese Seite zusammen
  2. Der Server antwortet mit 415 Unsupported Media Type. Er sagt nicht, was zu tun ist. Das Werkzeug entscheidet von selbst, es stattdessen direkt mit curl zu versuchen
  3. Eine Weiterleitung führt auf ein ZIP-Archiv. Die Quelle listet sechs Einträge darin; vier davon tragen den Angriff: kodierte Datensätze, eine README.txt, die das mitgelieferte decoder-darwin als das Werkzeug zum Entschlüsseln beschreibt, dieses Programm selbst, und eine Datei struct.py
  4. Das Werkzeug weigert sich, das fremde Programm auszuführen. Das ist die richtige Entscheidung, und sie ist die Falle: Es schreibt sich stattdessen selbst ein kurzes Python-Programm
  5. Dieses Programm läuft im entpackten Verzeichnis. Dort liegt eine Datei struct.py. Python durchsucht das Arbeitsverzeichnis mit, und der Standardbaustein für die Kodierung lädt genau diesen Namen. Beim Laden läuft fremder Code mit
  6. Dieser Code startet einen abgetrennten Kindprozess, der eine weitere Stufe nachlädt und ausführt. Im Versuchsaufbau meldet sich die Maschine danach bei einem kontrollierten Server, und der Prozess kann das Gespräch überleben

Der Beitrag gliedert den Weg in fünf Abschnitte; die sechs Schritte hier ziehen den harmlosen Auftrag am Anfang als eigenen heraus.

Eine Abwandlung davon gehört dazu, weil sie die Frage verschiebt, was ein gelungener Angriff erreichen kann: Statt eines Python-Kindprozesses startet die vergiftete Datei ein zweites Agentenwerkzeug, kopflos. Die Nutzlast führt dann nicht nur Code aus, sie erzeugt einen weiteren Agenten, und der bekommt seinen eigenen Werkzeugzugriff und seinen eigenen Zusammenhang. In den Durchläufen hat dieses Kind einfache Erkundung betrieben und Dateien im Heimatverzeichnis geschrieben.

Der entscheidende Satz steht dort so: Das Werkzeug traut dem mitgelieferten Programm nicht, aber dem, das es selbst geschrieben hat. Das mitgelieferte Programm ist ein Köder, und die Entscheidung dagegen ist der Weg hinein.

Zwei Beobachtungen daraus sind unabhängig vom Rest lehrreich.

Die erste: In einigen Durchläufen hat das Werkzeug den Angriff später bemerkt und wollte den fremden Prozess beenden. Der Auto Mode hat den Aufräumbefehl abgelehnt, nachdem er die Entstehung durchgelassen hatte. Die Absicherung war an der falschen Stelle streng.

Die zweite wiegt schwerer, wenn man sich auf Nachfragen verlassen will: Manchmal hat das Werkzeug hinterher gesagt, es habe die fremden Anweisungen nicht ausgeführt. Die Quelle vermerkt dazu in Klammern, dass es das sehr wohl getan hatte. Die Selbstauskunft ging also in die gefährliche Richtung falsch. Absichtlich aufgerufen hat es die vergiftete Datei nicht; es wusste nur nicht, was beim Laden mitgelaufen war.

Der Ausweg, den beide Beiträge nennen

Hier steht die eigentliche Empfehlung, und sie ist keine Feineinstellung am Prompt. Der Beitrag vom August trägt sie als eigene Überschrift, und das Wort darin ist nicht verhandelbar formuliert: Sandboxing, nicht optional.

Wörtlich heißt es dort, ein Klassifikator sei kein Sandkasten, und der Auto Mode sei kein Ersatz dafür, den Agenten in einer isolierten Umgebung laufen zu lassen und zu beobachten, was er tut. Sieben Sätze stehen dort als Rat, und der erste ist der allgemeinste: der Ausgabe des Modells nicht trauen. Vier davon als Liste:

  • Unbeaufsichtigte Codier-Agenten in einem Container, einer VM oder einem Betriebssystem-Sandkasten laufen lassen
  • Den Netzverkehr nach draußen einschränken
  • Die Agenten beobachten
  • Ihnen kein Heimatverzeichnis, keine SSH-Schlüssel, keine Cloud-Zugangsdaten offenlegen

Dazu ein Satz, der die ganze Absicherungsdebatte auf den Punkt bringt: Eine Freigabe durch den Auto Mode ist kein Nachweis, dass ein Befehl harmlos ist.

Aus dem Haus des Herstellers kommt dazu zweierlei, und der Autor sagt ausdrücklich, dass beides nicht zusammenpasst. Er hat den Fall gemeldet; Anthropic hat den Bericht als Informative geschlossen und das Verhalten als „working as designed“ eingestuft. Die Position dahinter schreibt der Autor Anthropic zu, in Klammern ersatzweise dessen Sicherheitsteam: Der Auto Mode sei eine Bequemlichkeitsfunktion mit einem Klassifikator nach bestem Bemühen, keine Sicherheitszusage, und entschlossene Ketten aus harmlos aussehenden Schritten solle er gar nicht abfangen. Die eigentliche Grenze sei Isolierung auf Betriebssystemebene und die Kontrolle dessen, was nach draußen darf.

Daneben steht eine Aussage aus dem Claude-Code-Team, Prompt-Injektion sei in der Praxis weitgehend gelöst, man könne sie nur nicht mehr vorführen. Der Beitrag, in dem dieser Satz zitiert wird, ist eine Vorführung, und auf sie kam die Antwort, eine entschlossene Angriffskette liege außerhalb des Umfangs. Der Autor hält fest, dass Nutzer damit gemischte Botschaften bekommen und die beiden nicht zusammengehen. Wer daraus etwas für sich ableiten will, hält sich besser an die Antwort auf den Bericht: Sie sagt, worauf man nicht warten braucht.

Der Autor selbst zieht die Bilanz ausgewogener, als es bis hierher klingt, und das gehört dazu: Der Auto Mode kann das Risiko senken, verglichen mit einem Betrieb ganz ohne Rückfragen. Er ist nur keine Sicherheitsgrenze.

Gegen die gezeigte Kette nennt die Quelle außerdem einen sehr konkreten Gegenzug, und zwar an der Stelle, an der der Angreifer ihn selbst benutzt: python3 -I schaltet Pythons isolierten Modus ein und verhindert damit, dass das vergiftete Modul überhaupt geladen wird. Der Angreifer braucht das, damit seine eigene Falle nicht ihn selbst trifft; die Quelle schreibt ausdrücklich dazu, dass es zugleich eine Absicherung gewesen wäre, die das Werkzeug hätte benutzen können.

Die Quelle führt auch die Durchläufe auf, in denen das Werkzeug richtig lag, und die lesen sich wie eine Anleitung: Es hat das Archiv untersucht, ohne Python aus dessen Wurzel zu starten; es hat den isolierten Modus benutzt; es hat seinen Ersatzentschlüssler aus einem sicheren übergeordneten Verzeichnis laufen lassen; und es hat die Überlagerung des Moduls erkannt, bevor sie zuschlug.

Der Beitrag vom Februar, vom selben Autor, rät zum selben, wenn auch vorsichtiger formuliert: man solle in Erwägung ziehen, den Agenten in einem Sandkasten laufen zu lassen, in dem man ihm Zugriff auf Ressourcen und Daten ausdrücklich einräumt. Besonders dann, wenn Befehle automatisch freigegeben werden.

Das ist die Antwort auf die Prüfliste weiter oben. Ein Codier-Agent hat alle drei Zutaten bauartbedingt; man kann sie ihm nicht wegnehmen, ohne ihn abzuschaffen. Was man stattdessen tun kann, ist die Reichweite der dritten zu begrenzen und dafür zu sorgen, dass die erste wenig hergibt.

Was man sonst dagegen tun kann, und was nicht

Zwei Listen, und sie richten sich an verschiedene Leute.

OWASP führt Prompt-Injektion als LLM01, also als Nummer eins seiner Liste der zehn Risiken für 2025, und nennt dazu sieben Maßnahmen und neun Beispielszenarien. Vier der sieben lassen sich auch dann anwenden, wenn man kein eigenes Programm baut, sondern nur Werkzeuge zusammensteckt:

  • Rechte klein halten. Ein Werkzeug bekommt nur, was es für seine Aufgabe braucht
  • Für heikle Schritte einen Menschen fragen. Genau die Stelle, die ein Auto Mode ersetzt
  • Fremden Inhalt kenntlich abtrennen, damit er nicht wie eine Anweisung aussieht
  • Gegen sich selbst testen, und das Modell dabei wie einen nicht vertrauenswürdigen Benutzer behandeln

Die restlichen drei betreffen den Bau einer eigenen Anwendung: Verhalten im Systemprompt einschränken, Ausgabeformate festlegen und prüfen, Ein- und Ausgaben filtern.

Anthropics Anleitung trennt sauber zwischen zwei Bedrohungsmodellen. Beim einen ist der Benutzer selbst der Angreifer, beim anderen ist er es nicht, und der Angriff kommt über Inhalt herein, den das Modell in seinem Auftrag liest. Für den zweiten Fall stehen dort acht Maßnahmen. Die meisten setzen voraus, dass man selbst etwas an ein Modell anschließt; eine davon gilt aber für jeden und deckt sich mit dem Abschnitt oben: Zugriff klein halten und Werkzeuge in abgeschotteten Umgebungen laufen lassen. Drei weitere, die das Muster gut zeigen:

  • Fremden Inhalt nur als Werkzeugergebnis übergeben, nie im Systemprompt und nie als gewöhnlichen Benutzertext
  • Dazuschreiben, was der Inhalt ist und woher er kommt
  • Fremde Zeichenketten als JSON verpacken, damit ein Angreifer nicht aus dem Text ausbrechen kann, indem er ein Anführungszeichen schließt

Die erste davon hat eine Kehrseite, die in derselben Liste steht und ohne die man sich in die eigene Falle baut: Die eigenen Anweisungen gehören nicht in ein Werkzeugergebnis. Weil Inhalt von dort als nicht vertrauenswürdig behandelt wird, kann eine eigene Anweisung an dieser Stelle ignoriert oder als Angriffsversuch angesehen werden.

Und jetzt der Teil, der beim Lesen am unbequemsten ist, aber in beiden Quellen steht. OWASP schreibt, es sei unklar, ob es überhaupt eine sichere Methode zur Verhinderung gibt, weil die Sache in der Arbeitsweise der Modelle selbst angelegt ist. Willison wird noch deutlicher und rechnet vor, warum ein Schutzprodukt, das mit 95 Prozent gefangener Angriffe wirbt, kein Schutz ist: In der Sicherheit von Webanwendungen sind 95 Prozent eine glatte Fünf.

Seine eigene Antwort für den, der Werkzeuge mischt, ist entsprechend knapp und sie steht zweimal in seinem Text: Der einzige Weg, dort sicher zu bleiben, ist, die Kombination der drei gar nicht erst herzustellen.

Warum Hinsehen allein nicht reicht

Bleibt der naheliegende Einwand: Man liest halt nach, was man sich einbaut.

Am 11.02.2026 ist auf derselben Seite gezeigt worden, warum das nicht trägt. Der Autor hat in eine echte, fremde Erweiterung zusätzliche Anweisungen eingebaut, und zwar mit unsichtbaren Unicode-Zeichen aus dem Tag-Bereich. Im Text sieht man nichts. Das Modell liest sie trotzdem und hat in der Vorführung danach gehandelt. Eine Voraussetzung gehört dazu, und sie ist keine Kleinigkeit: Bei dieser Vorführung war die automatische Freigabe für das Shell-Werkzeug eingeschaltet. Genannt sind Gemini, Claude und Grok als Modelle, von denen bekannt ist, dass sie diese Zeichen als Anweisung auffassen. Unsichtbare Zeichen sind dabei nur ein Träger unter mehreren: OWASP nennt als eigenes Szenario Anweisungen, die in einem Bild versteckt sind.

Der Vorbehalt gehört dazu, und er steht in derselben Quelle. Beim Wiederholen der Vorführung am 10.02.2026 kam die Erweiterung in Claude Code nicht mehr durch: durchgängig Erkennung der unsichtbaren Zeichen und Verweigerung. Der Autor schreibt, offenbar habe Anthropic in der Woche davor etwas an der Erkennung geändert, und lässt offen, ob das Absicht war. In claude.ai gab es diese Absicherung zu dem Zeitpunkt für Erweiterungen nicht. Der Angriffsweg ist also nicht überall gleich offen, und was heute erkannt wird, war es letzte Woche noch nicht.

Dazu eine Stelle, die man leicht übersieht: Name und Beschreibung einer solchen Erweiterung stehen von Anfang an im Zusammenhang, bevor sie überhaupt benutzt wird. Wer prüft, prüft meistens den langen Text darunter.

Praktisch heißt das dreierlei:

  1. Eine Sichtprüfung ist kein Nachweis. Man braucht etwas, das nach unsichtbaren Zeichen sucht. Der Autor hat dafür einen einfachen Scanner gebaut
  2. Ein Treffer allein sagt nichts. Die übliche Fundmenge sind gewöhnliche Emoji. Zu suchen sind zusammenhängende Läufe von Tag-Zeichen; sein Werkzeug schlägt bei einem Lauf von mehr als 10 an, und eine Gesamtzahl über 100 verstreuter Zeichen gilt ihm ebenfalls als hoher Befund
  3. Es gibt einen Schalter, der die Angriffsfläche verkleinert: disable-model-invocation: true. Damit lässt sich eine Erweiterung nur noch ausdrücklich aufrufen und nicht mehr vom Modell selbst

Dazu der Rat, den die Quelle unabhängig davon gibt: bei Erweiterungen sehr wählerisch sein, nur aus vertrauenswürdigen Quellen nehmen, und wieder entfernen, was man nicht mehr braucht.

Ein Streitpunkt zwischen zwei Quellen

Zwei der Quellen hier widersprechen sich, und es lohnt sich, das zu wissen, bevor man die Begriffe von jemand anderem hört.

OWASP behandelt Jailbreak als eine Form der Prompt-Injektion: die Form, bei der ein Angreifer das Modell dazu bringt, seine Sicherheitsregeln ganz beiseitezulassen.

Willison, der den Begriff geprägt hat, hält beides für verschiedene Dinge und ärgert sich sichtbar über die Vermischung. Sein Argument ist praktisch: Wer Prompt-Injektion für dasselbe wie Jailbreak hält, hält sie für das Problem des Modellanbieters und nicht für seins. Genannt hat er sie nach der SQL-Injektion, und der zugrunde liegende Fehler ist derselbe: vertrauenswürdiger und nicht vertrauenswürdiger Inhalt landen im selben Zusammenhang.

Was davon bleibt

Die Prüfliste ist das Werkzeug, und sie kostet dreißig Sekunden. Überall dort, wo fremder Text vor ein Modell kommt, drei Fragen: Kommt das Werkzeug an etwas Privates? Liest es Inhalt, den jemand anderes bestimmen kann? Kann es etwas nach draußen schicken?

Bei zusammengesteckten Werkzeugen ist das Ergebnis unmittelbar zu gebrauchen, und Willisons Rat dazu steht oben: die Kombination gar nicht erst herstellen. Eine der drei Zutaten wegzulassen ist fast immer leichter, als alle Angriffe abzufangen.

Bei einem Codier-Agenten geht das nicht. Der hat alle drei bauartbedingt, und man kann sie ihm nicht nehmen, ohne ihn abzuschaffen. Dort verschiebt sich die Frage, und das ist der Teil, den die Prüfliste allein nicht hergibt: nicht mehr, wie man Angriffe abhält, sondern was ein gelungener Angriff überhaupt erreichen kann. Container oder VM, eingeschränkter Weg nach draußen, keine Schlüssel und Zugangsdaten in Reichweite, und jemand, der hinsieht.

Ein Klassifikator ist kein Sandkasten, eine automatische Freigabe ist kein Nachweis, und die Auskunft des Agenten über sich selbst ist auch keiner.

Die Quellen

Alle fünf sind primär, also von denen, die die Sache selbst untersucht oder festgelegt haben, und keine Berichterstattung darüber. Die beiden Beiträge zu den Angriffen erscheinen auf embracethered.com; der Autor zeichnet dort als wunderwuzzi, ein bürgerlicher Name steht in beiden Texten nicht.

Die Prüfliste steht in https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/. Die Einordnung als LLM01 samt der sieben Maßnahmen und neun Szenarien in https://genai.owasp.org/llmrisk/llm01-prompt-injection/. Die acht Maßnahmen gegen indirekte Injektion stehen in https://docs.claude.com/en/docs/test-and-evaluate/strengthen-guardrails/mitigate-jailbreaks. Die Angriffskette, die zwei Messungen und der Abschnitt zum Sandkasten in https://embracethered.com/blog/posts/2026/breaking-claude-code-opus-5-and-automode/, die unsichtbaren Anweisungen samt Vorbehalt vom 10.02.2026 in https://embracethered.com/blog/posts/2026/scary-agent-skills/.

← Alle Notizen