Künstliche Intelligenz (KI)
RTT-Exploits, neue Angriffsmuster gegen KI-Agenten
KI-Agenten sind privilegierte Komponenten, die im Rahmen ihrer Aufgaben auch nicht vertrauenswürdige Eingaben auswerten. Wer dies übersieht, baut alle Kontrollmechanismen auf einem Exploit auf, den Angreifer nach dem Muster „Return-to-Tool“ zu nutzen wissen.
Save to Folio
Die wichtigsten Erkenntnisse
- Eine neue Klasse von Exploit-Mustern ist im Zeitalter der KI entstanden. Bei RTT-Exploits veranlassen eingebettete Anweisungen den KI-Agenten, für ihn autorisierte Tools aufzurufen, um Aktionen auszuführen, die der Angreifer beabsichtigt.
- Erfolgreiche Angriffe können zum Diebstahl und zur Offenlegung von Kundendaten, internen Dokumenten und anderen Beständen mit sensiblen Informationen führen.
- RTT lässt sich in jedem harmlos aussehenden Text verbergen, sodass seiner potenziellen Reichweite keine klaren Grenzen gesetzt sind.
- Dies erfordert – ebenso wie andere Exploits im Zeitalter der KI – einen Sicherheitsansatz, der über herkömmliche Abwehrmaßnahmen hinausgeht.
Das Sicherheitsteam hat alles richtig gemacht. Es hat die Datenbank in einem Docker-Container isoliert, den Model Context Protocol (MCP)-Server in einem eigenen Netzwerksegment untergebracht, und der Agent läuft in einer Sandbox. Vor der Anwendungsschicht befinden sich eine Web Application Firewall (WAF) und ein Reverse-Proxy. Die Firewall-Regeln sind streng, der ausgehende Datenverkehr ist eingeschränkt, und die Produktionszugangsdaten verlassen niemals den Tresor. Der Prüfer hat alles abgenommen.
Dann hat das Team einen KI-Agenten angebunden, damit Support-Tickets automatisch sortiert, Kundendokumente in großem Umfang analysiert und Ingenieure Produktionsdaten in natürlicher Sprache abfragen können. Der Agent funktioniert einwandfrei.
Dennoch landet am Samstagmorgen eine Nachricht im Posteingang des Leiters: „Schauen Sie sich das mal an. Soll das so sein?“ Im Anhang befindet sich ein Screenshot. Jedes Authentifizierungs-Token aus der Produktionsdatenbank befindet sich in einem öffentlichen Kundenkommentar-Thread, gepostet vom eigenen KI-Agenten über dessen eigenes Dienstkonto, mithilfe der genehmigten Tools und im Rahmen der vom Team gewährten Berechtigungen. Es wurden keine Warnmeldungen ausgelöst, und nichts verstößt gegen die Richtlinien.
Return-to-Tool (RTT) ist eine spezifische Unterklasse der indirekten Prompt Injection, bei der die injizierte Anweisung den Agenten dazu veranlasst, seine autorisierten Tools gegen den Mandanten einzusetzen, den er bedient. Die indirekte Prompt Injection ist der Übertragungsmechanismus, also die Art und Weise, wie nicht vertrauenswürdige Inhalte das Modell erreichen. RTT bezeichnet das Missbrauchsmuster, d. h. wie die genehmigten Tools des Agenten für den vom Angreifer vorgegebenen Zweck ausgenutzt werden.
Das ist so etwas wie das „Return-Oriented Programming“ (ROP) des KI-Zeitalters. Die genehmigten Tools des Agenten sind die „Gadgets“, und die Eingabeaufforderung des Angreifers ist die Kette, die sie miteinander verknüpft.
Herkömmliche Sicherheitsmaßnahmen helfen nicht weiter
Wie gelangt ein Support-Ticket in die Geheimnistabelle?
Nein, es wurde keine Kontrollmaßnahme übersehen. Vielmehr greifen die Abwehrmaßnahmen, auf die sich Organisationen verlassen, hier aus verschiedenen Gründen nicht.
Der Perimeter (WAF, Reverse-Proxy, Eingabefilter) dient dazu, bösartigen Datenverkehr abzufangen, doch bei einem Angriff durch einen KI-Agenten kommt harmlos aussehender Text – keine Shell-Metazeichen, keine Exploit-Strings, nichts, was ein regulärer Ausdruck oder eine Signatur erkennen könnte. Der Angreifer reicht ein Support-Ticket ein oder lädt ein Dokument hoch. Erst später, wenn es in der Datenbank vorliegt und der Agent es liest, wird es zu einer Anweisung. Es gab nie etwas, das die WAF hätte blockieren können!
Auch die Container-Isolierung hilft nicht weiter. Es spielt keine Rolle, ob der Agent, die Datenbank oder beides in abgeschotteten Docker-Containern läuft. Der Angriff findet vollständig innerhalb der vom Sicherheitsteam festgelegten Vertrauensgrenze statt, nämlich innerhalb der Kommunikation zwischen dem Agenten und seinen eigenen Tools. Die Sandbox löst ein anderes Problem.
Die rollenbasierte Zugriffskontrolle (RBAC) tut es auch nicht. Seit 30 Jahren wird mit RBAC das Prinzip der geringsten Berechtigungen umgesetzt, jede Rolle auf die minimal erforderlichen Berechtigungen beschränkt, und die Datenbank setzt den Rest durch. Das wurde mit ziemlicher Sicherheit auch für den Agenten getan. Allerdings steuert RBAC, auf welche Tabellen der Agent zugreifen darf, nicht jedoch auf die Zeilen innerhalb dieser Tabellen.
Und da bei jedem Schritt des Angriffs die eigenen Anmeldedaten und genehmigten Tools des Agenten verwendet werden, gibt es für herkömmliche Überwachungsmaßnahmen nichts Ungewöhnliches zu melden. Das Audit-Protokoll zeigt, dass der Agent Routinevorgänge ausführt. Wenn sich nicht erkennen lässt, was vor sich geht, ist der KI-Agent möglicherweise bereits kompromittiert.
Der Agent selbst ist die neue Angriffsfläche
Setzt man einen KI-Agenten zwischen nicht vertrauenswürdige Eingaben und eine Reihe von Tools, so geschehen zwei Dinge mit dem Bedrohungsmodell, die vor einigen Jahren noch nicht zutrafen: Einfache Daten können nun die Ausführung steuern, und ein Angreifer kann inaktive Schwachstellen auslösen, die im Backend verborgen sind.
Daten sind ausführbarer Code
In Vorzeiten der KI musste Code ausgeführt werden, um etwas auf einem System zu bewirken. Ein Angreifer musste eine Binärdatei auf die Festplatte bringen, sich eine Shell verschaffen oder einen Remote Code Execution (RCE)-Fehler finden. Die gesamte Detection-Branche basiert auf dieser Annahme: Man achtet auf neue Prozesse, neue Dateien oder neue Systemaufrufe und entdeckt so den Angriff.
KI-Agenten brechen mit dieser Annahme. Ransomware verschlüsselt jede Kunden-Mail in einer Postgres-Datenbank, indem sie lediglich eine speziell gestaltete Prompt nutzt, die in einem Support-Ticket versteckt ist – ohne Ablegen von Binärdateien, Starten von Prozessen oder RCE. Der Agent, der dieses Ticket während der routinemäßigen Triage liest, setzt die Anweisungen des Angreifers eigenständig in Datenbankoperationen um.
Der Agent ist das Bindeglied. Er wandelt bloßen Text in Aktionen um, die das Backend ausführt. Nimmt man den Agenten aus dem Spiel, bleibt derselbe Text für immer in einer Datenbankzeile stehen und bewirkt nichts.
Inaktive Schwachstellen werden angreifbar
Zahlreiche bekannte Bugs existieren jahrelang im Backend, ohne dass sie jemand ausnutzt. Sie sind irgendwo dokumentiert (zum Beispiel in einer CVE, einem Blogbeitrag oder einem Konferenzvortrag), aber niemand macht sich deswegen Sorgen, da kein Mensch versehentlich über den Auslöser stolpern wird.
Vor mehr als einem Jahr wurde eine SQL Read-Only-Schwachstelle im mcp/postgres Docker-Image bekannt. Der ungepatchte Code wurde dennoch weiterhin ausgeliefert, mehr als 100.000 Mal von Docker Hub heruntergeladen und war schließlich in unzähligen Produktionsumgebungen mit KI-Agenten verbunden. (Dies ist kein Gedankenexperiment. TrendAI™ Research meldete die Schwachstelle im Januar 2026 an Docker, und das Image wurde kurz darauf von Docker Hub entfernt).
Ein KI-Agent führt bereitwillig jede SQL-Anweisung aus, die in einem Support-Ticket beschrieben ist – einschließlich der Sequenz, die die Umgehung der Schreibschutzbeschränkung auslöst. Der Fehler selbst hat sich nicht geändert, seine Ausnutzbarkeit schon. Ein Angriff, der gestern noch theoretisch war, ist heute ein funktionierender Exfiltrationspfad, wobei der Agent als Übertragungsmechanismus dient. Solche Bereitstellungen sind nun nur noch ein gezieltes Ticket von einer Kompromittierung entfernt, unabhängig davon, ob bereits jemand davon Gebrauch gemacht hat.
Der Agent überlegt, aber nicht zuverlässig
Die Ausgabe großer Sprachmodelle (LLM) ist probabilistisch. Dieselbe Absicht, die auf hundert leicht unterschiedliche Weisen ausgedrückt wird, wird vom Modell unterschiedlich interpretiert. Manche Formulierungen lösen eine Ablehnung aus, während andere zur Ausführung führen.
Gibt es eine Chance, dass ein Angreifer einen KI-Agenten überlisten kann? Die Antwort lautet: Ja. LLMs sind nur so intelligent wie die Daten, mit denen sie trainiert wurden. Verteidiger stellen einen festen Korpus bereit. Angreifer nutzen einen offenen. Wenn man eines dieser Modelle hart genug auf die Probe stellt, tauchen Schwachstellen auf. Wir brauchen nur eine einzige Prompt, damit der Angriff erfolgreich ist.
Ein Angreifer platziert Anweisungen in Inhalten, die der Agent garantiert liest. Der Agent, der nicht in der Lage ist, Daten von Befehlen zu unterscheiden, und bereit ist, alles auszuführen, was er verarbeitet, kehrt nach dem Lesen dieser Inhalte zurück, indem er seine eigenen genehmigten Tools aufruft – über sein eigenes Dienstkonto und im Rahmen seiner dokumentierten Berechtigungen, jedoch in die vom Angreifer gewählte Richtung. Wir bezeichnen diesen Exploit der KI-Ära als „Return-to-Tool“ (RTT).
RTT ist keine Sicherheitslücke in einem bestimmten Modell, Framework oder MCP-Server, sondern eine neue Angriffsklasse, die in dem Moment entsteht, in dem ein Sprachmodell mit Tool-Zugriff nicht vertrauenswürdigen Inhalten ausgesetzt wird – was auf einen Großteil der heute eingesetzten Systeme zutrifft.
Die nächsten drei Teile unserer Artikelserie zeigen RTT in drei verschiedenen Umgebungen: einem „schreibgeschützten“ Postgres-MCP-Server, einem Bot zur Triage von Support-Tickets und einer KYC-Pass-Pipeline. Der Angriff funktioniert in jedem Fall auf die gleiche Weise. Die meisten Agenten, die nicht vertrauenswürdige Eingaben lesen und ein Tool aufrufen, sind gefährdet.