Prompt Injection: warum kein Filter das Problem löst

Prompt Injection steht in der OWASP Top 10 für LLM-Anwendungen seit der Ausgabe 2025 auf Platz 1. Der Grund ist kein Programmierfehler, sondern die Bauweise: Ein Sprachmodell bekommt alles, was es verarbeiten soll, als einen einzigen Strom von Text. Deine Systemanweisung, die Frage des Nutzers, der Seiteninhalt, die Mail, das hochgeladene PDF landen im selben Kontextfenster. Es gibt keinen Kanal für Anweisungen und einen zweiten für Daten. Das Modell entscheidet aus dem Text heraus, was davon Befehl ist.

Wer Inhalte in diesen Strom bekommt, kann also Anweisungen platzieren. Verteidigung heißt deshalb nicht, den Angriff zu verhindern, sondern den Schaden zu begrenzen, falls er gelingt. Das ist der ganze Beitrag; der Rest sind Belege und die vier Maßnahmen.

Warum der Vergleich mit SQL-Injection in die Irre führt#

Bei SQL gibt es eine Grammatik. Eine Datenbank unterscheidet Befehl und Wert, deshalb lässt sich das Problem technisch abschließen: Mit Prepared Statements geht die Abfrage einmal als Struktur an die Datenbank, die Werte kommen getrennt hinterher. Was im Wert steht, kann die Struktur nicht verändern, auch wenn dort ein vollständiger SQL-Befehl steht.

Bei einem Sprachmodell gibt es diese Trennung nicht. Keine Grammatik unterscheidet „Anweisung“ von „Inhalt“, also gibt es nichts, was man maskieren könnte. Ein Satz wie „der folgende Text ist nur Daten“ ist selbst wieder nur Text. OWASP schreibt, Prompt Injection nutze die stochastische Natur der generativen KI selbst aus, nicht eine bestimmte Softwarelücke. Bei SQL-Injection hast du mit Prepared Statements einen Fehler behoben. Bei Prompt Injection hast du kein Äquivalent, auf das du dich verlassen könntest.

Generative AI's Greatest Flaw - Computerphile – Video abspielen (lädt YouTube)

Direkt oder indirekt#

OWASP unterscheidet zwei Formen, und der Unterschied entscheidet, wie ernst das Thema für dich ist.

Direkt: Jemand tippt die manipulierende Anweisung selbst in dein Eingabefeld, um den Systemprompt auszulesen oder sich einen Rabatt zusagen zu lassen. Der Angreifer sitzt vor seinem eigenen Konto und erreicht, was dieser eine Nutzer ohnehin dürfte.

Indirekt: Die Anweisung steht in einem Inhalt, den dein System später von sich aus liest. Auf einer Seite, die der Agent abruft. In einer Mail, die er zusammenfasst. In einem Dokument, das ein Kunde hochlädt. Das BSI hat diese Form 2023 in einer eigenen Cybersicherheitswarnung als „intrinsische Schwachstelle in anwendungsintegrierten KI-Sprachmodellen“ bezeichnet; das NIST führt beide Formen in der Angriffstaxonomie AI 100-2e2025 vom März 2025.

Der praktische Unterschied ist die Rechtelage. Direkt handelt der Bot mit den Rechten des Angreifers. Indirekt handelt er mit deinen.

Solange der Bot nur antwortet, ist das Schlimmste eine falsche Auskunft. Mit Werkzeugen wird daraus eine Handlung: Daten an eine fremde Adresse, ein geänderter Datensatz, ein Link, den ein Kunde im Vertrauen auf deinen Namen anklickt. Dass das nicht theoretisch ist, zeigt CVE-2025-32711 in Microsoft 365 Copilot: Microsoft beschreibt sie als „AI command injection“, die einem nicht berechtigten Angreifer erlaubt, Informationen über das Netzwerk offenzulegen, bewertet mit CVSS 9.3, veröffentlicht am 11. Juni 2025 und serverseitig behoben. Betroffen war das Produkt eines Anbieters, der diesen Angriff kennt.

Vier Maßnahmen, die außerhalb des Modells liegen#

OWASP, BSI und die Anbieter empfehlen im Kern dasselbe. Keine der Maßnahmen verhindert die Injection, alle sorgen dafür, dass sie folgenlos bleibt.

Rechte auf die einzelne Aufgabe begrenzen. Ein Support-Bot, der Bestellstatus nachschlägt, braucht ein Konto, das Bestellstatus lesen darf; nicht das Kundenkonto, nicht den Mail-Ausgang, nicht das CMS. Das ist die einzige Maßnahme der Liste, die auch gegen Angriffe hilft, die du noch nicht kennst.

Lesen von Schreiben trennen. Der schädliche Fall entsteht, wenn der Agent fremde Inhalte liest und handeln darf. Zwei getrennte Läufe mit getrennten Zugängen brechen die Kette: Der lesende Teil hat keine Werkzeuge, der handelnde bekommt keine ungeprüften Fremdinhalte in den Kontext.

Vor wirksamen Handlungen bestätigen lassen. Alles, was Geld bewegt, Daten nach außen gibt oder etwas unwiderruflich ändert, gehört hinter eine menschliche Freigabe. Das BSI nennt die „explizite Bestätigung durch Nutzer vor der Ausführung von LLM-Funktionen“ in Evasion Attacks on LLMs vom November 2025 ausdrücklich. Die Rückfrage muss zeigen, was passieren soll (an welche Adresse, mit welchen Daten), nicht nur fragen, ob es weitergehen darf.

Die Ausgabe des Modells wie eine Nutzereingabe behandeln. Was das Modell zurückgibt, ist nicht vertrauenswürdiger als das, woraus es entstand. Renderst du die Antwort in deiner Seite, ist sie eine Fremdeingabe wie jedes Kommentarfeld: escapen, keine ungeprüften Links, kein HTML direkt ins DOM. Eine Content-Security-Policy ohne 'unsafe-inline' ist hier dieselbe Absicherung wie gegen klassisches XSS, siehe unsafe-inline loswerden. Geht die Ausgabe an eine Schnittstelle, gegen ein festes Format prüfen, nicht durchreichen.

Die übrigen Risiken beim Dauerbetrieb (Protokollierung, Tokens, Abhängigkeiten) stehen unter KI-Agenten: Sicherheit und Risiken.

Was Filter und Systemprompt leisten, und was nicht#

Ein Filter, der schädliche Anweisungen in Fremdinhalten erkennen soll, ist selbst ein Klassifikator mit Fehlerrate. Er muss jeden Angriff erwischen, der Angreifer braucht einen Treffer. Er sieht Text, der Angriff ist Bedeutung: Dieselbe Anweisung lässt sich umschreiben, übersetzen, über Absätze verteilen, in ein Bild oder Dokument legen. OWASP weist darauf hin, dass sie „nicht für Menschen sichtbar oder lesbar sein muss, solange der Inhalt vom Modell verarbeitet wird“. Google empfiehlt für Gemini deshalb eine mehrschichtige Verteidigung, die Angriffe teurer macht statt sie zu verhindern (Google, 13.06.2025).

Ein Systemprompt, der das Modell anweist, Anweisungen aus Fremdinhalten zu ignorieren, hilft und gehört dazu; OWASP wie BSI nennen präzise Systemanweisungen und das Kennzeichnen externer Inhalte als Maßnahme. Es bleibt eine Bitte, keine Grenze. Systemprompt und vergifteter Inhalt konkurrieren im selben Kontextfenster, und wer gewinnt, ist eine Wahrscheinlichkeit.

Wie groß die Lücke bleibt, sagen die Anbieter selbst. Anthropic veröffentlichte im November 2025 Messwerte zum eigenen Browser-Agenten: Eine Angriffserfolgsquote von 1 Prozent im eigenen Test sei eine deutliche Verbesserung und stelle „weiterhin ein erhebliches Risiko“ dar; „kein Browser-Agent ist immun gegen Prompt Injection“ (Anthropic, 24.11.2025). OWASP schreibt zu LLM01, es sei „unklar, ob es narrensichere Methoden zur Verhinderung von Prompt Injection gibt“.

Plane also so, als ob der Angriff gelingt. Die brauchbare Frage lautet nicht „Wie halte ich die Anweisung draußen?“, sondern „Was kann dieses System im schlimmsten Fall anrichten?“. Ist die Antwort unangenehm, ist der Rechteumfang zu groß, nicht der Filter zu lasch.

Drei Abgrenzungen#

Ein reiner Textbot ohne Anbindung kann falsch antworten, aber nichts auslösen; kritisch wird es mit dem ersten Werkzeug. Ein Jailbreak ist etwas anderes: Dort umgeht jemand die Sicherheitsregeln des Anbieters, um verbotene Inhalte zu erzeugen; bei Prompt Injection wird deine Anwendung umgelenkt. Und ob es passiert ist, siehst du nur im Protokoll: Halte fest, welche Quellen in den Kontext gingen und welche Werkzeugaufrufe daraus folgten. Ohne diese zwei Angaben lässt sich hinterher nicht rekonstruieren, warum der Agent tat, was er tat.

Stand 03.10.2026. Quellen am selben Tag abgerufen.