Leitfaden

Prompt-Injection testen: Testplan, Testfälle und Bewertung

Von Lucas Weber, CyberSec42 · Stand 28.10.2026

Prompt-Injection testen heißt: Sie bringen kontrollierte, harmlose Anweisungen über jeden Weg in Ihre LLM-Anwendung, auf dem Text das Modell erreicht, also Chatfenster, Dokumente, RAG-Quellen, Webseiten, Tool-Ausgaben und E-Mails, und prüfen, ob die Anwendung danach etwas tut, das sie nicht tun soll. Ein Treffer ist nicht die ungewöhnliche Antwort, sondern die Wirkung: Daten fließen ab, ein Werkzeug wird ausgelöst, eine Grenze wird überschritten. Weil Sprachmodelle nicht zuverlässig zwischen Anweisung und Daten unterscheiden, gehört dieser Test zu jeder Anwendung mit LLM, bevor sie echte Daten oder echte Rechte bekommt.

Direkt und indirekt: was Sie eigentlich testen

Bei einer direkten Prompt-Injection gibt die Person, die die Anwendung nutzt, selbst eine Anweisung ein, die das Verhalten des Modells umlenkt. Bei einer indirekten Prompt-Injection steckt die Anweisung in Inhalten, die das Modell liest, etwa in einer Webseite, einer Datei oder einer Werkzeug-Antwort. Angreifer und Nutzer sind dann verschiedene Personen, und geschädigt wird oft gerade der Nutzer. So beschreiben es OWASP in LLM01 Prompt Injection und NIST in der Taxonomie NIST AI 100-2 E2025.

Für einen Testplan reicht diese Unterscheidung. Wie der Angriff im Detail abläuft, warum Werkzeug-Beschreibungen ebenfalls ein Einfallstor sind und was die „lethal trifecta“ bedeutet, steht im Beitrag Prompt-Injection und Tool-Poisoning in MCP-Servern. Wo Prompt-Injection unter den übrigen LLM-Risiken steht, erklärt die OWASP Top 10 für LLM-Anwendungen.

Eine Voraussetzung gilt für jeden Test: Weder OWASP noch das BSI noch NIST kennen derzeit einen Schutz, der Prompt-Injection vollständig verhindert. Das BSI nennt die fehlende Trennung von Daten und Anweisungen eine intrinsische Schwachstelle der derzeitigen Technologie. Ein Test beantwortet deshalb nicht die Frage „Ist die Anwendung immun?“, sondern: „Was kann passieren, wenn das Modell getäuscht wird, und greifen unsere Grenzen dann?“

Schritt 1: Angriffsflächen inventarisieren

Der häufigste Fehler beim Testen ist, nur das Chatfenster zu prüfen. Das deckt die direkte Variante ab, aber kaum die indirekte. Legen Sie deshalb zuerst eine Liste aller Wege an, auf denen Text in den Kontext des Modells gelangt, und notieren Sie, wer diesen Text kontrollieren kann.

Die zweite Liste ist genauso wichtig: Was kann die Anwendung tun, nachdem das Modell geantwortet hat? Notieren Sie jede Wirkung, etwa Markdown oder HTML im Browser darstellen, Links anzeigen, Bilder nachladen, Werkzeuge aufrufen, Mails senden, Datensätze ändern, Code ausführen, Dateien schreiben. Notieren Sie auch, mit welcher Identität und welchen Rechten das geschieht. Erst die Kombination aus Eingangsweg und Wirkung ergibt einen sinnvollen Testfall. Eine Injection über eine Webseite ist bei einem reinen Textzusammenfasser ärgerlich. Bei einem Agenten, der danach Mails versenden darf, ist sie ernst.

Schritt 2: Testfälle nach Kategorien

Die folgenden Kategorien decken die Wirkungen ab, die OWASP, NIST und das BSI übereinstimmend beschreiben. Die Beispiel-Formulierungen sind bewusst harmlos und generisch. Sie arbeiten mit einem Kanarienwert, also einem eindeutigen Wort wie KANARIE-7Q4, und einer Testadresse unter Ihrer Kontrolle. So erkennen Sie einen Treffer sicher, ohne dass echter Schaden entsteht. Jede Formulierung testen Sie sowohl direkt im Chat als auch versteckt in jedem Eingangsweg aus Schritt 1.

Die Kategorie Datenabfluss verdient besondere Sorgfalt. OWASP beschreibt in LLM01 genau dieses Szenario: Eine versteckte Anweisung in einer Webseite lässt das Modell ein Bild mit einer Adresse einfügen, und das private Gespräch fließt ab. NIST nennt die Darstellung von Markdown-Bildern ausdrücklich als Weg zur Exfiltration, und der BSI-Basisschutz gegen Indirect Prompt Injection hält fest, dass dieser Abfluss ohne jede Interaktion des Nutzers geschehen kann, sobald der Browser das Bild lädt. Nutzen Sie für diesen Test ausschließlich eine Domain, die Ihnen gehört, und protokollieren Sie dort die Abrufe.

Varianten, die Sie je Kategorie durchspielen

Eine einzelne, gut lesbare Formulierung reicht nicht. Filter und Modelle reagieren auf die Form. Testen Sie jede Kategorie deshalb in mehreren Varianten:

• Versteckt: weiße Schrift auf weißem Grund, Schriftgröße null, Kommentare, Metadaten und Annotationen eines PDF. Das BSI nennt diese Formen sowohl in seiner Warnung von 2023 als auch im Basisschutz von 2026.
• Unsichtbare Zeichen: Unicode-Zeichen, die im Editor nicht sichtbar sind, und Zeichen, die lateinischen Buchstaben zum Verwechseln ähneln.
• Kodiert oder übersetzt: dieselbe Anweisung in Base64, in einer anderen Sprache oder gemischt. OWASP führt mehrsprachige und kodierte Angriffe als eigenes Szenario.
• Aufgeteilt: die Anweisung über mehrere Stellen eines Dokuments verteilt, die erst zusammen einen Sinn ergeben. OWASP beschreibt das als Payload Splitting.
• Multimodal: die Anweisung als Text in einem Bild, wenn Ihre Anwendung Bilder verarbeitet.
• Vorgetäuschte Struktur: Text, der aussieht wie ein Rollenwechsel oder das Ende eines Datenblocks, zum Beispiel ein nachgeahmtes Trennzeichen oder ein schließendes XML-Tag. Der BSI-Basisschutz nennt diese Form ausdrücklich.

Schritt 3: Tests durchführen

Testen Sie nur Anwendungen, die Ihnen gehören, oder solche, für die Sie eine schriftliche Erlaubnis haben. Das gilt auch für Dienste Dritter, die Ihre Anwendung einbindet. Fünf Punkte machen den Unterschied zwischen einem Test und einem Ausprobieren:

• Realistische Testumgebung. Eine Staging-Umgebung mit denselben Werkzeugen, Rechten und Datenquellen wie im Betrieb, aber mit Testdaten. Ein Test ohne angebundene Werkzeuge sagt über Tool-Missbrauch nichts aus.
• Mehrere Testkonten. Mindestens ein Konto als „Angreifer“, der Inhalte ablegt, und ein zweites als „Opfer“, das die Anwendung normal benutzt. Nur so sehen Sie indirekte und mehrstufige Effekte.
• Wiederholung. Jeden Testfall mehrfach ausführen und die Trefferquote notieren, etwa 3 von 10. Das BSI weist im Basisschutz darauf hin, dass Modellverhalten probabilistisch ist. Ein Fall, der beim ersten Mal nicht greift, ist nicht erledigt.
• Vollständiges Protokoll. Je Durchlauf: eingeschleuster Text, Eingangsweg, Nutzeranfrage, Modellausgabe, alle Werkzeugaufrufe mit Argumenten und die Abrufe auf Ihrem Testserver. Ohne Werkzeug-Protokoll übersehen Sie Treffer, die in der Chat-Antwort nicht sichtbar sind.
• Anpassung an Ihre Abwehr. Wenn ein Filter eine Formulierung blockt, umformulieren und erneut testen. OWASP empfiehlt, das Modell im Test wie einen nicht vertrauenswürdigen Nutzer zu behandeln. Der BSI-Basisschutz verweist darauf, dass sich selbst gezielt entwickelte Abwehrmaßnahmen durch adaptive Angriffe umgehen lassen.

Wiederholen Sie die Tests nach jeder Änderung an Modell, Systemprompt, Werkzeugen oder Datenquellen. Ein Modellwechsel kann das Verhalten in beide Richtungen verschieben. Wer den Test in ein größeres Red-Teaming einbetten will, findet im GenAI Red Teaming Guide des OWASP GenAI Security Project vom Januar 2025 eine strukturierte, risikobasierte Methodik, die Schwächen des Modells und der Systemeinbindung gemeinsam betrachtet.

Schritt 4: Treffer bewerten

Ein Treffer liegt vor, wenn eingeschleuster Inhalt eine Wirkung erzielt, die die Anwendung nicht haben soll. Eine merkwürdige Antwort allein ist meist ein Hinweis, noch kein Befund. Entscheidend ist, was danach passiert. Diese Einordnung nach Auswirkung hat sich in der Praxis bewährt. Sie ist keine Norm und sollte an Ihre Daten und Prozesse angepasst werden:

Zur Systemprompt-Abfrage eine Klarstellung: OWASP hält in LLM07:2025 System Prompt Leakage fest, dass der Systemprompt kein Geheimnis und keine Sicherheitskontrolle sein soll und dass seine Offenlegung allein nicht das eigentliche Risiko ist. Kritisch wird es, wenn darin Zugangsdaten stehen oder wenn die Anwendung Berechtigungsprüfungen an das Modell delegiert. Ein preisgegebener Systemprompt ist deshalb vor allem ein Hinweis darauf, dort nach Geheimnissen und Rechtelogik zu suchen.

Was automatische Werkzeuge leisten und was nicht

Es gibt frei verfügbare Werkzeuge, die viele Testvarianten automatisch gegen ein Modell oder eine Anwendung schicken. NIST nennt in AI 100-2 E2025 ausdrücklich zwei Open-Source-Werkzeuge, die Entwicklern helfen sollen, Schwachstellen in Modellen zu finden, und ein Evaluationsframework für Agenten:

• garak, ein Scanner für Schwachstellen in LLMs, Apache-2.0-Lizenz.
• PyRIT, ein Python-Framework zur Risikoerkennung in generativer KI, MIT-Lizenz. Das ursprüngliche Repository unter Azure verweist inzwischen auf diese Adresse.
• AgentDojo, eine Umgebung, die misst, wie anfällig Agenten für Prompt-Injection über Werkzeug-Ausgaben sind.

Das BSI stellt zum Basisschutz ein eigenes Repository bereit. Es enthält die fünf Basismaßnahmen und nach Angabe des BSI einen Agenten-Skill, der dokumentbasierte LLM-Chats daraufhin prüft, ob diese Maßnahmen umgesetzt sind.

Solche Werkzeuge sind nützlich für Breite und für Regressionstests nach Änderungen. Drei Grenzen bleiben:

• Sie kennen Ihre Wirkungen nicht. Ein Scanner sieht die Antwort des Modells. Ob danach in Ihrer Anwendung eine Mail verschickt, ein Datensatz geändert oder ein Bild nachgeladen wird, sieht er nur, wenn Sie das ausdrücklich verdrahten.
• Sie kennen Ihre Eingangswege nicht. Eine Anweisung in einem Wiki-Eintrag, die erst bei einem anderen Nutzer wirkt, entsteht nicht aus einer Liste bekannter Prompts.
• Ein grünes Ergebnis ist kein Nachweis. Gemessen werden Stichproben. Das BSI betont im Basisschutz, dass auch Benchmarks keine Robustheit im Einzelfall beweisen.

Ein belastbarer Test verbindet beides: Werkzeuge für die Masse der Varianten, gezielte manuelle Fälle für die Kombination aus Eingangsweg, Rechten und Wirkung in Ihrer Anwendung.

Gegenmaßnahmen in Kürze

Weil sich Injection nicht vollständig verhindern lässt, setzen die wirksamen Maßnahmen bei der Wirkung an. OWASP, NIST und BSI stimmen in diesen Punkten überein:

• Rechte begrenzen. Werkzeuge und Berechtigungen auf das Minimum der Aufgabe beschränken, Rechte im Anwendungscode prüfen, nicht im Prompt. Wer liest, muss nicht gleichzeitig senden dürfen.
• Ausgaben behandeln. Modellausgaben wie fremde Eingaben behandeln. Markdown-Bilder und Links nur zu freigegebenen Adressen zulassen, Ausgaben vor der Weitergabe an Browser, Datenbank oder Shell prüfen. Der BSI-Basisschutz empfiehlt dafür eine Liste erlaubter Adressen und im Zweifel das Sperren.
• Bestätigung bei Aktionen. Folgenreiche Schritte erst nach Freigabe durch einen Menschen ausführen, mit Anzeige der genauen Aktion. Das empfehlen OWASP und BSI gleichermaßen.
• Fremde Inhalte kennzeichnen. Nicht vertrauenswürdige Inhalte im Prompt klar als Daten abgrenzen und unsichtbare Zeichen vorher entfernen. Das senkt die Trefferquote, verhindert Treffer aber nicht sicher.

Für Agenten und MCP-Server vertieft der Leitfaden KI-Agenten absichern diese Grenzen.

Checkliste für Ihren Prompt-Injection-Test

Häufige Fragen

Weiterlesen

• AI Red Teaming erklärt
• Prompt-Injection und Tool-Poisoning in MCP-Servern
• Die OWASP Top 10 für LLM-Anwendungen, praktisch erklärt
• Microsoft 365 Copilot: Sicherheit und Risiken
• Leistung: KI-Pentest und MCP-Sicherheit

Quellen

• OWASP GenAI Security Project: LLM01:2025 Prompt Injection
• OWASP GenAI Security Project: LLM07:2025 System Prompt Leakage
• OWASP GenAI Security Project: GenAI Red Teaming Guide
• NIST AI 100-2 E2025: Adversarial Machine Learning, A Taxonomy and Terminology of Attacks and Mitigations
• BSI: Indirect Prompt Injections, Intrinsische Schwachstelle in anwendungsintegrierten KI-Sprachmodellen (CSW 2023-249034-1032, 18.07.2023)
• BSI: Basisschutz gegen Indirect Prompt Injections in dokumentbasierten LLM-Chats (2026)
• BSI auf GitHub: baseline_defense_lab_indirectPromptInjections
• GitHub: NVIDIA/garak
• GitHub: microsoft/PyRIT
• GitHub: ethz-spylab/agentdojo