Prompt Injection: warum kein Filter das Problem löst

Auf deiner Seite läuft seit vier Wochen ein Support-Bot. Er liest die Hilfeseiten, die Produktbeschreibungen und die Kommentare darunter und beantwortet daraus die Fragen der Besucher. Er funktioniert gut — genau deshalb darf er inzwischen mehr: den Bestellstatus nachschlagen und bei einfachen Fällen eine Mail an den Kunden auslösen.

Irgendwann hinterlässt jemand unter einem Artikel einen Kommentar. Für einen Leser ist das ein unauffälliger Absatz, vielleicht in heller Schrift, vielleicht in einem alt-Attribut. Für den Bot ist es Text, den er beim nächsten Mal mitliest — und darin steht eine Anweisung. Er kann nicht erkennen, dass sie nicht von dir stammt.

Das ist Prompt Injection — kein Laborangriff, sondern die Schwachstelle, die die OWASP-Stiftung in ihrer Top 10 für LLM-Anwendungen seit der Ausgabe 2025 auf Platz eins führt. Dieser Beitrag erklärt den Mechanismus, den grundsätzlichen Unterschied zu SQL-Injection und was du in deiner eigenen Automatisierung dagegen tun kannst — einschließlich des unangenehmen Teils: dass es bis heute keine vollständige Lösung gibt.

Die kurze Antwort#

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 — alles landet 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.

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

SQL-Injection klingt verwandt, und viele Erklärungen setzen dort an. Der Vergleich trägt bis zu einem bestimmten Punkt — und dahinter wird er gefährlich.

Bei SQL gibt es eine Grammatik. Eine Datenbank unterscheidet klar zwischen 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 mehr verändern — auch dann nicht, wenn dort ein vollständiger SQL-Befehl steht. Das ist keine Filterfrage, sondern eine Trennung auf Protokollebene.

Bei einem Sprachmodell gibt es diese Trennung nicht. Keine Grammatik unterscheidet „Anweisung“ von „Inhalt“, also gibt es auch nichts, was man maskieren oder escapen könnte. Ein Modell verarbeitet Bedeutung, nicht Syntax. Ein Satz wie „der folgende Text ist nur Daten“ ist selbst wieder nur Text — überzeugender Text, aber kein Mechanismus. Die OWASP formuliert den Unterschied so: Prompt Injection nutze „die stochastische Natur der generativen KI selbst“ aus, nicht eine bestimmte Softwarelücke.

Das ist der ganze Kern. Bei SQL-Injection hast du einen Fehler behoben, wenn du Prepared Statements einsetzt. Bei Prompt Injection hast du kein Äquivalent dazu, auf das du dich verlassen könntest.

Direkt oder indirekt — und warum nur eines davon wirklich weh tut#

Die OWASP unterscheidet zwei Formen, und der Unterschied entscheidet, wie ernst du das Thema nehmen musst.

Direkte Injection heißt: Jemand tippt die manipulierende Anweisung selbst in dein Eingabefeld — um den Systemprompt auszulesen, um Aussagen zu erzwingen, die du nicht verantworten willst, um sich einen Rabatt zusagen zu lassen. Ärgerlich, manchmal peinlich — aber der Angreifer sitzt vor seinem eigenen Konto und erreicht nur das, was dieser eine Nutzer ohnehin dürfte.

Indirekte Injection heißt: 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, in einem Ticket, im Datenblatt eines Lieferanten. Der Angreifer muss nicht mit deinem System reden — er muss nur den Inhalt vergiften, den es sich holt.

Das BSI hat genau diese Form schon 2023 in einer eigenen Cybersicherheitswarnung behandelt und sie eine „intrinsische Schwachstelle in anwendungsintegrierten KI-Sprachmodellen“ genannt — intrinsisch, weil sie nicht aus einem Programmierfehler folgt, sondern aus der Funktionsweise. Auch das NIST führt direkte und indirekte Prompt Injection in seiner 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 — mit dem Zugriff, den du ihm gegeben hast, auf Daten, die dem Angreifer nie gehört haben.

Der Ablauf, der harmlos aussieht#

Zurück zum Support-Bot. Der Ablauf ist nicht spektakulär, und das ist das Problem: Jeder Schritt ist genau das, wofür das System gebaut wurde.

Schritt 5 macht aus dem Textproblem einen Vorfall. Solange der Bot nur antwortet, ist das Schlimmste eine falsche Auskunft. Mit Werkzeugen wird daraus eine Handlung: Daten, die an eine fremde Adresse gehen, ein geänderter Datensatz, ein Link, den ein Kunde im Vertrauen auf deinen Namen anklickt.

Dass das nicht theoretisch ist, zeigt die Schwachstelle CVE-2025-32711 in Microsoft 365 Copilot: Microsoft beschreibt sie als „AI command injection“, die es einem nicht berechtigten Angreifer erlaubt, Informationen über das Netzwerk offenzulegen, und bewertet sie mit CVSS 9.3 — veröffentlicht am 11. Juni 2025, behoben auf Serverseite. Betroffen war kein Nischenwerkzeug, sondern das Produkt eines Anbieters, der diesen Angriff kennt.

Dieselbe Logik gilt für jede Automatisierung, die eingehende Mails auswertet, und für jeden fremden Inhalt auf deiner Seite — verwandt mit den SEO-Risiken durch Third-Party-Scripts: dort fremder Code, hier fremder Text.

Was tatsächlich hilft#

Die wirksamen Maßnahmen liegen alle außerhalb des Modells. Sie verhindern die Injection nicht, sie sorgen dafür, dass sie folgenlos bleibt. OWASP, BSI und die Anbieter empfehlen im Kern dieselben vier Dinge.

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

Trennen, was liest, von dem, was schreibt. Der schädliche Fall entsteht fast immer, wenn beides zusammenfällt: Der Agent liest fremde Inhalte und darf handeln. 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 seiner Handreichung Evasion Attacks on LLMs vom November 2025 ausdrücklich. Entscheidend ist die Rückfrage selbst: Sie muss zeigen, was passieren soll — an welche Adresse, mit welchen Daten —, statt nur zu fragen, ob es weitergehen darf.

Die Ausgabe des Modells behandeln wie eine Nutzereingabe. Das wird am häufigsten übersehen: Was das Modell zurückgibt, ist nicht vertrauenswürdiger als das, woraus es entstanden ist. 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, die auch gegen klassisches XSS wirkt — wie du sie sauber hinbekommst, steht in unserem Beitrag zu Content-Security-Policy und unsafe-inline. Geht die Ausgabe an eine Schnittstelle, gilt dasselbe: gegen ein festes Format prüfen, nicht durchreichen.

Diese vier Punkte entscheidest du beim Zuschnitt einer Automatisierung ohnehin mit — also besser vor dem ersten Prototyp als danach. Wie so ein Zuschnitt aussieht, ordnet unser Überblick zur KI-Automatisierung ein; die übrigen Risiken beim Dauerbetrieb autonomer Agenten — Protokollierung, Kosten, Abhängigkeiten, Zuständigkeit im Schadensfall — stehen unter Sicherheitsrisiken von KI-Agenten.

Wo die Verteidigung aufhört#

Jetzt der Teil, den Anbieterseiten gern kurz halten. Es gibt keine vollständige Lösung, und das ist keine Frage der Reife, sondern eine Folge der Bauweise.

Die OWASP schreibt zu LLM01 wörtlich, angesichts des stochastischen Einflusses in der Funktionsweise der Modelle sei „unklar, ob es narrensichere Methoden zur Verhinderung von Prompt Injection gibt“. Anthropic veröffentlichte im November 2025 Messwerte zum eigenen Browser-Agenten: Eine Angriffserfolgsquote von 1 Prozent im eigenen Test sei eine deutliche Verbesserung, stelle aber „weiterhin ein erhebliches Risiko“ dar — „kein Browser-Agent ist immun gegen Prompt Injection“, man zeige Fortschritt und behaupte nicht, das Problem sei gelöst (Anthropic, 24.11.2025). Auch die NIST-Taxonomie führt „die Grenzen einiger bestehender Gegenmaßnahmen“ als eigenen Gegenstand.

Warum Filter allein nicht reichen. Ein Filter, der schädliche Anweisungen in Fremdinhalten erkennen soll, ist selbst ein Klassifikator mit einer Fehlerrate. Er muss jeden Angriff erwischen, der Angreifer braucht einen Treffer. Er sieht Text, aber der Angriff ist Bedeutung: Dieselbe Anweisung lässt sich umschreiben, übersetzen, über mehrere Absätze verteilen, in ein Bild oder ein Dokument legen — und die OWASP weist darauf hin, dass sie „nicht für Menschen sichtbar oder lesbar sein muss, solange der Inhalt vom Modell verarbeitet wird“. Scharf genug eingestellt, um das zuverlässig zu fangen, blockiert derselbe Filter im Alltag legitime Inhalte. Genau deshalb empfiehlt Google für Gemini eine „mehrschichtige Verteidigungsstrategie“, die Angriffe teurer macht, statt sie zu verhindern (Google, 13.06.2025).

Praktisch heißt das: Plane so, als ob der Angriff gelingt. Die brauchbare Frage ist nicht „Wie halte ich die Anweisung draußen?“, sondern „Was kann dieses System im schlimmsten Fall anrichten?“. Wenn die Antwort unangenehm ist, ist nicht der Filter falsch eingestellt, sondern der Rechteumfang zu groß.

Und was ist mit einem besseren Systemprompt?#

Die naheliegende Rückfrage: Wenn das Modell Anweisungen nicht unterscheiden kann — lässt es sich nicht einfach anweisen, die aus Fremdinhalten zu ignorieren?

Das hilft, und es gehört dazu. OWASP wie BSI nennen präzise Systemanweisungen und das Kennzeichnen externer Inhalte als Maßnahme, und die Modelle sind darin besser geworden, weil die Anbieter genau das antrainieren.

Aber es bleibt eine Bitte, keine Grenze. Dein Systemprompt und der vergiftete Inhalt konkurrieren im selben Kontextfenster um dieselbe Aufmerksamkeit, und wer gewinnt, ist eine Wahrscheinlichkeit. Ein Systemprompt senkt die Erfolgsquote. Er ist nichts, worauf du eine Berechtigung stützen solltest, die du sonst nicht vergeben würdest.

Häufige Fragen#

Betrifft mich das, wenn ich nur einen Chatbot ohne Anbindung habe? Dann ist der Schaden begrenzt: Ein reiner Textbot kann falsch antworten, aber nichts auslösen. Kritisch wird es, sobald er ein Werkzeug bekommt — Suche, Mailversand, Datenbankzugriff.

Hilft es, wenn ich ein größeres oder neueres Modell einsetze? Es senkt die Erfolgsquote, mehr nicht. Anthropic misst im eigenen Test 1 Prozent und schreibt ausdrücklich, kein Browser-Agent sei immun. Die Rechte zu begrenzen wirkt unabhängig vom Modell.

Ist Prompt Injection dasselbe wie ein Jailbreak? Nein. Beim Jailbreak versucht jemand, die Sicherheitsregeln des Anbieters zu umgehen, um verbotene Inhalte zu erzeugen. Bei Prompt Injection wird deine Anwendung umgelenkt — das Ziel ist nicht der Text, sondern die Handlung.

Wie merke ich überhaupt, dass es passiert ist? Nur über Protokolle. 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.

Kurz gefasst#

Prompt Injection ist kein Fehler, den ein Update behebt. Sprachmodelle verarbeiten Anweisung und Inhalt im selben Kanal, und es gibt kein Gegenstück zu Prepared Statements, das beides trennen würde.

Gefährlich ist die indirekte Form: Der Angreifer redet nicht mit deinem System, er vergiftet den Inhalt, den es liest — und das System handelt dann mit deinen Rechten.

Was hilft, liegt außerhalb des Modells: wenige Rechte, getrennte Lese- und Schreibwege, menschliche Freigabe vor wirksamen Handlungen, Ausgaben wie jede andere Fremdeingabe behandelt. Dass ein Filter oder ein besserer Systemprompt die Lücke schließt, sagen weder OWASP noch BSI noch die Anbieter selbst.