Repeat‑After‑Me‑Prompt umgeht sechs führende KI‑Agenten‑Frameworks

In einem gemeinsamen Papier vom 9. Oktober 2026 beschrieb ein Forscherteam eine neue adversariale Technik namens „Repeat‑After‑Me“. Die Methode täuscht KI‑gesteuerte Agenten, sodass sie von Angreifern bereitgestellte Tool‑Aufrufe ausführen und damit eingebaute Sicherheitsprüfungen umgehen.

Die Wissenschaftler testeten die Technik an sechs weit verbreiteten Frameworks: LangChain / LangGraph, Microsoft Agent Framework, Microsoft AutoGen, Google Agent Development Kit 2.0, AWS Strands Agents und CrewAI. Laut Studie waren alle sechs anfällig für den konstruierten Prompt.

Funktionsweise des „Repeat‑After‑Me“-Prompts

Der Angriff beginnt mit einer harmlos scheinenden Anfrage, die eine Formulierung wie „repeat after me:“ enthält. Das LLM interpretiert dies als Anweisung, den folgenden Text wörtlich zu wiederholen. Enthält der wiederholte Text eine Tool‑Call‑Payload, behandelt das Framework dies als legitime Anforderung und leitet sie an das zugrundeliegende Tool weiter.

Im LangGraph‑1.2.0‑Demo‑Setup lehnte das Modell (Llama 3.1 8B über Ollama) zunächst die Anfrage ab, gab aber dennoch die rohe Tool‑Call‑Zeichenkette aus. Nach einer hypothetischen Umformulierung erzeugte das Modell einen strukturierten Aufruf, der ausgeführt wurde, bevor die Ablehnung verarbeitet wurde – ein Beleg für die Durchführbarkeit des Exploits.

Umfang der Schwachstellen

Über den prompt‑basierten Umweg hinaus führten die Autoren eine groß angelegte Fuzzing‑Kampagne auf 273 Open‑Source‑Multi‑Tool‑Orchestrierungs‑Servern (MCP) durch. Sie entdeckten 253 verifizierte Sicherheitsfehler auf 118 Servern, die 343 unterschiedliche Tools betrafen.

Die Aufschlüsselung der schwerwiegendsten Befunde umfasst 64 Pfad‑Traversal‑Fehler, 7 Server‑Side‑Request‑Forgery‑Probleme (SSRF), 5 Daten‑Leak‑Incidents und 3 OS‑Command‑Injection‑Schwachstellen. Die übrigen Bugs waren hauptsächlich Output‑ oder Log‑Injection‑Probleme.

Das ToFu‑Fuzzing‑Framework

Um diese Lücken zu schließen, stellten die Forscher ToFu vor, ein Fuzzing‑Framework, das Tool‑Metadaten ausliest, sie relevanten CWE‑Einträgen zuordnet und automatisch Sicherheitsprüfungen generiert. ToFu erstellt Harnesses und semantische Orakel, indem es Ausführungstraces introspektiert und Ergebnisse bereinigt.

• Automatische Erzeugung von Fuzzing‑Harnesses aus Tool‑Spezifikationen
• Semantische Orakel aus Ausführungs‑Introspektion
• CWE‑basierte Sicherheitskontroll‑Templates
• Batch‑Tests von Tausenden Tool‑Instanzen
• Berichterstattung verifizierter Bugs mit reproduzierbaren Payloads

Das Papier weist darauf hin, dass viele Tools implizit LLM‑Ausgaben für die Eingabesanitierung vertrauen, selbst wenn diese Eingaben von anderen Tools oder externen Inhalten stammen. Dieses implizite Vertrauen erweitert die Angriffsfläche und ermöglicht verkettete Exploits über mehrere orchestrierte Komponenten hinweg.

Die Entwickler von LangGraph wurden über das Fehlen von Vor‑Ausführungs‑Kontrollen informiert, doch zum Zeitpunkt der Veröffentlichung gab es keine öffentliche Reaktion von den Teams hinter LangChain, Microsoft, Google, AWS oder CrewAI.

Die Analyse der „Repeat‑After‑Me“-Technik verdeutlicht, dass die Kernschwäche nicht im einzelnen LLM selbst liegt, sondern in der Art und Weise, wie Agenten‑Frameworks die Ausgabe des Modells als vertrauenswürdige Eingabe für nachgelagerte Tool‑Aufrufe behandeln. Solange diese Schnittstelle keine unabhängige Validierung vornimmt, lässt sich das Muster beliebig replizieren, weil das LLM lediglich einer Anweisung folgt, die es nicht als potenziell schädlich erkennt. Diese strukturelle Lücke entsteht aus der Annahme, dass die vom Modell erzeugte Zeichenkette bereits sanitisiert sei, wodurch jede nachfolgende Komponente die Verantwortung für die Sicherheit implizit delegiert verliert.

Ein zentrales Limit der präsentierten Forschung besteht darin, dass die getesteten Frameworks zwar repräsentativ für aktuelle Praxis sind, aber nicht sämtliche Implementierungsvarianten abdecken. Unterschiedliche Konfigurationen, etwa strengere Rollen‑ und Berechtigungskonzepte oder zusätzliche Middleware, könnten das Exploit erschweren oder verhindern. Ebenso bleibt offen, inwiefern zukünftige Modell‑Updates, die das Verständnis von Anweisungen wie „repeat after me“ verfeinern, das Angriffsszenario von selbst mitigieren könnten. Die Ergebnisse zeigen also eher ein Warnsignal als einen endgültigen Beweis für universelle Verwundbarkeit.

Die durchgeführte Fuzzing‑Kampagne liefert eine systematische Verifikation der Annahme, dass die Trust‑Boundary zwischen LLM‑Ausgabe und Tool‑Ausführung leicht zu überschreiten ist. Die hohe Quote verifizierter Bugs bestätigt, dass die Schwachstellen nicht zufällig, sondern strukturell in den Orchestrierungs‑Mechanismen verankert sind. Dennoch beruhen die Erkenntnisse auf einer kontrollierten Testumgebung; reale Produktionssysteme können zusätzliche Schutzschichten besitzen, die im Labor nicht abgebildet wurden. Deshalb muss jede Validierung im Feld die spezifischen Deployment‑Parameter berücksichtigen, um Fehlalarme zu vermeiden.

Praktisch bedeutet die Existenz von „Repeat‑After‑Me“‑Exploits für Unternehmen, dass jede automatisierte Workflow‑Kette, die externe Werkzeuge einbindet, als potenzielle Angriffsfläche behandelt werden muss. Die sofortige Deaktivierung automatischer Tool‑Aufrufe reduziert das Risiko, birgt jedoch gleichzeitig Kosten in Form von eingeschränkter Funktionalität und geringerer Effizienz. Ein ausgewogenes Vorgehen erfordert die Einführung von mehrstufigen Prüfungen: zunächst eine syntaktische Analyse der LLM‑Ausgabe, gefolgt von einer semantischen Bewertung, die kontextuelle Inkonsistenzen erkennt, bevor ein Tool überhaupt aufgerufen wird.

Die Integration von ToFu‑ähnlichem Fuzzing in kontinuierliche Integrations‑Pipelines stellt eine präventive Maßnahme dar, die nicht nur bekannte Schwachstellen abdeckt, sondern auch neu auftretende Muster systematisch entdeckt. Durch automatisierte Generierung von Harnesses und semantischen Orakeln können Entwickler frühzeitig erkennen, welche Tool‑Metadaten unzureichend gefiltert werden. Gleichzeitig muss die Skalierbarkeit solcher Tests beachtet werden, da die Menge an unterstützten Werkzeugen in Unternehmensumgebungen schnell wächst und die Testdauer sonst zum Flaschenhals werden könnte. Hier gilt es, Prioritäten auf kritische Pfade zu setzen und regelmäßige Regressionstests zu planen.

Langfristig sollten Architekten von KI‑Agenten‑Frameworks das Konzept einer expliziten Trust‑Boundary implementieren, bei der jede Übergabe von LLM‑generierten Daten an ein Tool durch ein unabhängiges Verifizierungsmodul erfolgt. Dieses Modul müsste nicht nur syntaktische Regeln anwenden, sondern auch kontextuelle Policies, die zum Beispiel das Ausführen von System‑ oder Netzwerk‑Operationen nur unter definierten Bedingungen erlauben. Durch die konsequente Trennung von Sprachverstehen und Systeminteraktion kann das Risiko verketteter Exploits signifikant reduziert werden, ohne die Vorteile der LLM‑gestützten Orchestrierung vollständig aufzugeben.

Für deutsche Unternehmen, die diese Agenten‑Frameworks einsetzen, bedeutet dies, dass jede LLM‑gesteuerte Arbeitsablauf‑Kette, die externe Tools einbindet, als potenziell verwundbar betrachtet werden muss, bis konkrete Gegenmaßnahmen implementiert sind. Empfohlene Sofortmaßnahmen sind das Deaktivieren automatischer Tool‑Ausführungen, die Durchsetzung strenger Eingabevalidierung außerhalb des LLM und die Integration von ToFu‑ähnlichem Fuzzing in die CI‑Pipeline, um verborgene Vertrauensgrenzen‑Schwächen frühzeitig zu entdecken.