Glossar
Prompt Injection
Auch: Indirekte Prompt Injection · Prompt-Einschleusung
Ein Angriff, bei dem Anweisungen in Daten versteckt werden, die ein Sprachmodell verarbeitet, damit es etwas anderes tut als vorgesehen.
Die Ursache ist strukturell: Für ein Sprachmodell sind Anweisung und Inhalt derselbe Text. Es gibt keine technische Trennung wie zwischen Code und Daten in einer Datenbankabfrage. Was in einem verarbeiteten Dokument steht, kann deshalb wie eine Anweisung wirken.
Die direkte Form ist harmlos, weil sichtbar: Ein Nutzer schreibt „ignoriere alle vorherigen Anweisungen" ins Eingabefeld. Gefährlich ist die indirekte Form. Dort steht die Anweisung in einer Quelle, die das System später liest: in einer E-Mail, auf einer Webseite, in einem hochgeladenen PDF, in einem Ticket, in einem Repository.
Der Schaden entsteht nicht durch den Text, sondern durch die Fähigkeiten, die dahinterhängen. Ein Modell, das nur antwortet, kann höchstens Unsinn erzählen. Ein Modell mit Werkzeugen kann Daten abfließen lassen, Mails verschicken, Datensätze ändern. Je mehr ein Agent darf, desto größer der Hebel.
Vollständig verhindern lässt sich Prompt Injection nach heutigem Stand nicht. Kein Prompt ist sicher, kein Filter erkennt alle Varianten. Deshalb ist der richtige Umgang derselbe wie bei anderen unlösbaren Klassen: den Schadensradius begrenzen statt den Angriff auszuschließen.
Praktisch heißt das: Rechte des Modells minimal halten, schreibende Aktionen bestätigen lassen, ausgehende Daten prüfen, und jeden Werkzeugaufruf protokollieren. Ein Agent mit Leserechten auf ein Postfach und Schreibrechten auf nichts ist ein anderes Risiko als einer mit Vollzugriff auf das CRM.
Ein oft übersehener Pfad ist die Ausgabe: Wenn eine Modellantwort ungeprüft in einer Weboberfläche gerendert oder als Befehl ausgeführt wird, hängt an der Injection direkt eine klassische Schwachstelle. Modellausgaben sind Nutzereingaben und werden so behandelt.
Woran Sie es erkennen
- Das Modell verarbeitet Inhalte aus Mails, Tickets, Uploads oder dem Web.
- Angebundene Werkzeuge können Daten ändern oder versenden.
- Es gibt keine Liste erlaubter Ziele für ausgehende Aufrufe.
- Modellausgaben werden direkt gerendert oder ausgeführt.
Nicht zu verwechseln mit
- Jailbreak
- Zielt darauf, die Regeln des Modellanbieters zu umgehen, etwa unerwünschte Inhalte zu erzeugen. Prompt Injection zielt auf die Anwendung und ihre Berechtigungen.
- SQL-Injection
- Strukturell verwandt, aber dort gibt es die saubere Lösung über parametrisierte Abfragen. Für Sprachmodelle existiert dieses Äquivalent nicht.
- Halluzination
- Ein Fehler ohne Angreifer: Das Modell erfindet etwas. Bei Prompt Injection tut es genau das, was jemand anderes wollte.
- Guardrails
- Die Gegenmaßnahmen rund um das Modell. Sie senken das Risiko, beseitigen es aber nicht, weil sie ebenfalls auf Textprüfung beruhen.
Wann es trägt
- Immer, sobald ein Modell Inhalte verarbeitet, die nicht aus vertrauenswürdiger Hand stammen.
- Besonders dringend, wenn Werkzeuge angebunden sind, die Daten ändern oder versenden.
- Bei Agenten, die selbständig mehrere Schritte ausführen.
Wann nicht
- Bei einem geschlossenen System, das ausschließlich intern erzeugte, geprüfte Texte verarbeitet, ist das Risiko gering. Diesen Fall gibt es allerdings seltener als angenommen.
Wie man rangeht
- Rechte auf das Nötigste begrenzenDer wirksamste Hebel. Ein Agent, der nichts löschen kann, löscht auch unter Angriff nichts. Rechte je Werkzeug vergeben, nicht pauschal je Dienstkonto.
- Quellen kennzeichnen und trennenFremde Inhalte klar als Daten markieren und vom Systemtext trennen. Das verhindert nichts zuverlässig, senkt die Trefferquote naiver Angriffe aber deutlich.
- Schreibende Aktionen bestätigen lassenAlles, was nicht rückgängig zu machen ist, braucht einen Menschen oder eine zweite Prüfung. Bei hohem Volumen wenigstens Schwellenwerte und Stichproben.
- Ausgehende Daten prüfenZiele für Netzaufrufe auf eine Liste erlaubter Adressen begrenzen. Der typische Abfluss geschieht über eine unscheinbare URL in der Antwort.
- Modellausgaben wie Nutzereingaben behandelnNie ungeprüft rendern, nie als Befehl ausführen. Sonst hängt an der Injection direkt eine klassische Schwachstelle.
- Alles protokollierenEingaben, Werkzeugaufrufe, Ergebnisse. Nach einem Vorfall ist das die einzige Grundlage, um zu klären, was passiert ist und was nicht.
Häufig gefragt
Lässt sich Prompt Injection verhindern?
Nach heutigem Stand nicht vollständig. Anweisung und Inhalt sind für ein Sprachmodell derselbe Text, ein Äquivalent zu parametrisierten Abfragen gibt es nicht. Der richtige Umgang ist deshalb Schadensbegrenzung: minimale Rechte, Bestätigung für schreibende Aktionen, geprüfte Ausgänge, lückenlose Protokollierung.
Reicht ein guter System-Prompt?
Nein. Ein System-Prompt ist eine Bitte, keine Grenze. Er hilft gegen naive Versuche und ist gegen gezielte Angriffe unzuverlässig. Sicherheitsentscheidungen gehören außerhalb des Modells getroffen, im Rechtemodell und im Code.
Was ist der Unterschied zwischen direkter und indirekter Injection?
Bei der direkten schreibt der Nutzer die Anweisung selbst ins Eingabefeld, sie ist sichtbar und meist harmlos. Bei der indirekten steht sie in Inhalten, die das System später liest: eine E-Mail, eine Webseite, ein PDF. Der Angreifer muss die Anwendung dafür nicht einmal benutzen.
Wie testet man darauf?
Mit einem festen Satz von Angriffsmustern in allen Kanälen, aus denen Inhalte kommen, und einer Prüfung, was jeder Werkzeugaufruf im schlimmsten Fall anrichten kann. Der zweite Teil ist der wichtigere: Er ändert die Architektur, während der erste nur die aktuelle Modellversion prüft.