Was ist Prompt Injection?

Eine knappe Definition

Prompt Injection bezeichnet Angriffe, bei denen Inhalte, die ein Sprachmodell erreichen, es dazu bringen, Anweisungen zu folgen, die der Betreiber der Anwendung nicht vorgesehen hat. Anwendungsanweisungen, Nutzereingaben und externe Inhalte werden Teil desselben modellsichtbaren Kontexts, auch wenn Anbieter Rollen oder Kanäle unterschiedlich darstellen. Einen verlässlichen, eingebauten Mechanismus, der anweisungsähnlichen Text in Daten wirkungslos macht, gibt es nicht.

NIST beschreibt Prompt Injection als Angriff, der die Verkettung nicht vertrauenswürdiger Eingaben mit einem Prompt ausnutzt, den eine vertrauenswürdigere Partei wie der Anwendungsentwickler erstellt hat. Damit ist der Kern benannt: Das Problem entsteht dort, wo unterschiedliche Vertrauensstufen in einem modellsichtbaren Kontext zusammenfließen.

Warum es Prompt Injection gibt

Klassische Injection-Schwachstellen wie SQL Injection entstehen, weil Code und Daten denselben Kanal teilen. Für diese Klasse schafft die parametrisierte Abfrage eine harte Trennung zwischen Code und Daten. Sprachmodelle kennen keine vergleichbare allgemeine Trennung: Anweisungen und Daten sind gleichermaßen natürliche Sprache, und was das Modell als Anweisung behandelt, ergibt sich aus gelerntem Verhalten, nicht aus einer Grammatik, die die Anwendung kontrolliert.

Rollenmarkierungen, System Prompts und Formatierungskonventionen helfen dem Modell bei der Priorisierung, bleiben aber Verhaltenssignale. Sie verschieben Wahrscheinlichkeiten, ziehen jedoch keine durchgesetzte Grenze. Deshalb behandelt diese Website jede modellsichtbare Eingabe als potenziell einflussreich, unabhängig von ihrer Position im Prompt.

Direkte und indirekte Prompt Injection

Die beiden gängigen Varianten unterscheiden sich darin, woher der beeinflussende Text stammt.

In agentischen Systemen ist indirekte Prompt Injection oft das größere Problem, weil Angreifende gar keinen Zugang zur Anwendung brauchen. Vertiefung: Direkte Prompt Injection und Indirekte Prompt Injection.

Kontrollverlust über Anweisungen und Sicherheitsfolgen

Es hilft, zwei Fragen zu trennen, die oft vermischt werden:

1. Ist das Modell unbeabsichtigten Anweisungen gefolgt? Das ist ein Kontrollverlust über Anweisungen, also eine Eigenschaft des Modellverhaltens.
2. Ist dadurch etwas Sicherheitsrelevantes passiert? Das ist die Sicherheitsfolge, also eine Eigenschaft der Anwendung: welche Daten offengelegt wurden, welche Aktion lief, wohin Inhalte gelangten.

Ein Chatbot ohne Tools, ohne private Daten und ohne dauerhaften Speicher lässt sich zu seltsamen Antworten verleiten, mit möglicherweise nur begrenzter direkter Auswirkung auf Vertraulichkeit oder Integrität. Dasselbe Modell in einem Agenten, der E-Mails lesen und Nachrichten versenden darf, kann aus demselben Kontrollverlust einen Datenabfluss machen. Über die Schwere entscheidet die Architektur, nicht der eingeschleuste Text.

Modellsichtbarer Text wird nicht vertrauenswürdig

Inhalte gewinnen keine Autorität, weil sie im Kontext des Modells stehen, weil sie nahe am System Prompt platziert sind oder weil ein vertrauenswürdiges Tool sie geladen hat. Eine abgerufene Webseite bleibt Inhalt Dritter, auch nachdem sie in einen Prompt eingefügt wurde. Eine E-Mail bleibt der Text des Absenders, selbst wenn der Mailserver den Absender authentifiziert hat.

Vertrauen stellt die Anwendung anhand von Systemnachweisen fest: authentifizierte Identität, verifizierte Herkunft, zugriffsgeschützte Speicherorte, erfasste Provenienz. Diese Fakten liegen in anwendungskontrollierten Metadaten, nicht in der Prosa, die das Modell liest. Der Artikel Vertrauensgrenzen und Modellkontext vertieft diesen Gedanken, und Datenprovenienz beschreibt, wie Herkunft erfasst wird.

Eine Modellantwort ist ein Vorschlag, keine Autorisierung

Schlägt ein Modell einen Tool Call, eine Nachricht, eine Dateiänderung oder eine Ziel-URL vor, ist diese Ausgabe ein Vorschlag. Sie ist variable Daten, geprägt von allem im Kontext, auch von Inhalten, die Angreifende beeinflusst haben könnten. Sie wird nicht dadurch autorisiert, dass das Modell sie selbstsicher formuliert oder dass sie einem gültigen Format entspricht.

Deterministische Prüfungen außerhalb des Modells entscheiden, ob eine Aktion für diese Person, diese Ressource und dieses Ziel zulässig ist. Siehe Agentenautorisierung, Informationsflusskontrolle und Ausgabevalidierung. Validierung prüft das Format, Autorisierung prüft die Berechtigung, und keine von beiden macht modellerzeugte Inhalte vertrauenswürdig.

Wann Prompt Injection sicherheitsrelevant wird

Relevant wird Prompt Injection, sobald die Ausgabe des Modells etwas erreichen kann, das zählt. Hilfreiche Fragen:

Lautet die Antwort überall nein, beschränkt sich die realistische Auswirkung auf die Antwort selbst. Jedes Ja vergrößert den möglichen Schaden und verlangt an dieser Stelle eine deterministische Kontrolle.

Ein kurzes synthetisches Beispiel

Das Beispiel ist rein konzeptionell. Es zeigt die Struktur des Problems, keine Technik.

Der Kontrollverlust fand im Modell statt. Über das Sicherheitsergebnis entschied die Autorisierungsprüfung außerhalb des Modells.

Prompt Injection und Jailbreak

Die beiden Begriffe überschneiden sich und werden von Anbietern, Forschenden und Standardisierungsgremien nicht einheitlich verwendet. Eine verbreitete Arbeitsunterscheidung:

• Jailbreaking meint meist Versuche, ein Modell dazu zu bringen, sein Sicherheitsverhalten oder seine Nutzungsrichtlinien zu ignorieren, häufig durch die nutzende Person selbst.
• Prompt Injection meint meist Inhalte, die die vorgesehenen Anweisungen der Anwendung unterlaufen, und ist besonders relevant, wenn diese Inhalte von Dritten stammen.

Manche Quellen behandeln Jailbreaking als Form der Prompt Injection, andere trennen beides. Einen universellen Begriffsstandard gibt es nicht. Diese Website sagt deshalb, welche Bedeutung sie verwendet, statt eine davon für verbindlich zu erklären. Für die Sicherheitsarchitektur zählt in beiden Fällen dasselbe: woher der Text kam und was die Anwendung mit der resultierenden Ausgabe zulässt.

Zur ausführlichen Gegenüberstellung: Prompt Injection und Jailbreaking.

Verborgener Kontext ist kein Geheimnis

System Prompts und andere verborgene Anweisungen lassen sich manchmal über Modellausgaben offenlegen, erschließen oder teilweise rekonstruieren. Sie dürfen weder Zugangsdaten enthalten noch die einzige Kontrolle sein. Ausführlich dazu: System-Prompt-Extraktion.

Warum Abwehr mehrschichtig ist

Kein einzelner Klassifikator, Filter oder Prompt-Wortlaut trennt Anweisungen und Daten in natürlicher Sprache zuverlässig. Microsofts Leitfaden zu indirekter Prompt Injection empfiehlt eine Defense-in-Depth-Strategie, die probabilistische und deterministische Maßnahmen kombiniert. Diese Website folgt demselben Prinzip:

1. 01
   Herkunft kennen

   Erfassen, woher jeder Inhalt stammt, außerhalb des modellsichtbaren Texts.

2. 02
   Beobachten

   Inhaltsprüfung und Erkennung liefern probabilistische Signale, die umleiten, markieren oder Befugnisse einschränken.

3. 03
   Begrenzen

   Least Privilege beschränkt, welche Daten und Tools ein Ablauf überhaupt erreichen kann.

4. 04
   Deterministisch entscheiden

   Autorisierung und Informationsflusskontrolle entscheiden über jede Aktion und jedes Ziel.

5. 05
   Ausgaben sicher behandeln

   Ausgabevalidierung und senkenspezifische Behandlung, bevor Ausgaben verwendet werden.

Verbreitete Fehlannahmen

Im kontrollierten Lab ausprobieren

Das Lab Grundlagen der direkten Prompt Injection ist eine geführte Simulation. Es zeigt modellsichtbaren Kontext, konkurrierende Anweisungen und eine Autorisierungsentscheidung außerhalb des Modells, ohne Verbindung zu realen Modellen oder Systemen. Im Lab Direkte und indirekte Prompt Injection üben Sie anschließend, Szenarien nach Ursprung und Weg einzuordnen und die Auswirkung als eigene Frage zu bewerten.

Standards und Quellen

Häufige Fragen