Wer Nutzer:innen erlaubt, PDFs in einen KI-Chat hochzuladen, lässt Fremde am Prompt mitschreiben. Das BSI hat am 14. September 2026 fünf Basismaßnahmen dagegen veröffentlicht: Eingabe-Bereinigung, Vertrauensbereich-Trennung, gehärteter System-Prompt, Modellauswahl mit Reasoning und Egress-Filter. Vollständigen Schutz verspricht das Amt ausdrücklich nicht.
Was ist eine Indirect Prompt Injection?
Eine Indirect Prompt Injection ist ein Angriff, bei dem die schädliche Anweisung nicht von der Person im Chat stammt, sondern aus einer Quelle, die das Modell verarbeitet: einem Dokument, einer Webseite, einer E-Mail. Angreifer und Nutzerin sind verschiedene Personen. Zuerst beschrieben haben das Muster Kai Greshake und Kolleg:innen 2023. In den OWASP Top 10 für LLM-Anwendungen steht Prompt Injection als Risiko LLM01 an erster Stelle.
Das Versteck ist banal: weiße Schrift auf weißem Grund, unsichtbare Unicode-Zeichen, Metadaten, Kommentare, Annotationen. Für das Auge ist dort nichts, für das Modell ist alles lesbar. Und das Modell hat ein Grundproblem, das das BSI in einem Satz fasst: Es kann allein nicht zwischen Nutzerauftrag, Systemanweisung und Daten unterscheiden, weil es alles als eine Kette von Tokens wahrnimmt. Viele Anwendungen extrahieren den Dokumenttext und übernehmen ihn eins zu eins in den Prompt. Ab da steht die fremde Anweisung gleichberechtigt neben Ihrer.
Drei dokumentierte Fälle, darunter die Zero-Click-Lücke EchoLeak in Microsoft 365 Copilot, stehen in unserem Beitrag Prompt Injection: Drei echte Fälle.
Woher kommen die fünf Maßnahmen?
Das Papier (Version 1.0, Referat T 25) beruht auf Red Teaming mehrerer dokumentbasierter LLM-Chats. Die Schwäche, die dabei immer wieder auftauchte: Dokumentinhalte landeten ungefiltert im Prompt, ohne klare Trennung vom Auftrag der Nutzer:innen. Besonders kritisch waren Datenabflüsse über Exfiltrationslinks. Daraus leitet das BSI fünf Maßnahmen ab, geordnet entlang der Verarbeitungskette vom Hochladen bis zur Antwort.
Die fünf Basismaßnahmen im Einzelnen
1. Eingabe-Bereinigung
Bevor der Text das Modell erreicht, wird er auf Zeichenebene gesäubert. Das Beispiel-PDF zerfällt dabei in vier Bereiche: Textkörper, Metadaten, Gliederung und Annotationen. Jeder Bereich wird normalisiert, unsichtbare Zeichen wie der Unicode-Tag-Block, Steuerzeichen für die Schreibrichtung und exotische Leerzeichen werden entfernt. Ein kyrillisches „а” wird auf das lateinische „a” zurückgeführt. Gefälschte Rollen-Trennzeichen wie <|system|> ersetzt der Filter durch [FILTERED].
2. Vertrauensbereich-Trennung
Der bereinigte Inhalt kommt in einen eigenen XML-Block, markiert als nicht vertrauenswürdig und versehen mit einer Zufalls-ID, die bei jeder Anfrage neu entsteht. Wer den Block mit einem eingeschleusten Schluss-Tag verlassen will, müsste diese ID kennen. Dazu kommt eine Sandwich-Defense: Vor dem Block, nach dem Block und am Ende der Nutzereingabe steht jeweils, dass hier Daten folgen und keine Anweisungen. Die ersten und letzten zweihundert Wörter des Dokuments werden zusätzlich mit Sonderzeichen durchsetzt, nach dem Spotlighting-Ansatz von Hines und Kolleg:innen (2024).
3. Gehärteter System-Prompt
Das BSI empfiehlt einen System-Prompt aus acht Teilen, als Struktur, nicht als festen Wortlaut. Kern ist eine Rangfolge: System-Prompt vor Nutzerauftrag, der Dokumentinhalt ohne jede Anweisungsbefugnis. Dazu kommen harte Verbote, Negativbeispiele für typische Tricks und ein geheimer Canary-Token, der pro Sitzung neu erzeugt wird und in keiner Form ausgegeben werden darf. Das BSI verweist selbst auf eine Studie (Geng und Kolleg:innen, 2026), nach der Modelle solche Hierarchien nicht zuverlässig einhalten.
4. Modellauswahl und Reasoning
Gegen Angriffe, die ohne technische Tarnung auskommen und allein durch geschickte Formulierung wirken, hilft nur ein robustes Modell. Das BSI rät, nach Benchmarks wie BIPIA oder InjecAgent auszuwählen, und nennt das Reasoning, also einen vorgeschalteten Denkschritt, „einen der wirksamsten Hebel” des gesamten Basisschutzes. Den Denkschritt selbst sollten Nutzer:innen nicht zu sehen bekommen, weil er seinerseits zum Angriffsweg werden kann.
5. Egress-Filter
Die letzte Linie prüft die fertige Antwort, bevor sie ausgeliefert wird. Taucht der Canary-Token auf, auch mit eingestreuten Leerzeichen, als Base64- oder Hexadezimalwert? Enthält die Antwort Fragmente des System-Prompts? Finden sich Marker wie „ignoring previous instructions”? Stecken Bild- oder Linkadressen darin, über die Daten abfließen könnten? Externe Adressen sind nur per Whitelist erlaubt. Eine kritische Antwort wird vollständig durch einen neutralen Text ersetzt.
Warum wirken die Maßnahmen nur gemeinsam?
Die fünf Maßnahmen greifen ineinander. Die Zufalls-ID koppelt Trennung und System-Prompt. Der Canary-Token und die typischen Formulierungen des System-Prompts sind genau das, wonach der Egress-Filter sucht. Fällt eine Maßnahme weg, kommen die Angriffe durch, die nur sie abgefangen hätte.
Wie hart diese Abhängigkeit ist, zeigt das Test-Lab, das das BSI auf GitHub begleitend veröffentlicht hat. Dort lassen sich die fünf Maßnahmen einzeln an- und ausschalten. Den gehärteten Prompt mit Canary ohne Egress-Filter nennt das README „net-harmful”: ein Geheimnis, das abfließen kann, ohne dass jemand es bemerkt. Für genau diese Kombination zeigt die Oberfläche eine Warnung. Und das README sagt deutlicher als das Papier, dass Prompt-Text allein wenig aushält. Die Last tragen Struktur, Reasoning und das Modell selbst.
Was leistet der Basisschutz nicht?
Das BSI ist in diesem Punkt ungewöhnlich offen. Indirect Prompt Injection gilt als nicht abschließend lösbar, die Maßnahmen seien Orientierung und keine hinreichende Schutzbedingung. Die Bereinigung arbeitet nur auf Zeichenebene; ein semantischer Angriff in sauberem, unauffälligem Text passiert sie unverändert. Benchmarks messen Stichproben und beweisen keine Robustheit im Einzelfall. Für Systeme, die als Agenten selbst handeln, empfiehlt das Amt zusätzlich eine menschliche Bestätigung sicherheitskritischer Aktionen.
Auch das Test-Lab ist kein Werkzeug für den Betrieb. Laut README wird es nicht gewartet, hat keine Anmeldung und soll ausschließlich lokal laufen. Für das Frontend meldet das README selbst sechs schwerwiegende, ungepatchte Sicherheitswarnungen in den Abhängigkeiten. Und das voreingestellte Modell gemma3 unterstützt den Reasoning-Kanal gar nicht: Schalter 4 bleibt dort wirkungslos, was das Lab offen ausweist. Zum Repository gehört außerdem ein Agenten-Skill, der eine bestehende Anwendung darauf prüft, ob die fünf Maßnahmen umgesetzt sind.
Was Sie jetzt tun können
Die meisten Unternehmen bauen keinen eigenen Dokumenten-Chat, sie kaufen einen. Dann werden aus den fünf Maßnahmen fünf Fragen an den Anbieter:
- Welche Zeichen entfernt Ihr System aus hochgeladenen Dokumenten, und werden auch Metadaten und Kommentare bereinigt?
- Wie trennen Sie im Prompt den Dokumentinhalt vom Auftrag der Nutzer:innen?
- Legt der System-Prompt eine feste Rangfolge fest, und gibt es einen Canary-Token?
- Welches Modell läuft, ist Reasoning aktiv, und nach welchen Benchmarks wurde es ausgewählt?
- Wird jede Antwort vor der Auslieferung geprüft, und lädt der Chat externe Bilder nur von freigegebenen Adressen?
Wer selbst entwickelt, nimmt das Papier als Prüfliste und das Lab als Übungsgelände, lokal und abgeschottet. Ein anwendungsspezifisches Red Teaming und eine eigene Sicherheitsbewertung ersetzt beides nicht, schreibt das BSI.
Cheat Sheet: Die fünf Maßnahmen auf einen Blick
| Maßnahme | Stelle in der Kette | Fängt ab | Fängt nicht ab |
|---|---|---|---|
| Eingabe-Bereinigung | vor dem Modell | unsichtbare Zeichen, Doppelgänger-Buchstaben, gefälschte Rollen-Tags | Angriffe in sauberem Klartext |
| Vertrauensbereich-Trennung | Aufbau des Prompts | Anweisungen, die sich als Nutzerauftrag ausgeben | Modelle, die die Markierung übergehen |
| Gehärteter System-Prompt | System-Prompt | überschriebene Regeln, vorgetäuschte Rollenwechsel | umgangene Hierarchien; ohne Egress-Filter sogar schädlich |
| Modellauswahl und Reasoning | Modell | rhetorisch getarnte Anweisungen | Einzelfälle, die kein Benchmark abbildet |
| Egress-Filter | vor der Auslieferung | Token-Abfluss, Prompt-Lecks, Exfiltrationslinks | unbekannte Muster; wirkt erst nach der Erzeugung |
Quellen
- Bundesamt für Sicherheit in der Informationstechnik (2026): Basisschutz gegen Indirect Prompt Injections in dokumentbasierten LLM-Chats, Version 1.0, 14.09.2026. https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/KI/Basisschutz_Indirect-Prompt-Injections_LLM.pdf?__blob=publicationFile&v=5
- Bundesamt für Sicherheit in der Informationstechnik: Baseline-Defense-Lab, GitHub-Repository, Version 0.1.0, Lizenz EUPL-1.2. https://github.com/BSI-Bund/baseline_defense_lab_indirectPromptInjections
- Greshake, Kai et al. (2023): Not what you’ve signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection. In: Proceedings of the 16th ACM Workshop on Artificial Intelligence and Security, S. 79–90.
- Hines, K. et al. (2024): Defending against indirect prompt injection attacks with spotlighting. In: Proceedings CAMLIS 2024, CEUR Workshop Proceedings, Bd. 3920.
- Geng, Y. et al. (2026): Control Illusion: The Failure of Instruction Hierarchies in Large Language Models. In: Proceedings of the AAAI Conference on Artificial Intelligence, Bd. 40.
- OWASP (2026): OWASP Top 10 for LLM Applications 2026. https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/