Prompt Injection ist ein Angriff auf Anwendungen, die ein Large Language Model einsetzen: Jemand schmuggelt Anweisungen in Text, den das Modell ohnehin verarbeitet, und bringt es damit dazu, seine eigentliche Aufgabe zu verlassen. Für das Modell sieht der eingeschleuste Satz genauso aus wie die Vorgabe des Betreibers. Beides ist Text im selben Strom, und daraus entsteht die Lücke.
Der Begriff kursiert seit 2022. Ernst geworden ist er erst, als Sprachmodelle nicht mehr nur Text ausgaben, sondern Werkzeuge bedienen, Mails verschicken und in fremden Systemen lesen durften.
Warum die Lücke strukturell ist
Ein klassisches Programm kennt den Unterschied zwischen Programmcode und Nutzereingabe. Bei einem Sprachmodell gibt es diesen Unterschied nicht. Systemprompt, Nutzerfrage, abgerufenes Dokument und Werkzeugantwort landen als eine einzige Folge von Zeichen im Kontextfenster. Das Modell entscheidet dann nach Wahrscheinlichkeit, welchem Teil davon es folgt.
Der Vergleich mit SQL Injection liegt nahe, hinkt aber an der entscheidenden Stelle. Gegen SQL Injection gibt es Prepared Statements: eine harte technische Trennung von Abfrage und Wert. Für Prompts existiert nichts Vergleichbares. Man kann Rollen markieren, Trennzeichen setzen und das Modell bitten, fremde Anweisungen zu ignorieren. Das erhöht die Hürde, aber es ist eine Bitte und keine Garantie.
Daraus folgt die wichtigste Regel für den Entwurf: Der Systemprompt ist keine Sicherheitsgrenze. Er ist eine Arbeitsanweisung.
Direkte und indirekte Prompt Injection
| Variante | Woher der Text kommt | Typischer Fall |
|---|---|---|
| Direkt | Der Nutzer tippt sie selbst ein | Jemand versucht, den Systemprompt auszulesen oder Sperren aufzuheben |
| Indirekt | Aus einer Quelle, die das Modell liest | Eine Webseite, ein PDF, eine Support-Mail, ein Ticket, eine Repository-Datei |
| Gespeichert | Aus dem eigenen Gedächtnis der Anwendung | Der präparierte Text steckt in der Wissensdatenbank und wirkt bei jedem Abruf erneut |
Die indirekte Variante ist die gefährlichere, weil der Angreifer nicht am Chatfenster sitzen muss. Er legt seinen Text dort ab, wo das System später von selbst hinschaut. Ein KI-Agent, der eine Website zusammenfasst, liest die Anweisung im unsichtbaren Fließtext mit. Ein Assistent mit Retrieval Augmented Generation zieht sie aus einem hochgeladenen Dokument.
Und gespeicherte Injections sind besonders zäh: Einmal in der Vektordatenbank, wirken sie bei jeder passenden Anfrage weiter, auch lange nachdem der Angreifer weg ist.
Was dabei schiefgehen kann
Der Schaden hängt weniger vom Angriff ab als von den Rechten, die die Anwendung ihrem Modell gegeben hat.
- Datenabfluss: Das Modell hat Zugriff auf interne Dokumente oder auf den bisherigen Gesprächsverlauf und wird angewiesen, beides in eine URL zu packen, die es abruft oder als Bild einbettet. Der Inhalt landet im Log eines fremden Servers.
- Ungewollte Aktionen: Sobald Werkzeuge im Spiel sind, etwa über das Model Context Protocol, reicht eine überzeugende Anweisung, um eine Mail zu verschicken, ein Ticket zu schließen oder einen Datensatz zu ändern.
- Manipulierte Ausgabe: Eine Bewerbung enthält versteckten Text, der die Auswertung anweist, das Dokument als hervorragend geeignet einzustufen. Die Antwort sieht plausibel aus, sie ist nur gekauft.
- Ausführbare Antworten: Gibt das Modell Markdown, HTML oder Code aus und rendert die Anwendung das ungeprüft, wird aus dem Textangriff ein klassisches Cross-Site-Scripting.
Was hilft
Es gibt keine Einstellung, die das Problem abschaltet. Was es gibt, ist eine Architektur, in der ein erfolgreicher Angriff wenig anrichtet.
Im Entwurf
- Rechte klein halten. Jedes Werkzeug bekommt genau die Berechtigung, die es für seine Aufgabe braucht. Ein Assistent, der Bestellungen nachschlägt, braucht kein Schreibrecht auf die Bestelltabelle.
- Bestätigung für alles Wirksame. Lesen darf das Modell allein. Was verschickt, ändert oder löscht, geht über einen Menschen oder über eine Regel außerhalb des Modells.
- Ausgabe wie Nutzereingabe behandeln. Escapen, keine automatischen Abrufe fremder URLs, kein Ausführen von generiertem Code außerhalb einer Sandbox.
- Fremde Inhalte kennzeichnen. Abgerufener Text gehört sichtbar getrennt in den Kontext, mit dem Hinweis, dass es sich um Daten handelt und nicht um Anweisungen. Das ist kein Schutzwall, senkt die Trefferquote aber messbar.
- Zweite Instanz für heikle Schritte. Ein Prüfschritt, der nur die geplante Aktion sieht und nicht den eingeschleusten Text, fängt einen Teil der Fälle ab.
Im Betrieb
Protokollieren, welche Werkzeuge mit welchen Parametern aufgerufen wurden, und die Anwendung regelmäßig mit bekannten Angriffsmustern durchtesten. Filter und Klassifikatoren, die verdächtige Eingaben erkennen, sind eine sinnvolle Schicht, aber nie die einzige. Sie erkennen, was sie kennen.
Prompt Injection und Jailbreak
Die beiden Begriffe werden oft vermischt. Ein Jailbreak zielt auf die Sicherheitsregeln des Modells: Der Nutzer will eine Ausgabe erzwingen, die der Anbieter unterbunden hat. Prompt Injection zielt auf die Anwendung: Ein Dritter will das System gegen den Willen seines Betreibers und meist ohne Wissen des Nutzers umlenken.
Praktisch heißt das: Ein Jailbreak schadet vor allem dem Modellanbieter, eine Prompt Injection dem Unternehmen, das die Anwendung betreibt.
Häufige Fragen zu Prompt Injection
Kann man Prompt Injection vollständig verhindern? Nach heutigem Stand nicht. Solange Anweisung und Daten denselben Kanal teilen, bleibt ein Restrisiko. Deshalb verschiebt sich die Arbeit vom Abwehren des Angriffs zum Begrenzen seiner Folgen.
Reicht es, im Systemprompt Anweisungen aus Dokumenten zu verbieten? Nein. Das hilft gegen Gelegenheitsversuche und ist trotzdem richtig. Ein gezielt formulierter Angriff hebelt es aus, weil das Modell am Ende beides nur als Text sieht.
Betrifft das auch unsere interne Anwendung? Sobald sie Inhalte verarbeitet, die nicht aus der eigenen Hand stammen, ja. Eine eingehende Bewerbung, ein Kundenticket, eine externe Webseite: Jede dieser Quellen kann Anweisungen enthalten.
Was hat das mit Halluzinationen zu tun? Nichts, und die Verwechslung ist verbreitet. Eine KI-Halluzination ist ein Fehler ohne Absender. Prompt Injection ist ein Angriff mit einem.
Fazit
Prompt Injection ist keine Kinderkrankheit, die der nächste Modellwechsel behebt. Sie ist die Folge davon, dass Sprachmodelle Anweisungen und Inhalte im selben Kanal lesen. Wer eine KI-Anwendung baut, plant sie deshalb wie jedes andere System mit fremden Eingaben: wenig Rechte, klare Grenzen, ein Mensch vor der wirksamen Aktion. Wie wir Anwendungen entwerfen, bei denen solche Grenzen von Anfang an stehen, steht auf unserer Seite zur Custom-Software-Entwicklung. Eine Einordnung, was KI in Projekten heute wirklich leistet, gibt der Artikel KI in der Softwareentwicklung. Wo diese Grenzen bei einem handelnden System verlaufen und an welcher Stelle eine Freigabe dazwischensteht, beschreiben wir auf der Seite zu KI-Agenten. Für alles Weitere gibt es das unverbindliche Beratungsgespräch.