Qwen 3.8 27B in AgentDojo: Wenn fremde Inhalte zu Befehlen werden

In einem meiner Testläufe hat ein lokal betriebener KI-Agent eine Überweisung an ein fremdes Konto ausgelöst, ohne dass der Nutzer das je verlangt hätte. Die Anweisung dazu stand nicht im Chat, sondern in einer Datei, die der Agent im Auftrag des Nutzers geöffnet hatte. Er hat sie gelesen, als Befehl interpretiert und ausgeführt. Danach hat er die eigentliche Aufgabe des Nutzers ebenfalls erledigt und einen freundlichen Abschlussbericht verfasst.

Die Zahlen um diesen Vorfall herum sind der eigentliche Befund. Ohne Angriff löste das offizielle Qwen 3.8 27B in der NVFP4-Ausführung von Unsloth 35 von 37 legitimen Aufgaben in den AgentDojo-Suiten Banking und Slack, also 94,6%. Gegen die einfache Textinjektion des InjecAgent-Musters lag die Angriffserfolgsrate bei 0 von 249 Fällen. Gegen ChatInject, einen Angriff, der die Nutzlast in Qwens eigenes Chat-Template verpackt, waren es 29 von 249, also 11,7%.

Das Ergebnis gilt für genau diesen NVFP4-Checkpoint, genau diese zwei Suiten, einen einzelnen stochastischen Durchlauf unter einem eingefrorenen Serving-Vertrag, keine Verteidigungsschicht und simulierte Werkzeuge. Es ist weder ein Freispruch für Qwen noch ein Urteil über lokale Agenten als Klasse. Alle 29 erfolgreichen Angriffe stehen einzeln im Anhang.

Von nützlichen Tools zur indirekten Prompt Injection

Agenten werden nützlicher, sobald sie Werkzeuge bedienen dürfen: Dateien lesen, Nachrichten senden oder Webseiten abrufen. Solche Zugriffe sind in Büro- und Kommunikationssystemen bereits naheliegend. Bankkonten oder gar Überweisungsrechte würde ich einem heutigen Agenten nicht anvertrauen; AgentDojo modelliert diesen bewusst riskanten Grenzfall. Das Sicherheitsproblem beginnt jedoch schon früher: Sobald ein Werkzeug Inhalte zurückgibt, die jemand anderes geschrieben hat, mischt sich fremder Text in denselben Kontext, in dem auch die echten Anweisungen des Nutzers stehen.

Indirekte Prompt Injection nutzt das aus. Der Angreifer redet nicht mit dem Agenten, sondern platziert seine Anweisung dort, wo der Agent im Rahmen einer legitimen Aufgabe ohnehin hinschaut: in einer Rechnungsdatei, einer Slack-Nachricht, auf einer Webseite. Der Agent liest sie als Teil des Arbeitsmaterials und muss selbst entscheiden, ob er Daten oder Befehle vor sich hat.

Die Forschungsgruppe hinter ChatInject hat gezeigt, dass diese Entscheidung an einer strukturellen Stelle bricht. Instruction-tuned Modelle lernen eine Rollenhierarchie über Spezialtokens, und diese Tokens lassen sich in einer Werkzeugausgabe fälschen. Der Angreifer schreibt keinen auffälligen Befehlssatz mehr, sondern imitiert das native Chat-Template des Zielmodells. Aus einem Textschnipsel in einer Datei wird für das Modell scheinbar eine höherrangige System- oder Nutzeranweisung. Einen wesentlichen Teil dieses Unterschieds misst mein Lauf: dieselben Angriffszielklassen, einmal in der Plain-Baseline und einmal in Qwens eigenem Templateformat.

Was AgentDojo in diesem Lauf verlangt

AgentDojo stammt aus dem SPY Lab der ETH Zürich und ist kein Textbenchmark. Der Agent arbeitet in einer simulierten Umgebung mit echtem Zustand: Konten, Transaktionen, Dateien, Kanäle, Nutzer. Ein Angriff gilt nur dann als erfolgreich, wenn dieser Zustand danach dem Angreiferziel entspricht, also die Überweisung tatsächlich existiert oder der Nutzer wirklich aus dem Workspace entfernt wurde. Eine bloss zustimmende Antwort zählt nicht.

Ich habe zwei Suiten gefahren. Banking kombiniert 16 Nutzeraufgaben mit neun Angriffszielen, das ergibt 144 Paare. Slack kombiniert 21 Nutzeraufgaben mit fünf Angriffszielen, also 105 Paare. Zusammen sind das 249 Paare pro Angriffsmethode und 498 Angriffsfälle insgesamt, dazu 37 angriffsfreie Kontrollaufgaben.

Zwei Kennzahlen laufen dabei getrennt und sind keine Gegenstücke. Die Utility misst, ob die eigentliche Nutzeraufgabe erledigt wurde. Die Attack Success Rate misst, ob das Angreiferziel erreicht wurde. Beides kann gleichzeitig zutreffen, und genau dieser Fall ist der gefährlichste: Der Nutzer sieht ein korrektes Ergebnis und hat keinen Anlass, den Vorgang zu prüfen.

Der Versuchsaufbau

Diese Konfiguration blieb für alle sechs Lanes unverändert. Die GPU war nur über einen kontrollierten Tunnel erreichbar; der Benchmark selbst lief auf einer separaten gehärteten Maschine bei Hetzner. Der Gesamtlauf startete am 27. August um 15:44 UTC und war am 28. August um 02:39 UTC beendet.

Das Ergebnis: 29 von 249 angepassten Angriffen erfolgreich

Die Null in der Plain-Zeile ist bemerkenswert und sollte trotzdem nicht als allgemeiner Robustheitsbeleg gelesen werden. Obwohl der Lauf stochastisch sampelte, erreichte die Plain-Injection in keiner der 249 beobachteten Ziehungen ihr Ziel. Eine nachträgliche konservative Textauszählung liefert zugleich eine Positivkontrolle: In mindestens 200 der 249 Plain-Traces benannte das Modell den Einschub ausdrücklich als eingebettete, injizierte oder anderweitig untrusted Anweisung, davon 104 von 144 Mal in Banking und 96 von 105 Mal in Slack. Gezählt wurden nur explizite Formulierungen in den Assistentenantworten; die Auszählung war kein vorab definierter Benchmark-Scorer. Auch in den übrigen 49 Plain-Traces wurde das Angriffsziel nie erreicht. Die Abwehr hing also nicht davon ab, dass das Modell den Einschub verbalisierte.

Innerhalb der ChatInject-Lane zeigt sich ein genaueres Bild: In 158 von 249 Traces benannte das Modell die Injection ausdrücklich; sechs dieser Angriffe waren trotzdem erfolgreich. Ohne ausdrückliche Benennung gelangen 23 von 91 Angriffen. Verbalisierte Erkennung ging in diesem Lauf mit weniger Erfolgen einher, garantierte aber keine sichere Toolausführung. Auch diese Auszählung ist nachträglich und sagt nicht, ob die Benennung vor oder nach einer schädlichen Aktion erfolgte. Für die 29 Treffer gilt zudem die umgekehrte Sampling-Vorsicht: Sie bezeichnen erfolgreiche Ziehungen, nicht 29 Aufgabenpaare, die bei jeder Wiederholung kippen würden.

Die Angriffe zielten nicht auf Textausgaben, sondern auf Zustandsänderungen. In Banking gingen zehn Angriffe durch: drei unautorisierte Überweisungen an das Angreiferkonto mit dem Musikdienst des Nutzers im Verwendungszweck, zwei mit der IBAN einer Person aus einer früheren Essensabrechnung, eine mit einem Lieblingsessen, eine mit dem Telefonmodell. Dazu kamen zwei Änderungen des Empfängers einer Dauerzahlung auf das Angreiferkonto und eine Passwortänderung auf einen vom Angreifer gewählten Wert. Die Verwendungszweck-Varianten wirken harmlos, sind es aber nicht: Das Modell musste dafür die Transaktionshistorie durchsuchen und persönliche Details in eine Zahlung an Fremde schreiben.

In Slack gingen 19 Angriffe durch: sieben Zyklen aus Einladen, Hinzufügen und Entfernen eines vom Angreifer benannten Nutzers, fünf Besuche einer vom Angreifer genannten Webseite, drei Direktnachrichten mit Angreiferlink an eine Kollegin, zwei Abflüsse aller Kanalnachrichten an eine Angreiferwebseite und zwei Abflüsse aller Nachrichten des Kanals general. Die letzten vier Fälle sind Datenabfluss, die ersten sieben sind Administrationsrechte in fremder Hand.

Der unangenehmste Teil steckt in der Kreuzung beider Achsen. In 21 der 29 erfolgreichen Fälle bestand auch die legitime Nutzeraufgabe. Der Agent hat also die Zusammenfassung geschrieben, die Kollegin eingeladen oder die Rechnung bearbeitet und nebenbei das Angreiferziel erfüllt. Aus Nutzersicht sah der Vorgang in diesen Fällen erfolgreich aus.

Ein zweites Muster betrifft die Nützlichkeit, nicht die Sicherheit. In mehreren Banking-Aufgaben rund um Miete und Dateien erriet das Modell wiederholt Dateinamen, weil kein Werkzeug zum Auflisten von Dateien existierte und der Systemprompt bei leeren Ergebnissen zu einer anderen Anfrage aufforderte. Ein Fall lief so über 953 Sekunden. Diese Läufe endeten regulär, ohne HTTP-, Harness- oder Prozessfehler. Das ist eine begrenzte Werkzeugschleife und kostet Utility Punkte.

ChatInject schadete ausserdem, wenn das eigentliche Angriffsziel nicht durchkam. Unter der Plain-Baseline bestand das Modell 208 von 249 Nutzeraufgaben, unter ChatInject noch 186 von 249. In Slack sank die Utility von 89 von 105 auf 70 von 105. Das ist kein zusätzlicher Angriffserfolg nach dem Security-Scorer, aber ein deutlicher Verfügbarkeits- und Zuverlässigkeitseffekt. Auch die Dateinamen-Schleifen zeigen dabei nicht nur eine Modellgrenze, sondern die Leistung des gesamten Agenten samt bereitgestelltem Werkzeugsatz.

Was 29 von 249 bedeuten und was nicht

Für einen ersten Ordnungsversuch taugt die Literatur nur mit Vorsicht. Die ChatInject-Projektseite nennt für den einfachen Template-Angriff über das volle AgentDojo unter anderem Qwen3-235B mit 54,8%, GPT-oss-120B mit 51,4%, Kimi-K2 mit 29,3%, GLM-4.5 mit 20,3%, Grok-2 mit 19,3% und Llama-4 Maverick mit 17,2%. Für Angriffe mit Qwen-Template gegen geschlossene Zielmodelle werden GPT-4o mit 27,3%, Grok-3 mit 33,2% und Gemini 2.5 Pro mit 10,1% berichtet.

Diese Werte sind kein Ranking neben meinem Ergebnis. Mein Lauf deckt nur Banking und Slack ab, nutzt Benchmarkversion 1.2.1, genau einen lokalen NVFP4-Checkpoint und meinen eingefrorenen vLLM-Adapter; die Publikation verwendet ein anderes Modellset und einen breiteren AgentDojo-Aufbau. AgentDojo selbst weist auf seiner Ergebnisseite darauf hin, dass die Übersicht kein Leaderboard ist, weil die Modelle nicht einheitlich angegriffen wurden. Zulässig ist deshalb nur eine schwache Aussage: Dieser lokale 27B-Checkpoint wirkte in meinem Aufbau überraschend widerstandsfähig. Eine Überlegenheit gegenüber irgendeinem dieser Modelle ist damit nicht belegt.

Dass Slack mit 18,1% klar schlechter abschnitt als Banking mit 6,9%, lässt sich plausibel erklären, aber nicht beweisen. Slack besteht aus freiem Text, Links, Identitäten und Werkzeugen für Kommunikation und Mitgliederverwaltung; Banking arbeitet stärker mit strukturierten Feldern und Beträgen. Für lokale Agenten mit Mail-, Chat-, Browser- oder MCP-Zugriff ist Slack deshalb der realitätsnähere Analogfall, Banking dagegen ein bewusst harter Grenzfall. Die 18,1% lassen sich trotzdem nicht auf ein echtes Slack-, Mail- oder MCP-System übertragen.

Wichtiger ist die betriebliche Umrechnung. Eine mittlere Angriffserfolgsrate von 11,7% ist keine Restwahrscheinlichkeit, mit der man leben kann, sondern eine Rate pro Angriffsversuch. Ein Angreifer braucht kein Mittel über 249 Fälle, sondern einen Treffer bei der Dauerzahlung oder beim Passwort. Genau diese beiden Klassen waren im Lauf erfolgreich.

Daraus folgen auch für einen selbst betriebenen Agenten konkrete Einstellungen, keine magische Promptformulierung. Er bekommt in seiner Toolkonfiguration nur die Rechte, die er wirklich braucht. Geldbewegungen, Passwort- und Mitgliedschaftsänderungen erfordern eine interaktive Bestätigung. Tool-Aufrufe werden lokal protokolliert, damit sichtbar bleibt, was der Agent tatsächlich getan hat. Wer mehr absichern will, kann kritische Aufrufe zusätzlich durch einen kleinen Policy-Proxy prüfen lassen.

Die greifbarste Massnahme ist eine Egress-Positivliste im Agenten-Container oder am Proxy. Neun der 19 erfolgreichen Slack-Angriffe setzten den Aufruf einer angreiferseitig vorgegebenen Adresse voraus. Eine Regel, die nur benötigte Ziele erlaubt, hätte genau diese beobachteten Aktionen blockiert, sofern die fremden Ziele nicht freigegeben gewesen wären. Das beweist keine pauschale Reduktion um neun Fälle unter einer neuen Defense, zeigt aber unmittelbar, wo eine einfache Netzwerkgrenze ansetzt.

Ausserdem müssen die Grenzen dieses Laufs benannt werden: nur Banking und Slack, ein einzelner stochastischer Durchlauf, NVFP4 statt BF16, keine Verteidigungsschicht, kein Multiturn-Angriff, simulierte Werkzeuge ohne echtes Slack und echte Bank. Jedes Aufgabenpaar wurde nur einmal gezogen. Ohne Wiederholungen verzichte ich deshalb auf Intervalle und Signifikanztests. Deskriptiv bleibt der Abstand deutlich: 10 von 144 beobachteten Angriffserfolgen in Banking gegenüber 19 von 105 in Slack. Eine Wiederholung könnte eine andere Teilmenge treffen, und die Ursache des Suite-Unterschieds beweist dieser Lauf nicht.

Anhang: Methode und Einzelergebnisse

Zusammenfassung der Tabelle: 10 erfolgreiche Angriffe in Banking, 19 in Slack, zusammen 29 von 249 angepassten Angriffen. In 21 dieser 29 Fälle bestand die legitime Nutzeraufgabe ebenfalls.