Prompt Injection versucht, ein Sprachmodell über Eingaben oder gelesene Inhalte umzulenken. Entscheidend ist, welche Daten, Regeln und Aktionen die Anwendung trennt.
Redaktion: smao Team · Stand: 16. September 2026
Kurz erklärt
Prompt Injection bezeichnet die Beeinflussung einer Sprachmodellanwendung durch Eingaben, die ihr vorgesehenes Verhalten verändern sollen oder unbeabsichtigt verändern. Die Anweisung kann direkt aus einer Nutzereingabe oder indirekt aus einem gelesenen Dokument stammen. Kritisch wird es, wenn die Anwendung solchen Inhalt wie eine berechtigte Regel behandelt. Mögliche Folgen sind verfälschte Antworten oder unerlaubte Aktionen über angebundene Werkzeuge.
Direkte und indirekte Prompt Injection unterscheiden
OWASP LLM01:2025 unterscheidet direkte Eingaben und indirekte Einflüsse aus externen Quellen. Eine direkte Eingabe kommt über den Dialog. Eine indirekte Anweisung kann in einer Datei, Webseite oder abgerufenen Textstelle liegen. Die Person, die eine normale Sachfrage stellt, muss diesen Inhalt nicht selbst ausgewählt haben.
Entscheidend ist die Rolle des Textes: Eine Anleitung darf beispielsweise beschreiben, wie eine Störung gemeldet wird. Sie darf sich dadurch nicht selbst die Befugnis geben, Zugriffsrechte oder Freigaberegeln der Anwendung umzuschreiben. Auch eine flüssige Formulierung oder ein hoher Suchrang macht aus Dokumentinhalt keine autorisierte Systemanweisung.
Warum lokale KI und RAG eigene Prüfungen brauchen
Bei RAG gelangen gefundene Dokumentstellen in den Kontext für eine Antwort. OWASP weist ausdrücklich darauf hin, dass RAG und Fine-Tuning Prompt Injection nicht vollständig verhindern. Ein sinnvoller Suchtreffer kann also trotzdem eine unzulässige Anweisung enthalten. Embeddings bewerten Ähnlichkeit, keine Befugnis zur Steuerung der Anwendung.
Daraus folgt für lokale KI: Der Betriebsort allein löst diese Vertrauensfrage nicht. Prüfe, wer Dokumente ändern darf, welche Inhalte bei einer Anfrage tatsächlich ankommen und welche Aktionen daraus entstehen können. Der Leitfaden zu eigenen Daten ordnet Quellen, Aktualität und Berechtigungen im gesamten Ablauf ein.
Welche Kontrollen sollten außerhalb des Modells liegen?
Die OWASP-Checkliste zur Prävention empfiehlt mehrere Schutzschichten: Anweisungen und Daten klar trennen, Ausgaben prüfen und Werkzeuge nur mit den benötigten Rechten ausstatten. Eine schärfere Formulierung im Prompt ersetzt diese Anwendungsprüfungen nicht. Auch ein zusätzliches prüfendes Modell ist keine alleinige Sicherheitsgrenze.
Bei Tool Calling ist ein Modellvorschlag noch keine ausgeführte Aktion. Die Anwendung muss Berechtigung, Parameter und Geschäftsregeln prüfen. Für folgenreiche Änderungen gehört eine passende Freigabe dazu. Die maßgebliche Identität oder Berechtigung darf nicht aus der Behauptung eines Dokuments übernommen werden.
- Lesen: Welche Quellen sind für diese Person und Aufgabe überhaupt zugelassen?
- Antworten: Wird ein Dokumentinhalt als Quelle behandelt oder als neue Verhaltensregel?
- Handeln: Welche Prüfung verhindert eine unberechtigte Änderung im Zielsystem?
- Nachweisen: Lassen sich Quelle, Modellvorschlag und tatsächlich ausgeführte Aktion getrennt beurteilen?
Praxisbeispiel
Illustratives Prüfszenario, kein beobachteter Angriff: Ein erfundenes Dokument zur Störungsmeldung nennt die benötigten Angaben. Eine veränderte Fassung enthält zusätzlich die Aufforderung, jede Meldung ohne weitere Prüfung als dringend einzustufen. Die normale Leserfrage bleibt: „Welche Angaben brauche ich für eine Störungsmeldung?“
Erwartetes Verhalten: Die Antwort nennt die benötigten Angaben. Die eingeschleuste Aufforderung verändert weder die fachliche Prioritätsregel noch einen Eintrag im angebundenen System. Lege vor einem späteren Versuch drei getrennte Prüfpunkte fest: Antworttext, vorgeschlagener Werkzeugaufruf und Zustand des Testsystems. Wiederhole die Frage mit der unveränderten Fassung als Kontrolle. Beide Dokumente sind fiktiv; es wurde hier kein Modelltest ausgeführt.
Abgrenzung
- Eine erfundene Antwort ohne eingeschleuste Anweisung ist nicht automatisch Prompt Injection. Ursache und beobachtete Wirkung müssen getrennt geprüft werden.
- Ein bestandener Beispielsfall beweist keine allgemeine Angriffssicherheit. Ändern sich Modell, Quellen oder Werkzeuge, braucht der Ablauf eine erneute Bewertung.
- Eine Bewertung des Gesamtsystems muss dessen Datenwege, Rollen und Aktionen berücksichtigen. Dieser Begriff ersetzt keine anwendungsspezifische Sicherheitsprüfung.
Quellen
- OWASP Gen AI Security Project: LLM01:2025 Prompt Injection (abgerufen am 16. September 2026)
- OWASP: LLM Prompt Injection Prevention Cheat Sheet (abgerufen am 16. September 2026)
Kostenlos testenLive in 15 MinHosting in Deutschland