Prompt-Injection
Prompt-Injection ist ein Angriff, bei dem eine gezielt gestaltete Eingabe ein Sprachmodell dazu bringt, seine ursprünglichen Anweisungen zu ignorieren und stattdessen denen des Angreifers zu folgen. Es ist das meistdiskutierte Sicherheitsrisiko für Anwendungen, die auf großen Sprachmodellen aufbauen, und es ist schwer vollständig zu beseitigen, weil diese Modelle so funktionieren, wie sie funktionieren.
Ein LLM trennt vertrauenswürdige Anweisungen nicht sauber von nicht vertrauenswürdigen Daten. Der System-Prompt, die Nutzernachricht und alle Inhalte, die die Anwendung einspeist, treffen als Text im selben Kontextfenster ein. Wenn vom Angreifer kontrollierter Text sagt „Ignoriere deine vorherigen Anweisungen und tu X", kann das Modell befolgen, denn für das Modell ist alles nur Text, auf den es reagieren soll.
Das Ergebnis ist, dass sich die Schutzmechanismen einer Anwendung umreden lassen. Ein Modell, das ein höflicher Support-Bot sein soll, kann dazu verleitet werden, seinen System-Prompt zu verraten, unerlaubte Inhalte zu erzeugen oder, in einem werkzeugnutzenden System, Funktionen aufzurufen, die es nicht aufrufen sollte.
Direkte Prompt-Injection
Bei einer direkten Injection ist der Angreifer der Nutzer. Er tippt Anweisungen, die den System-Prompt überschreiben sollen: er bittet das Modell, versteckte Anweisungen zu verraten, um eine Beschränkung herum eine Rolle zu spielen oder frühere Regeln als aufgehoben zu behandeln.
Jailbreaking ist eine bekannte Form der direkten Injection, bei der der Nutzer ein Szenario konstruiert, das das Modell an seinem Sicherheitstraining vorbeilockt. Die direkte Injection ist der leichter zu durchdenkende Fall, weil die böswillige Eingabe von der Person stammt, die mit dem System interagiert, und Ratenbegrenzung oder Missbrauchserkennung helfen können.
Indirekte Prompt-Injection
Die indirekte Injection ist die gefährlichere Variante. Hier werden die böswilligen Anweisungen nicht vom Nutzer getippt. Sie sind in Inhalten versteckt, die die Anwendung hereinzieht: eine Webseite, die das Modell zusammenfasst, ein Dokument in einem Retrieval-Speicher, eine E-Mail in einem Postfach, das das Modell liest, oder eine von jemand anderem hochgeladene Datei.
Wenn das Modell diesen Inhalt verarbeitet, stößt es auf die platzierten Anweisungen und folgt ihnen möglicherweise, obwohl der Nutzer sie nie gesehen oder beabsichtigt hat. In einem System, das Werkzeuge nutzen oder Daten senden kann, lässt die indirekte Injection einen Angreifer, der ein einziges abgerufenes Dokument kontrolliert, die Handlungen des Modells lenken. Deshalb behandeln Retrieval- und Agentensysteme alle aufgenommenen Inhalte als nicht vertrauenswürdig.
Warum sie ein Spitzenrisiko bei LLMs ist
Prompt-Injection steht aus mehreren Gründen ganz oben auf den Risikolisten, einschließlich der OWASP Top 10 für LLM-Anwendungen.
Sie ist grundlegend, kein Fehler. Das Fehlen einer harten Grenze zwischen Anweisungen und Daten ist Teil davon, wie aktuelle Modelle einen Prompt lesen. Es gibt keinen Patch, der sie vollständig schließt.
Sie skaliert mit den Fähigkeiten. Sobald Anwendungen Modellen Zugriff auf Werkzeuge, private Daten und die Fähigkeit zu handeln geben, verschiebt sich eine erfolgreiche Injection von einer peinlichen Ausgabe hin zu Datenabfluss oder unbefugten Handlungen.
Sie ist schwer erschöpfend zu testen. Angreifer können dieselbe Absicht auf unzählige Arten formulieren, auch in anderen Sprachen oder in kodierter Form, sodass ein Filter, der eine Formulierung blockiert, selten alle blockiert.
Gegenmaßnahmen
Es gibt keine Einzellösung, daher werden Abwehrmaßnahmen geschichtet.
Vertrauensstufen trennen und kennzeichnen. Halten Sie Systemanweisungen, Nutzereingaben und abgerufene Inhalte getrennt und machen Sie dem Modell klar, was maßgeblich ist. Einige Frameworks nutzen strukturierte Nachrichtenrollen, um das zu verstärken.
Einschränken, was das Modell tun kann. Die stärkste Gegenmaßnahme ist, die Wirkung zu verringern. Begrenzen Sie Werkzeugberechtigungen, verlangen Sie für folgenreiche Handlungen eine menschliche Freigabe und lassen Sie die Ausgabe des Modells nie ohne Prüfung direkt eine unumkehrbare Operation auslösen.
Eingaben und Ausgaben prüfen. Filtern Sie bekannte Injection-Muster und prüfen Sie die Ausgabe des Modells sowie alle Werkzeugaufrufe, bevor Sie darauf reagieren. Behandeln Sie abgerufene und Nutzerinhalte standardmäßig als nicht vertrauenswürdig.
Isolieren und in einer Sandbox ausführen. Führen Sie Werkzeughandlungen mit geringsten Rechten aus, sodass ein gekapertes Modell dennoch nicht an sensible Systeme heranreicht. Bereinigen Sie Inhalte, wo praktikabel, bevor sie ins Kontextfenster gelangen.
Feindlich testen. Führen Sie Red Teaming der Anwendung mit Injection-Versuchen durch, auch mit indirekten, die in Dokumenten und Seiten platziert sind, und verfolgen Sie über die Zeit, welche Formulierungen durchkommen.
Keine Kombination ist perfekt, das realistische Ziel ist daher, Injection zu erschweren und den Schaden zu begrenzen, wenn sie gelingt.
Bezug zur Governance
Prompt-Injection ist der Punkt, an dem Sicherheit und Governance aufeinandertreffen. Nach dem EU AI Act müssen Hochrisikosysteme gegenüber Manipulationsversuchen widerstandsfähig sein, was Injection unmittelbar betrifft. ISO 42001 und das [NIST AI Risk Management Framework](/de/lexicon/nist-ai-risk-management-framework-rmf) erwarten, dass solche Bedrohungen als Teil des laufenden Risikomanagements erkannt, getestet und gemindert werden.
Für Governance-Teams sind die praktischen Forderungen klar. Dokumentieren Sie, dass Prompt-Injection in Ihrem Bedrohungsmodell enthalten ist. Belegen Sie feindliche Tests. Halten Sie die Kontrollen fest, die begrenzen, was ein kompromittiertes Modell tun kann, und binden Sie Injection-Vorfälle in Ihren Prozess zur Reaktion auf KI-Vorfälle ein. Es geht nicht darum, Immunität zu behaupten, die niemand erreichen kann, sondern zu zeigen, dass das Risiko verstanden und eingedämmt ist.
FAQ
Was ist der Unterschied zwischen direkter und indirekter Prompt-Injection?
Bei der direkten Injection tippt der Nutzer Anweisungen, die den System-Prompt überschreiben. Bei der indirekten Injection sind die böswilligen Anweisungen in Inhalten versteckt, die das Modell aufnimmt, etwa eine Webseite, ein Dokument oder eine E-Mail, sodass der Nutzer sie nie getippt hat und unter Umständen nicht weiß, dass sie da sind. Die indirekte Injection ist gefährlicher, weil sie werkzeugnutzende und Retrieval-Systeme über eine einzige platzierte Quelle kapern kann.
Lässt sich Prompt-Injection vollständig verhindern?
Nein. Aktuelle Modelle erzwingen keine harte Grenze zwischen Anweisungen und Daten, daher lässt sich Injection nicht vollständig schließen. Abwehrmaßnahmen verringern, wie oft sie gelingt, und begrenzen den Schaden, wenn sie gelingt, vor allem indem sie die Berechtigungen des Modells einschränken und seine Handlungen prüfen. Behandeln Sie sie als ein gemanagtes Risiko, nicht als ein gelöstes.
Wie unterscheidet sich Prompt-Injection von Jailbreaking?
Jailbreaking ist eine Art der direkten Injection, die darauf abzielt, das Modell an seinen Sicherheitsbeschränkungen vorbeizubringen, etwa um unerlaubte Inhalte zu erzeugen. Prompt-Injection ist die breitere Kategorie, die auch das Überschreiben von Anwendungsanweisungen umfasst und, in indirekter Form, das Platzieren von Befehlen in externen Inhalten, um Verhalten oder Werkzeugnutzung zu kapern.
Warum ist indirekte Prompt-Injection ein Problem für RAG und Agenten?
Diese Systeme speisen externe Inhalte ins Modell: abgerufene Dokumente bei RAG, Werkzeugergebnisse und abgerufene Seiten bei Agenten. Trägt einer dieser Inhalte versteckte Anweisungen, kann das Modell ihnen folgen und, bei einem Agenten, seine Werkzeuge missbrauchen. Weil der Inhalt über Retrieval oder Werkzeuge statt über den Nutzer eintrifft, umgeht er die auf den Nutzer ausgerichteten Eingabeprüfungen.
Was ist die einzelne wirksamste Abwehr?
Die Fähigkeiten des Modells zu begrenzen. Wenn ein kompromittiertes Modell ohne menschliche Freigabe weder an sensible Daten herankommt noch Geld ausgeben oder unumkehrbare Handlungen ausführen kann, erzeugt eine erfolgreiche Injection eine schlechte Ausgabe statt echten Schaden. Eingabefilterung und Vertrauenskennzeichnung helfen, aber die Wirkung zu begrenzen ist das, was Bestand hat, wenn die Filterung versagt.
Wie hängt Prompt-Injection mit Compliance zusammen?
Rahmenwerke wie der EU AI Act verlangen, dass Hochrisikosysteme Manipulation widerstehen, und Standards wie ISO 42001 und das NIST AI RMF erwarten, dass Bedrohungen erkannt, getestet und gemindert werden. Für einen Prüfer sollten Sie zeigen, dass Injection in Ihrem Bedrohungsmodell steht, dass Sie dafür Red Teaming betreiben und dass Kontrollen die Wirkung eines erfolgreichen Angriffs begrenzen.
Zusammenfassung
Prompt-Injection ist ein Angriff, der ein Sprachmodell dazu bringt, vom Angreifer gelieferten Anweisungen statt seinen eigenen zu folgen, und nutzt aus, dass Modelle vertrauenswürdige Anweisungen nicht von nicht vertrauenswürdigen Daten trennen. Die direkte Injection stammt vom Nutzer, während die indirekte Injection Anweisungen in Inhalten versteckt, die das Modell aufnimmt, und die gefährlichere Variante für Retrieval- und Agentensysteme ist. Sie lässt sich nicht vollständig beseitigen, daher ist die Antwort geschichtet: Vertrauensstufen trennen, die Berechtigungen des Modells einschränken, Eingaben und Handlungen prüfen, Werkzeuge isolieren und feindlich testen. Für die Governance besteht die Erwartung darin, zu zeigen, dass das Risiko in Ihrem Bedrohungsmodell steht, getestet und eingedämmt ist, nicht Immunität zu behaupten.