Direkte Prompt Injection

Was ist direkte Prompt Injection?

Direkte Prompt Injection liegt vor, wenn ein primärer Nutzer natürlichsprachige Eingaben übermittelt, die das Verhalten einer LLM-Anwendung auf unbeabsichtigte oder unerwartete Weise verändern. Die Eingabe erreicht das System über einen vorgesehenen Kanal, etwa ein Chatfeld, einen API-Parameter, ein Befehlsfeld oder die Aufgabenbeschreibung eines Agents. Der Kanal ist legitim. Sein Inhalt wird dadurch jedoch nicht vertrauenswürdig.

NIST beschreibt Prompt Injection als Folge der Verbindung nicht vertrauenswürdiger Eingaben mit einem Prompt, den eine höher vertrauenswürdige Partei wie der Anwendungsentwickler erstellt hat. Den Fall des primären Nutzers bezeichnet NIST als Direct Prompting Attack. Er unterscheidet sich von Angriffen, die über Ressourcen erfolgen, welche das System später abruft oder verarbeitet. OWASP grenzt ebenfalls direkte von indirekter Prompt Injection ab. Bei der indirekten Variante steckt die Anweisung in einer externen Quelle wie einem Dokument, einer Website, einer E-Mail oder einem Tool-Ergebnis.

Eine direkte Injection kann absichtlich erfolgen. OWASP weist zugleich darauf hin, dass auch unbeabsichtigte Eingaben das Verhalten verändern können. Die Sicherheitsfrage ist deshalb breiter als die Absicht des Absenders: Kann nutzerkontrollierte Sprache das Anwendungsziel übersteuern, Informationen offenlegen oder Aktionen außerhalb der Befugnisse des Nutzers beeinflussen?

Wie direkte Prompt Injection funktioniert

Der Ablauf beginnt in der Anwendung und nicht erst im Modell. Vor der Anfrage stellt die Anwendung den für das Modell sichtbaren Kontext aus höher vertrauenswürdigen Anweisungen und der Nutzereingabe zusammen. Je nach Produkt können auch der bisherige Gesprächsverlauf, Beschreibungen verfügbarer Tools oder Fähigkeiten und von der Anwendung ausgewählte Daten enthalten sein. Nicht jedes System verwendet alle diese Quellen, und die konkrete Umsetzung unterscheidet sich. Das Modell soll das bereitgestellte Material jedoch gemeinsam interpretieren und daraus die nächste Ausgabe ableiten.

Viele LLM-APIs unterscheiden Quellen von Anweisungen über Rollen wie System, Developer und User oder über vergleichbare Nachrichtenstrukturen. Solche Rollen können die Priorität beeinflussen und die beabsichtigte Hierarchie deutlicher machen. Ihre genaue Semantik ist jedoch anbieterspezifisch. Sie entsprechen weder einer Isolation auf Parser-Ebene noch einer Zugriffskontrolle oder deterministischen Autorisierungsgrenze. Eine Regel in einer höher priorisierten Rolle macht widersprechende Nutzereingaben nicht automatisch harmlos.

Auf Ebene des Modellverhaltens gelingt eine direkte Injection, wenn nicht vertrauenswürdige natürliche Sprache als Anweisungssignal interpretiert wird und dadurch die vorgesehene Aufgabe verändert, eine Beschränkung abgeschwächt, eine Ausgabe umgelenkt oder eine nachgelagerte Aktion beeinflusst wird. Das Modell kann konkurrierende Anweisungen priorisieren, neu deuten oder verbinden, ohne dass dies dem Anwendungsziel entspricht. Die Eingabe kann dabei vollständig in ihrem vorgesehenen Feld bleiben und syntaktisch gültig sein.

Direkte Prompt Injection erfordert deshalb kein "Ausbrechen" aus einem Eingabefeld, wie es bei SQL Injection etwa durch das Verlassen eines Zeichenkettenkontexts und die Veränderung einer formalen Abfragegrammatik geschieht. Stattdessen interpretiert das Modell Inhalte, die für die Anwendung nicht vertrauenswürdige Daten sind, als anweisungsähnliche Sprache in seinem Verarbeitungskontext. Die Analogie zu klassischen Injection-Schwachstellen ist hilfreich, weil angreiferkontrollierte Eingaben die Interpretation beeinflussen. Die Mechanik unterscheidet sich jedoch: Prompt-Verarbeitung ist probabilistisch, während SQL- oder Code Injection typischerweise eine formale Grenze zwischen Daten und Code überschreitet.

Trennzeichen, Rollenkennzeichnungen und präzise Prompts können die Robustheit verbessern, indem sie Datenbereiche und erwartete Aufgaben klarer markieren. Sie schaffen aber keine Isolation wie parametrisierte Abfragen, typisierte Schnittstellen oder eine Autorisierungsschicht. Das Ergebnis hängt vom Modell, dem vollständigen Kontext, der Orchestrierung und den verfügbaren Fähigkeiten ab. Ein fehlgeschlagener Test der Anweisungskontrolle kann nur eine unpassende Antwort erzeugen. Bei einem System mit vertraulichen Daten oder privilegierten Tools kann derselbe Fehler zu einem relevanten Sicherheitsvorfall beitragen.

Offensive Perspektive und Erfolgsbedingungen

Für eine autorisierte Prüfung ist der Zugriff auf einen gültigen Eingabekanal nur die erste Voraussetzung. Das Testteam muss feststellen, ob kontrollierte Eingaben in den zusammengesetzten Kontext gelangen, Rollen-, Format-, Längen- und Aufgabenbeschränkungen überstehen, Antwort oder Plan verändern, modellsichtbare Daten oder eine verfügbare Fähigkeit erreichen und anschließend eine Anwendungskontrolle überschreiten. Jede Stufe kann unabhängig scheitern.

Was im Modellkontext tatsächlich passiert

Die Anwendung bestimmt, welche Quellen diesen Pfad erreichen. Ein einfacher Assistent verwendet möglicherweise nur eine feste Anweisung und eine Nutzernachricht. Ein Dialogprodukt kann frühere Gesprächsschritte einbeziehen. Ein Agent erhält möglicherweise zusätzlich Tool-Namen, Parameterschemas, Beschreibungen seiner Fähigkeiten oder ausgewählte Anwendungsdaten. Diese Ergänzungen unterstützen die Aufgabe, vergrößern aber zugleich den Anteil von Kontext mit gemischtem Vertrauen, der die Interpretation beeinflussen kann.

Rollen und Nachrichtengrenzen können die Provenienz innerhalb einer Anfrage erkennbar halten. Die maßgebliche Dokumentation dieser Herkunft muss dennoch außerhalb des Modells bestehen bleiben. Die Anwendung sollte festhalten, welcher Principal die Eingabe geliefert hat, welche Policy-Version die Anweisungen erzeugte, welche Datenquelle Kontext beitrug und welche Fähigkeiten angeboten wurden. Das Modell weist diese Vertrauensstufen nicht selbst verbindlich zu und setzt sie nicht für deterministische Sicherheitsentscheidungen durch.

Auch die Modellausgabe ist eine weitere Grenze und keine abschließende Entscheidung. Text kann einem Menschen zur Prüfung angezeigt werden. Eine vorgeschlagene Aktion wird dagegen an Kontrollen der Anwendung übergeben. Ein sicherer Pfad bewertet initiierenden Principal, Zielressource, gewünschte Aktion, Ziel und Parameter vor der Ausführung. Das Modell darf eine Handlung empfehlen, kann aber nicht feststellen, dass der Nutzer dazu autorisiert ist.

Die Vertrauensgrenze

Diese Kennzeichnungen beschreiben das Sicherheitsmodell der Anwendung. Sie behaupten nicht, dass das LLM die Vertrauensstufen selbst zuverlässig durchsetzt. Die Anwendung kennt Herkunft, Befugnis und zulässige Aktionen jeder beteiligten Partei. Werden alle Inhalte zu Modelltext zusammengeführt, kann diese Herkunftsinformation verloren gehen.

Ein robustes Design erhält die Provenienz außerhalb des Prompts und berücksichtigt sie bei Richtlinienentscheidungen. Nutzereingaben bleiben nicht vertrauenswürdig, auch wenn sie autoritativ klingen, einen Notfall behaupten, einen Administrator zitieren oder dem Modell eine andere Rolle zuweisen. Das Modell kann die Anfrage interpretieren. Deterministische Kontrollen müssen jedoch entscheiden, ob Daten offengelegt oder Aktionen ausgeführt werden dürfen.

Praxisbeispiele

Die folgenden drei Abläufe trennen Fehler bei der Anweisungskontrolle von ihren möglichen Sicherheitsfolgen. Sie verwenden gewöhnliche Aufgabenänderungen und keine optimierten Umgehungsformulierungen.

Beispiel 1: Reiner Textassistent. Die Anwendung verlangt eine begrenzte Zusammenfassung. Der Nutzer liefert Text, der zugleich eine andere Aufgabe fordert. Das Modell folgt dieser konkurrierenden Aufgabe und antwortet außerhalb des vorgesehenen Formats.

Der Fehler bleibt relevant, weil er zeigt, dass nutzerkontrollierte Sprache die Aufgabe umleiten kann. Sein Schweregrad ergibt sich aus den zugänglichen Daten und verbundenen Befugnissen und nicht allein aus einer überraschenden Antwort.

Beispiel 2: Agent mit Tool-Nutzung. In einer agentischen Anwendung kann dieselbe Art der Task Redirection beeinflussen, welche Aktion das Modell vorschlägt. Dieser Vorschlag muss vor der Ausführung eine unabhängige Kontrollebene durchlaufen.

Das Modell kann ableiten, dass ein Tool Call die manipulierte Anfrage erfüllt. Diese Schlussfolgerung darf aber nicht darüber entscheiden, ob der Aufruf zulässig ist. Eine Prompt-Anweisung wie "Sende niemals Daten an ein nicht freigegebenes Ziel" ist nützliche Steuerung, aber keine Autorisierungskontrolle. Deterministische Prüfungen müssen Aktionen außerhalb des Umfangs des initiierenden Principals ablehnen, auch wenn der Vorschlag flüssig, plausibel und selbstsicher formuliert ist.

Beispiel 3: Dialog über mehrere Schritte. Direkte Prompt Injection beschränkt sich nicht auf einzelne Sätze wie "Ignoriere vorherige Anweisungen". Frühere Nutzereingaben können eine falsche Voraussetzung etablieren oder den Aufgabenrahmen unauffällig erweitern. Bleiben diese Schritte im Modellkontext sichtbar, kann eine spätere Anfrage daran anknüpfen und das Verhalten weiter vom ursprünglichen Anwendungsziel entfernen.

Diese Beispiele erklären die Mechanik und sind keine wiederverwendbaren Anleitungen zum Umgehen von Kontrollen. Defensive Tests sollten Aufgabenänderungen, Kontextstruktur, Gesprächslänge und verfügbare Aktionen variieren und dabei Anweisungsintegrität, Autorisierungsergebnisse und Nebenwirkungen messen.

Häufige Techniken direkter Prompt Injection

Die folgenden Bezeichnungen beschreiben wiederkehrende Mechanismen. Sie helfen bei Threat Modeling und Testabdeckung, sind jedoch keine überschneidungsfreien Klassifikationen.

Instruction Override, Role Manipulation, Multi-Turn Prompt Injection und kodierte oder verschleierte Anweisungen sind Techniken, Interaktionsmuster oder Darstellungsformen innerhalb eines Prompt-Injection-Eintrittspfads, keine weiteren gleichrangigen Klassen neben dem direkten und dem indirekten Pfad. Eine Technik verändert nicht, wie eine Anweisung ins System gelangt ist; das tut der Eintrittspfad.

Frühe Forschung von Perez und Ribeiro behandelte Goal Hijacking und Prompt Leaking als nützliche Kategorien für Fehler beim Befolgen von Anweisungen. Diese Begriffe liefern historischen Kontext, bestimmen aber allein nicht den Schweregrad einer aktuellen Anwendung.

Direkte Prompt Injection vs. Jailbreaking

OWASP behandelt beide Konzepte als verwandt, aber nicht identisch. Jailbreaking ist eine Form der Prompt Injection mit dem Ziel, Sicherheitsprotokolle zu umgehen. Direkte Injection kann stattdessen auf Task Redirection, Offenlegung von Anweisungen, unautorisierte Tool-Nutzung oder Manipulation von Geschäftsprozessen zielen. Wer jede direkte Injection als Jailbreak bezeichnet, verdeckt wichtige Fragen der Anwendungssicherheit.

Direkte vs. indirekte Prompt Injection

Der Unterschied betrifft den Weg, über den die angreiferkontrollierte Anweisung das Modell erreicht. Beide Varianten können Kontext mit gemischtem Vertrauen ausnutzen und benötigen Kontrollen auf Systemebene. Der externe Übertragungsweg wird unter Indirekte Prompt Injection beschrieben.

Angriffsfläche

Direkte Eingaben treten in vielen Produktformen auf. Entscheidend sind weniger die Bezeichnung der Oberfläche als die verbundenen Daten, Befugnisse und Nebenwirkungen.

Wann wird Prompt Injection zur Sicherheitslücke?

Fehlverhalten eines Modells ist nicht automatisch eine Sicherheitslücke. Liefert ein öffentlicher Chatbot ohne weitere Fähigkeiten eine unpassende oder richtlinienwidrige Antwort, ist dies ein Verhaltensfehler, dessen Sicherheitsauswirkung begrenzt sein kann. Derselbe Fehler ist bei einem Enterprise Agent anders zu bewerten, wenn dieser vertrauliche Datensätze lesen, privilegierte Tools aufrufen, Nachrichten versenden, Transaktionen freigeben oder persistenten Zustand ändern kann.

Entscheidend sind die überschrittene Grenze und die ermöglichte Folge. Eine relevante Sicherheitsauswirkung liegt nahe, wenn die Manipulation zu unautorisiertem Datenzugriff, Offenlegung über Nutzer- oder Mandantengrenzen, Tool-Ausführung außerhalb der Befugnisse des Initiators, Umgehung einer Richtlinien- oder Autorisierungsentscheidung, persistenten Zustandsänderungen, Kommunikation an ein nicht zugelassenes externes Ziel, Erweiterung von Privilegien oder wesentlicher Manipulation eines Geschäftsprozesses beiträgt.

Der Schweregrad ist systemspezifisch. Zu prüfen ist der gesamte Pfad von der Eingabe über Modellentscheidung und Anwendungslogik bis zur realen Aktion. Dabei muss nachvollzogen werden, welche unabhängigen Kontrollen funktioniert haben oder ausgefallen sind. Eine überraschende Unterhaltung allein genügt nicht für eine Bewertung. Ein Modellfehler darf aber auch nicht verharmlost werden, wenn nachgelagerte Komponenten ihm Befugnisse verleihen. Forschung von Yi Liu und Mitautoren liefert zusätzlichen Kontext für Prompt Injection in integrierten Anwendungen, bei denen die Folgen auf Systemebene von den umgebenden Komponenten und nicht allein von der Modellantwort abhängen.

Potenzielle Auswirkungen

OWASP nennt Folgen von Offenlegung und Inhaltsmanipulation bis zu unautorisiertem Funktionszugriff, Befehlsausführung in verbundenen Systemen und Manipulation kritischer Entscheidungen. Dies sind mögliche Konsequenzen und keine Eigenschaften jeder verwundbaren Eingabe.

Direkte Prompt Injection bei AI Agents

Agency verändert das Auswirkungsmodell. Ein reiner Textassistent erzeugt vor allem Inhalte, die ein Mensch bewertet. Ein AI Agent kann Tools auswählen, interne Daten abrufen, externe Dienste ansprechen oder eine Folge von Aktionen mit delegierten Befugnissen ausführen. Prompt-Manipulation wird dann von einem Problem der Ausgabequalität zu einem Autorisierungs- und Aktionssicherheitsproblem.

Das Modell kann Absichten interpretieren und Aktionen vorschlagen oder auswählen. Es darf sich jedoch nicht selbst Berechtigungen erteilen. Ein Agent benötigt eine explizite Identität, eng begrenzte Tools und Zugangsdaten, Autorisierung jeder folgenreichen Aktion anhand des initiierenden Principals und der aktuellen Ressource, Parameterprüfung und eine belastbare Audit-Spur. Sicherheitsleitlinien von Microsoft stützen diese Architekturprinzipien wie Least Privilege, explizite Identität, Autorisierung pro Aktion, Nachvollziehbarkeit und menschliche Freigabe für besonders folgenreiche Vorgänge.

Prompts bleiben für die Aufgabensteuerung nützlich. Ein Satz wie "Sende niemals vertrauliche Daten" ist jedoch keine Autorisierungsgrenze. Deterministische Anwendungskontrollen müssen erzwingen, wer auf welche Ressource zugreifen, welches Tool verwenden und mit welchem Ziel kommunizieren darf.

Erkennung

Erkennung beruht auf Signalen und Wahrscheinlichkeiten. Schlüsselwörter und Prompt-Klassifikatoren können Hinweise liefern. Sprache ist jedoch variabel, und legitime Anfragen können Angriffen ähneln. Ein einzelner Detektor darf weder automatisch einen Angriff beweisen noch als einzige Kontrolle dienen. Eingabesignale müssen mit Modellplänen, Autorisierungsergebnissen, Tool-Telemetrie, Datenzugriff und nachgelagerten Auswirkungen korreliert werden.

Protokollierung und Telemetrie

Eine Untersuchung benötigt eine nachvollziehbare Spur über die gesamte Anfrage- und Aktionskette. Es sollte genügend strukturierter Kontext erfasst werden, um Entscheidungen zu rekonstruieren, ohne mehr sensible Inhalte als erforderlich zu sammeln.

Prompt- und Kontextprotokolle können selbst personenbezogene, vertrauliche oder regulierte Daten enthalten. Erforderlich sind Zugriffskontrollen, Datenminimierung, gegebenenfalls Schwärzung, definierte Aufbewahrungsfristen und sichere Löschung. Der forensische Wert muss erhalten bleiben, ohne ein neues zentrales Offenlegungsrisiko zu schaffen.

Incident Response

Die Reaktion darf nicht beim Entfernen des sichtbaren Prompts oder beim Ergänzen seiner Formulierung in einer Blockliste enden. Entscheidend ist, warum die Modellausgabe sensible Daten oder Befugnisse erreichen konnte und welche fehlende Systemkontrolle dies zugelassen hat.

Prävention und Minderung

OWASP hält fest, dass es keine eindeutig narrensichere Präventionsmethode gibt. Wirksame Risikominderung kombiniert Kontrollen, welche den Einfluss von Anweisungen, die Datenexposition, die Modellbefugnisse und nachgelagerte Folgen begrenzen.

1. 01
   Eingaben als nicht vertrauenswürdig behandeln

   Quelle und Provenienz erhalten. Ein normaler Nutzerkanal darf keine implizite Autorität erzeugen.

2. 02
   Rolle und Aufgabe begrenzen

   Fokussierte Anweisungen, begrenzte Abläufe und explizite Ausgabeerwartungen reduzieren unnötige Verhaltensfreiheit.

3. 03
   Ausgaben validieren

   Erzeugte Strukturen, Parameter, Ziele und Behauptungen vor der weiteren Verwendung parsen und prüfen.

4. 04
   Für das Modell sichtbare Geheimnisse minimieren

   Zugangsdaten oder vertraulichen Kontext nur in den Prompt geben, wenn die Aufgabe dies tatsächlich erfordert.

5. 05
   Außerhalb des LLM autorisieren

   Deterministische Prüfungen anhand von Nutzeridentität, Ressource, Aktion, Mandant und aktueller Policy durchführen.

6. 06
   Least Privilege anwenden

   Agents nur eng begrenzte Tools, Zugangsdaten, Datenzugriffe und zeitlich beschränkte Befugnisse geben.

7. 07
   Aktionen und Parameter prüfen

   Erlaubte Operationen, typisierte Schnittstellen, Geschäftsregeln und Zielkontrollen einsetzen.

8. 08
   Menschliche Freigabe verlangen

   Vor folgenreichen, irreversiblen, finanziellen oder externen Aktionen eine echte Bestätigung vorsehen.

9. 09
   Ausführung einschränken

   Bei Bedarf Netzwerk- und Egress-Kontrollen, Sandboxing, Isolation sowie Schritt- oder Ratenlimits einsetzen.

10. 10
    Adversarial Testing durchführen

    Anweisungstreue, Vertraulichkeit, Autorisierung, Tools, Zustand, Isolation und Telemetrie vor und nach Änderungen prüfen.

Ein- und Ausgabefilter können bekannte Muster oder offensichtlich unsichere Ergebnisse erfassen. Allein reichen sie nicht aus. Angriffssprache verändert sich, legitime Inhalte können Fehlalarme auslösen, und auch zugelassene Modellausgaben benötigen Validierung.

Sichere Architektur

In der robusteren Architektur darf das Modell eine Aktion empfehlen und mögliche Parameter erzeugen. Eine Policy-Schicht bewertet den Vorschlag anhand expliziter Regeln. Die Autorisierung prüft initiierende Identität und Zielressource. Die Validierung erzwingt Typen, Wertebereiche, Ziele und Geschäftsregeln, bevor das Tool ausgeführt wird.

Diese Kette macht das Modellverhalten nicht vollständig vorhersagbar. Sie begrenzt die Folgen unvorhersehbaren Verhaltens. Das Modell kann seinen eigenen Umfang nicht erweitern, keine eigene Ausnahme genehmigen und eine Nutzerbehauptung nicht als Berechtigungsnachweis behandeln.

Checkliste für das Threat Modeling

Direkte Prompt Injection testen

Tests sollten in einer kontrollierten Umgebung mit synthetischen Daten und Testidentitäten mit bewusst begrenzten Berechtigungen stattfinden. Erwartete Policy-Ergebnisse werden vorab definiert, damit die Prüfung Sicherheitsgrenzen statt subjektiver Antwortqualität misst.

Diese Ergebnisse dürfen nicht zu einem einzigen Score verdichtet werden. Ein System kann häufige Modellbeeinflussung und zugleich starke Eindämmung zeigen oder seltene Beeinflussung aufweisen, aber in den wenigen erreichten Fällen einen schweren Autorisierungsfehler enthalten.

Die Tests werden wiederholt, wenn sich Modelle, Prompts, Tools, Richtlinien, Retrieval-Quellen oder Orchestrierung ändern. Sowohl blockierte Versuche als auch unsichere Pfade werden dokumentiert. Eine bestandene Testsuite ist Evidenz für die geprüfte Konfiguration, aber kein Beweis dafür, dass Prompt Injection beseitigt wurde.

Häufige Fehlannahmen

Standards und Klassifikationen

NIST AI 100-2e2025 wurde im März 2025 veröffentlicht und stellt eine Taxonomie und Terminologie für Adversarial Machine Learning bereit. Das NIST-Glossar beschreibt Prompt Injection über die Verbindung nicht vertrauenswürdiger Eingaben mit einem höher vertrauenswürdigen Prompt. Direct Prompt Injection wird dort als Direct Prompting Attack eingeordnet, den der primäre Nutzer über Anfragezugriff ausführt.

Die OWASP GenAI LLM Top 10 (Ausgabe 2026) klassifiziert das Risiko als LLM01:2026 Prompt Injection. MITRE ATLAS katalogisiert direkte LLM-Prompt-Injection als AML.T0051.000. Weitere Zuordnungen zu CWE, CAPEC oder anderen Frameworks werden hier nicht vorgenommen.

Häufig gestellte Fragen