Prompt Injection: Wie Angreifer KI-Agenten mit Überredung kapern

Die neue Angriffsfläche: KI-Agenten
Mit der wachsenden Leistungsfähigkeit und Autonomie von KI-Systemen ist eine neue Klasse von Sicherheitsbedrohungen entstanden: Agent-Injection-Angriffe, allen voran Prompt Injection.
Anders als klassische Cyberangriffe, die Softwarefehler oder Fehlkonfigurationen ausnutzen, manipulieren diese Angriffe, wie KI-Systeme Anweisungen interpretieren.
Das ist ein grundlegender Wandel in der Art, wie Systeme kompromittiert werden: Angreifende müssen die Software nicht mehr knacken, sie überreden sie.
Was „Agent Injection“ in der Praxis bedeutet
Eine Injection liegt vor, wenn nicht vertrauenswürdige Inhalte (eine Webseite, ein Dokument, eine E-Mail, ein Ticket-Text, eine Anzeige, ein PDF usw.) Anweisungen enthalten, die der Agent wie echte Vorgaben behandelt. Ziel der Angreifenden ist es, Prioritäten außer Kraft zu setzen, sodass der Agent ihren Anweisungen folgt statt der Absicht der Entwickelnden oder Nutzenden.
Ein moderner Agent kombiniert typischerweise:
- ein Modell (LLM),
- einen System-Prompt bzw. eine Policy (Regeln),
- Tools (APIs, Browser, Dateisysteme),
- Kontextquellen (Webseiten, E-Mails, Dokumente, Tickets, Wissensdatenbanken).
Direkte Prompt Injection bedeutet, dass Angreifende schädliche Anweisungen unmittelbar in den Eingabekanal des Agenten einschleusen, etwa in eine Chat-Oberfläche, um dessen Verhalten gezielt zu überschreiben oder umzulenken.
Bei der indirekten Prompt Injection verstecken Angreifende diese Anweisungen dagegen in externen Inhalten, die der Agent später verarbeitet, etwa in Webseiten, E-Mails oder Dokumenten. Diese indirekte Form ist besonders riskant für Browsing-Agenten und Enterprise-Copilots, die darauf ausgelegt sind, große Mengen an Fremddaten automatisch aufzunehmen und darauf zu reagieren.
Wenn Agenten selbst zur Angriffsfläche werden
Mit zunehmender Autonomie von KI-Agenten beschränken sich Schwachstellen nicht mehr auf ein einzelnes Modell oder Deployment. Sie entstehen vielmehr daraus, wie Agenten mit Informationen, Tools und untereinander interagieren.
Aktuelle Forschung und reale Vorfälle zeigen, dass agentenbasierte Systeme eine völlig neue Klasse von Sicherheitsrisiken mit sich bringen, eine, die sich zur Laufzeit und über ganze Agenten-Netzwerke hinweg entfaltet (Brodt et al., 2026).
Anders als klassische Anwendungen laufen Agenten oft dauerhaft, nehmen Inhalte aus vielen Quellen auf und tauschen Nachrichten mit anderen Agenten aus. So entstehen Bedingungen, unter denen sich schädliche Anweisungen ausbreiten, festsetzen und sogar weiterentwickeln können.
Kürzlich beobachtete Schwachstellen bei Agenten
1 Prompt Injection ohne jede Interaktion (Zero-Click)
Sicherheitsforschende haben gezeigt, dass Agenten nicht zwingend eine explizite Nutzereingabe brauchen, um kompromittiert zu werden. Sorgfältig präparierte Dokumente, E-Mails oder Webseiten können eingebettete Anweisungen enthalten, die automatisch ausgeführt werden, sobald ein Agent sie verarbeitet.
Ein dokumentiertes Beispiel, EchoLeak (CVE-2025-32711), zeigte, wie Angreifende mehrere Instruction-Overrides verketten konnten, um in einem Enterprise-Copilot-Szenario sensible interne Daten abzugreifen, ganz ohne Zutun der Nutzenden. Die Schwachstelle lag nicht in fehlerhaftem Code, sondern darin, wie der Agent nicht vertrauenswürdigen Kontext zur Laufzeit interpretierte.
Diese Angriffsklasse ist besonders gefährlich in Unternehmensumgebungen, in denen Agenten fortlaufend Postfächer, Tickets oder gemeinsame Dokumentenablagen durchsuchen.
2 Tool-Missbrauch durch Verwirrung über Anweisungen
Eine weitere wachsende Kategorie von Schwachstellen betrifft Agenten mit Tool-Zugriff.
Hat ein Agent Zugriff auf APIs, Dateisysteme oder Messaging-Tools, müssen Angreifende keine Zugangsdaten stehlen. Sie können den Agenten stattdessen dazu bringen, seine eigenen legitimen Berechtigungen auf unbeabsichtigte Weise zu nutzen.
Forschende haben Fälle beobachtet, in denen Agenten dazu gebracht wurden:
- interne Zusammenfassungen an externe Ziele zu senden
- Dateien außerhalb des vorgesehenen Aufgabenbereichs zu verändern
- Workflows auf Basis irreführenden Kontexts auszulösen
In den Logs wirken diese Aktionen autorisiert und normal, was die Aufarbeitung nach einem Vorfall erschwert.
3 Persistenter Kontext und Memory Poisoning
Manche Agenten verfügen über ein Langzeitgedächtnis, um bessere Ergebnisse zu liefern.
So nützlich das ist, es bringt ein neues Risiko mit sich: Schädliche Anweisungen können gespeichert und später erneut verwendet werden. Einmal eingebettet, können sie Entscheidungen noch lange nach der ursprünglichen Interaktion beeinflussen. Aus einer einmaligen Injection wird so ein dauerhafter Verhaltensfehler.
4 Ein Lieferkettenproblem in Marktplätzen für KI-Skills
Da KI-Agenten immer erweiterbarer werden, setzen viele Ökosysteme inzwischen auf Skills-Marktplätze und -Repositories, über die Nutzende Funktionen von Drittanbietern installieren und den Funktionsumfang eines Agenten erweitern können.
Das beschleunigt Innovation, bringt aber ein bekanntes und zugleich verschärftes Risiko mit sich: die Kompromittierung der Lieferkette, übertragen in einen KI-nativen Kontext.
Beim Skills-Marktplatz ClawHub von OpenClaw wurde die Offenheit selbst zur Angriffsfläche. Ein groß angelegtes Sicherheitsaudit von Koi Security untersuchte 2.857 veröffentlichte Skills und deckte 341 schädliche Einträge auf, verteilt über mehrere koordinierte Kampagnen. Die später ClawHavoc genannte Operation ist eines der deutlichsten Beispiele für Lieferkettenmissbrauch, der sich direkt gegen KI-Agenten richtet.
Statt Softwareschwachstellen auszunutzen, setzten die Angreifenden fast ausschließlich auf Social Engineering: Sie entwarfen Skills, die legitim und nützlich wirkten, und brachten Nutzende dann dazu, „Setup“- oder „Voraussetzungs“-Skripte auszuführen.
Einmal installiert, ermöglichten diese Skills eine ganze Reihe schädlicher Verhaltensweisen, darunter:
- Auslieferung von macOS-Schadsoftware (vor allem Atomic Stealer)
- Nachahmung legitimer Tools wie Krypto-Werkzeugen, Finanz-Bots, YouTube-Automatisierungen und Auto-Updatern
- Typosquatting-Angriffe mit täuschenden Namen wie clawhubb oder cllawhub, die vertrauenswürdige Pakete imitieren
- Reverse Shells, eingebettet in ansonsten funktionierenden Skill-Code
- Abfluss von Zugangsdaten, gezielt aus Umgebungsdateien, die KI-Agenten nutzen
Aus Sicht der Nutzenden funktionierte der Agent scheinbar völlig normal. Im Hintergrund war die Agenten-Umgebung jedoch längst kompromittiert.
Abwehr in Arbeit?
Agent-Injection-Angriffe stehen in den OWASP Top 10 für Anwendungen mit großen Sprachmodellen auf Platz eins der Risiken. Das zeigt, warum man KI-Agenten nicht blind vertrauen darf.
Diese Angriffe gelingen häufig über Social Engineering: Sie nutzen Annahmen der Nutzenden, geteilte Aufmerksamkeit und ein übermäßiges Vertrauen in das Verhalten der Agenten aus, nicht technische Fehler.
Je mehr Entscheidungen und Handlungen an KI-Agenten delegiert werden, desto stärker wird Sicherheit zu einem menschlichen und nicht nur zu einem technischen Problem. Agentenaktionen zu überprüfen, implizites Vertrauen zu begrenzen und Skepsis gegenüber agentengenerierten Anweisungen zu bewahren, sind entscheidende Schutzmaßnahmen in Umgebungen, in denen Überredung wirksamer sein kann als ein technischer Exploit.
Die Security-Community reagiert: Sandbox-Ausführungsumgebungen, Agenten-Monitoring und Human-in-the-Loop-Kontrollpunkte werden zum Standard. Doch technische Schutzmaßnahmen reichen nur so weit.
Der menschliche Faktor verschwindet nicht, wenn Agenten mehr Entscheidungen übernehmen, er verschiebt sich. Die Frage ist, ob Unternehmen diese Verschiebung früher erkennen als die Angreifenden.
.avif)




.avif)