Schutz vor Prompt Injection in RAG-Systemen und KI-Agenten

KI-Agenten mit Werkzeugliste, Freigaben und Protokoll WZ-IT baut KI-Agenten und interne Assistenten, bei denen erlaubte Aktionen explizit definiert sind, kritische Schritte eine menschliche Freigabe brauchen und jede Aktion protokolliert wird. Eingehende Inhalte aus E-Mails und Dokumenten werden als Daten behandelt, nicht als Anweisungen. KI-Agenten ansehen · Interne KI-Assistenten

Ein RAG-System liest Dokumente, ein KI-Agent liest E-Mails, Tickets und Webseiten. Jeder dieser Texte kann Anweisungen enthalten, die das Modell befolgt, obwohl sie niemand Berechtigtes geschrieben hat. Das ist Prompt Injection, und sie steht in der OWASP Top 10 for LLM Applications 2026 wieder auf Platz eins. Dieser Artikel erklärt, wie direkte und indirekte Injection wirken, warum Filter das Problem nicht lösen und welche Architekturentscheidungen den Schaden begrenzen, wenn ein Angriff gelingt. Stand Oktober 2026.

Inhaltsverzeichnis

• Was Prompt Injection ist
• Direkt und indirekt: woher die Anweisungen kommen
• Warum Filter das Problem nicht lösen
• Einordnung nach OWASP
• Die entscheidende Kombination: Daten, fremde Inhalte, Außenwirkung
• Architekturmaßnahmen im Überblick
• Besonderheiten bei RAG-Systemen
• Besonderheiten bei KI-Agenten und MCP
• Erkennungswerkzeuge als zusätzliche Schicht
• Testen und überwachen

Was Prompt Injection ist

OWASP beschreibt Prompt Injection als Eingabe, die das Verhalten eines Sprachmodells auf eine Weise verändert, die der Entwickler der Anwendung nicht beabsichtigt hat. Die Eingabe kann Text des Benutzers sein, ein abgerufener Dokumentabschnitt, die Ausgabe eines Werkzeugs, ein Bild, eine Tonspur oder ein Eintrag im Langzeitgedächtnis eines Agenten (OWASP, LLM01:2026). Sie muss für Menschen weder lesbar noch sichtbar sein.

Der Grund liegt in der Funktionsweise der Modelle. Systemprompt, Benutzerfrage, abgerufene Dokumente und Werkzeugausgaben landen in einem einzigen Kontextfenster, als ein Strom von Tokens. Eine strukturelle Grenze zwischen „Anweisung" und „Daten" gibt es nicht. Das britische NCSC formuliert es so: Im Inneren eines LLM gibt es keine Unterscheidung zwischen Daten und Anweisungen, es gibt nur das nächste Token (NCSC, Prompt injection is not SQL injection, Dezember 2025).

Daraus folgt der wichtigste Unterschied zur SQL Injection. Gegen SQL Injection gibt es mit parametrisierten Abfragen eine Lösung, die das Problem an der Wurzel beseitigt. Ein Gegenstück dazu existiert für Sprachmodelle derzeit nicht. OWASP, NCSC und NIST kommen übereinstimmend zu dem Schluss, dass es heute keinen zuverlässigen Mechanismus gibt, der Prompt Injection verhindert. Die Verteidigung ist deshalb architektonisch: Das System wird so gebaut, dass eine gelungene Injection keinen ernsthaften Schaden anrichten kann.

Direkt und indirekt: woher die Anweisungen kommen

Der Begriff der indirekten Prompt Injection geht auf eine Arbeit von Greshake und anderen aus dem Februar 2023 zurück, die solche Angriffe unter anderem gegen den GPT-4-basierten Bing Chat demonstrierte (Greshake et al., arXiv 2302.12173). Das Muster ist seitdem dasselbe: Der Angreifer muss das Backend nicht kompromittieren. Er legt Text dort ab, wo das Modell ihn später liest, und das Modell erledigt den Rest mit den Rechten des Benutzers.

OWASP unterscheidet die Quellen indirekter Injection nach Vertrauensstufe (OWASP, LLM01:2026):

Die dritte Zeile wird am häufigsten unterschätzt. Ein internes Ticketsystem gilt als vertrauenswürdig, enthält aber Text, den Externe über ein Formular eingegeben haben. Liest ein Agent dieses Ticket mit Schreibrechten auf andere Systeme, handelt er auf Anweisung eines Fremden. Hinzu kommen Varianten, die Filter gezielt umgehen: Anweisungen in Bildern, unsichtbare Unicode-Zeichen, Base64-kodierte Texte oder Sprachen, auf die ein Klassifikator nicht trainiert ist.

Warum Filter das Problem nicht lösen

Der naheliegende Ansatz ist ein Filter vor dem Modell, der verdächtige Eingaben erkennt. Solche Filter haben ihren Platz, aber sie tragen nicht die Sicherheit.

Adaptive Angriffe. Nasr und andere haben 12 veröffentlichte Abwehrverfahren gegen Jailbreaks und Prompt Injection mit Angriffen getestet, die gezielt auf das jeweilige Verfahren optimiert wurden. Bei den meisten lag die Erfolgsquote über 90 Prozent, obwohl die Verfahren in ihren ursprünglichen Tests nahezu keine erfolgreichen Angriffe zugelassen hatten (Nasr et al., The Attacker Moves Second, arXiv 2510.09023).

Die Quote ist nicht das Maß. Ein Filter, der 95 Prozent der Angriffe erkennt, ist in der Anwendungssicherheit ein ungenügendes Ergebnis, weil der Angreifer so lange variiert, bis er in den verbleibenden 5 Prozent landet (Simon Willison, The lethal trifecta).

Markierungen lassen sich nachahmen. Verfahren, die externe Inhalte kennzeichnen, damit das Modell sie als Daten erkennt, senken die Erfolgsquote nachweislich. Für das Spotlighting-Verfahren von Microsoft berichteten die Autoren einen Rückgang von über 50 auf unter 2 Prozent (Hines et al., arXiv 2403.14720). OWASP weist aber darauf hin, dass solche Ergebnisse aus nicht adaptiven Tests stammen und ein Angreifer, der das Markierungsschema kennt, es nachahmen kann.

Die Konsequenz zieht das NCSC: Prompt Injection wird wahrscheinlich nie vollständig beseitigt. Ziel ist, die Wahrscheinlichkeit zu senken und vor allem die Wirkung zu begrenzen. Der Leitsatz dafür: Verarbeitet ein Modell Inhalte einer Partei, sinken seine Rechte auf die Rechte dieser Partei (NCSC).

Einordnung nach OWASP

Die aktuelle Fassung ist die OWASP Top 10 for LLM Applications 2026, veröffentlicht im August 2026. Gegenüber der Ausgabe 2025 hat sich die Reihenfolge deutlich verschoben. Für Prompt Injection sind drei Einträge zusammen zu lesen:

OWASP beschreibt das Zusammenspiel ausdrücklich: Die meisten Vorfälle mit hoher Schadenswirkung wurden schwerwiegend, weil die Injection in einem System landete, dessen Werkzeuge, Berechtigungen oder Darstellungsfunktionen das kompromittierte Modell im Namen des Benutzers handeln ließen.

Sobald ein Modell nicht mehr nur antwortet, sondern Werkzeuge aufruft und Gedächtnis über Sitzungen hinweg führt, verweist OWASP zusätzlich auf die OWASP Top 10 for Agentic Applications 2026 vom Dezember 2025. Dort sind vor allem ASI01 Agent Goal Hijack (Ziele des Agenten werden umgelenkt), ASI02 Tool Misuse and Exploitation, ASI03 Identity and Privilege Abuse und ASI06 Memory & Context Poisoning relevant.

Die entscheidende Kombination: Daten, fremde Inhalte, Außenwirkung

Zwei Entwurfsregeln haben sich als Prüfung vor dem Betrieb durchgesetzt, und beide nennt OWASP. Simon Willison beschreibt die „lethal trifecta": Ein Agent, der gleichzeitig Zugriff auf private Daten hat, nicht vertrauenswürdige Inhalte verarbeitet und nach außen kommunizieren kann, lässt sich zum Datenabfluss bringen (Willison, Juni 2025). Meta hat daraus im Oktober 2025 die Agents Rule of Two abgeleitet: Ein Agent soll innerhalb einer Sitzung höchstens zwei der drei Eigenschaften haben.

Legende: (A) nicht vertrauenswürdige Eingaben, (B) Zugriff auf sensible Systeme oder private Daten, (C) Zustand verändern oder nach außen kommunizieren.

Der praktische Wert der Regel liegt darin, dass sie eine Entscheidung erzwingt, bevor gebaut wird. Häufig lässt sich eine Aufgabe so schneiden, dass eine Eigenschaft wegfällt: Der Agent entwirft die Antwort, ein Mensch versendet sie. Oder die Zusammenfassung fremder E-Mails läuft in einer eigenen Sitzung ohne Zugriff auf das CRM.

Architekturmaßnahmen im Überblick

Keine Maßnahme reicht allein. OWASP unterscheidet zwischen Maßnahmen, die die Erfolgsquote senken und gegen adaptive Angreifer nachlassen, und Maßnahmen, die die Wirkung einer gelungenen Injection begrenzen. Die zweite Gruppe trägt die Sicherheit.

Quelle der Gliederung: OWASP, LLM01:2026, Prevention and Mitigation Strategies.

Einen Schritt weiter geht der Ansatz, Steuerfluss und Datenfluss vollständig zu trennen. Bei CaMeL (Debenedetti und andere, 2025) plant ein privilegiertes Modell den Ablauf nur aus der Anfrage des Benutzers; nicht vertrauenswürdige Inhalte werden von einem zweiten Modell ohne Werkzeugzugriff verarbeitet und können den Ablauf nicht mehr verändern. Im Benchmark AgentDojo löste das System 77 Prozent der Aufgaben mit nachweisbarer Sicherheit, gegenüber 84 Prozent ohne Schutz (Debenedetti et al., arXiv 2503.18813). Für einzelne Agenten mit klar umrissenem Auftrag lässt sich dasselbe Prinzip auch ohne Forschungsframework umsetzen: Der Ablauf steht im Code fest, das Modell füllt Felder.

Besonderheiten bei RAG-Systemen

Ein RAG-System ohne Werkzeuge kann keine Aktionen auslösen, ist aber nicht immun. Drei Wege bleiben offen.

Manipulierte Antworten. Ein präparierter Abschnitt im Index ändert die Antwort für jeden, dessen Frage ihn abruft. OWASP zitiert eine Untersuchung, in der fünf präparierte Dokumente in einer Wissensbasis mit Millionen Texten für rund 90 Prozent Angriffserfolg genügten. Gegenmaßnahme ist Kontrolle darüber, wer Inhalte in den Index bringt: Quellen mit externem Schreibzugriff (Ticketsysteme, geteilte Ordner, Webseiten) gehören getrennt bewertet und gekennzeichnet.

Preisgabe von Kontext. Was im Kontext liegt, kann in der Antwort landen. Deshalb gehören Berechtigungen vor die Suche, nicht in den Prompt. Ein Abschnitt, den der Benutzer nicht sehen darf, darf gar nicht erst abgerufen werden. Die Mechanik dahinter beschreibt RAG mit Berechtigungen.

Abfluss über die Darstellung. Rendert die Oberfläche Markdown-Bilder, kann eine eingeschleuste Anweisung das Modell dazu bringen, ein Bild mit einer URL auszugeben, die Gesprächsinhalte als Parameter an einen fremden Server überträgt. Der Benutzer sieht nur ein Bild oder gar nichts. Wirksam ist hier nur eine Einstellung in der Anwendung: keine externen Bilder laden oder nur Ziele aus einer Allowlist zulassen.

Wer die Antworten eines RAG-Systems systematisch prüft, sollte präparierte Dokumente in den Testbestand aufnehmen. Wie ein solcher Testbestand aufgebaut wird, zeigt RAG-Qualität messen.

Besonderheiten bei KI-Agenten und MCP

Bei Agenten entscheidet der Werkzeugzugang über die Schadenshöhe. OWASP beschreibt Fälle, in denen ein Agent über ein präpariertes GitHub-Issue private Repositories preisgab oder über einen MCP-Server mit Administratorrechten eine Produktionsdatenbank ausgab, unter Umgehung der Row-Level Security. In beiden Fällen lag die Anweisung in einem Kanal, den ein Externer befüllen konnte, und der Agent führte sie mit den Rechten des Entwicklers aus.

Daraus ergeben sich vier Regeln für Agenten:

1. Rechte im Zielsystem durchsetzen. Der Agent ruft reguläre Schnittstellen mit eng geschnittenen Rechten auf. Die Prüfung, ob eine Aktion erlaubt ist, findet im Zielsystem oder in deterministischem Anwendungscode statt, nicht im Modell. Wie Identität, Werkzeugkatalog und Freigaben zusammenspielen, beschreibt KI-Agenten: Rechte und Freigaben.
2. Freigabe mit der exakten Aktion. Wer zustimmt, sieht den konkreten Empfänger, den konkreten Text, die konkreten Parameter, nicht eine Zusammenfassung des Modells.
3. Gedächtnis als privilegierte Schreiboperation. Ein Eintrag im Langzeitgedächtnis wirkt in jeder späteren Sitzung. Schreibvorgänge dorthin werden protokolliert und bei anweisungsartigem Inhalt freigegeben.
4. MCP-Server wie Software-Abhängigkeiten behandeln. Version festlegen, Herkunft prüfen, Werkzeugbeschreibungen auf versteckte Anweisungen durchsehen. Werkzeugbeschreibungen landen im Kontext und können selbst Injection enthalten. Mehr dazu in MCP im Unternehmen.

Ein MCP-Server, der lokal Befehle ausführt, ist faktisch Codeausführung auf dem Host. Dass auch die Gateways selbst angreifbar sind, zeigt die LiteLLM-Sicherheitslücke vom September 2026.

Erkennungswerkzeuge als zusätzliche Schicht

Erkennungswerkzeuge senken die Wahrscheinlichkeit erfolgreicher Angriffe und liefern Signale fürs Monitoring. Sie ersetzen keine der Architekturmaßnahmen.

Stand Oktober 2026. Das Kontextfenster von 512 Tokens bedeutet, dass längere Dokumente in Abschnitten geprüft werden müssen. Die Llama 4 Community License ist bei der Lizenzprüfung zu berücksichtigen; worauf es dabei ankommt, beschreibt LLM-Lizenzen für die kommerzielle Nutzung.

Testen und überwachen

Testen gegen adaptive Angreifer. OWASP empfiehlt, Abwehrmaßnahmen mit Testern zu prüfen, die die Verteidigung kennen, und statische Erfolgsquoten nicht als Nachweis zu akzeptieren. Als Ausgangsbasis nennt OWASP den Benchmark AgentDojo. Für die eigene Anwendung zählt vor allem ein Testbestand aus präparierten E-Mails, Dokumenten und Tickets, die zu den tatsächlich angebundenen Quellen passen.

Protokollieren. Jeder Werkzeugaufruf wird mit Auslöser, ausführender Identität, Parametern und Ergebnis festgehalten, zusammen mit den Inhalten, die im Kontext lagen. Fehlgeschlagene und abgelehnte Werkzeugaufrufe sind ein Signal, das das NCSC ausdrücklich zur Überwachung nennt. Langfuse zeichnet solche Läufe als Traces auf eigener Infrastruktur auf (Was ist Langfuse?).

Änderungen kontrollieren. Ein Modellwechsel, ein neuer Systemprompt oder ein neues Werkzeug ändert die Angriffsfläche. Die Injection-Testfälle gehören deshalb in dieselbe Regressionsprüfung wie die fachlichen Testfragen.

Was das für Ihr Projekt heißt

Prompt Injection wird bei der Auswahl des Modells nicht gelöst, sondern beim Zuschnitt des Systems. Die Fragen, die vor dem Bau beantwortet sein sollten: Welche Quellen kann ein Externer befüllen? Welche Daten erreicht das System? Was kann es nach außen bewirken? Wo eine Aufgabe alle drei braucht, gehört eine menschliche Freigabe in den Ablauf.

Bei den KI-Agenten von WZ-IT sind erlaubte Aktionen explizit definiert, kritische Schritte brauchen eine menschliche Freigabe, und jede Aktion wird mit Trace protokolliert. Eingehende Inhalte aus E-Mails und Dokumenten werden als Daten behandelt; Werkzeugauswahl und Freigabelogik hängen nicht am Text des Absenders. Für interne Assistenten greifen Berechtigungen vor der Suche. Modelle laufen auf dem AI Cube oder auf Managed GPU-Servern von WZ-IT. Support, Beratung und Implementierung durch WZ-IT.

Wie Agenten und Automatisierung grundsätzlich einzuordnen sind, erklärt KI-Agenten & Automatisierung. Wenn Agenten Datenbanken abfragen, ist Text-to-SQL der nächste Schritt, mit eigenen Anforderungen an Leserechte und Validierung. Einen Vergleich gängiger Frameworks aus Betreibersicht bietet der Beitrag zu KI-Agenten-Frameworks.

Quellen

• OWASP Top 10 for LLM Applications 2026
• OWASP LLM01:2025 Prompt Injection
• OWASP Top 10 for Agentic Applications 2026
• NCSC: Prompt injection is not SQL injection (Dezember 2025)
• Meta: Agents Rule of Two (Oktober 2025)
• Simon Willison: The lethal trifecta for AI agents (Juni 2025)
• Greshake et al.: Indirect Prompt Injection (arXiv 2302.12173)
• Nasr et al.: The Attacker Moves Second (arXiv 2510.09023)
• Hines et al.: Spotlighting (arXiv 2403.14720)
• Debenedetti et al.: Defeating Prompt Injections by Design, CaMeL (arXiv 2503.18813)
• Debenedetti et al.: AgentDojo (arXiv 2406.13352)
• Meta: Llama Prompt Guard 2 Model Card
• Meta: LlamaFirewall (arXiv 2505.03574)
• NIST AI 100-2 E2025: Adversarial Machine Learning