prompt injections.de
Glossar

Indirekte Prompt Injection

Indirekte Prompt Injection entsteht, wenn eine LLM-Anwendung Inhalte aus einer externen Quelle abruft und das Modell darin enthaltenen Text so verarbeitet, dass seine vorgesehene Aufgabe verändert wird. Der Einflussweg führt damit nicht über das sichtbare Eingabefeld, sondern etwa über Webseiten, Dateien, E-Mails, Datenbankfelder oder Werkzeugergebnisse. OWASP fasst diese Form als Verarbeitung externer Inhalte auf, die das Modellverhalten unbeabsichtigt oder gezielt verändern können.1

Einordnung

Gegenüber der direkten Prompt Injection verändert sich vor allem das Bedrohungsmodell. Die angreifende Person muss keinen Benutzerzugang zur Zielanwendung besitzen; ausreichend ist, dass ein von ihr beeinflussbarer Inhalt später in einen relevanten Abruf- und Verarbeitungspfad gelangt. Das ist bei browserfähigen Assistenten, RAG-Anwendungen, E-Mail-Analysen und Agenten mit Werkzeugzugriff besonders bedeutsam. Der Fachbegriff beschreibt dabei nicht jede falsche Information in einer Quelle. Erst wenn der Inhalt das Modell zu einer vom Betreiberziel abweichenden Handlung oder Ausgabe veranlasst, liegt die sicherheitsrelevante Manipulation vor.

Auch eine sauber markierte Fremdquelle ist keine harte Garantie. Die Quellenkennzeichnung kann dem Modell helfen, ihren Status zu erkennen; sie verhindert aber nicht zuverlässig, dass der Inhalt die Modellentscheidung beeinflusst. Wu, Cecchetti und Xiao argumentieren deshalb für eine systemweite Informationsflusskontrolle: Nicht vertrauenswürdige Eingaben sollen aus sensiblen Planungsschritten herausgehalten und durch einen Monitor kontrolliert werden.2

Dokumentiertes Beispiel

Greshake und Kollegen legten 2023 eine einflussreiche Analyse dieser Angriffsklasse vor. Ihre Forschungsarbeit zeigt, wie strategisch in voraussichtlich abgerufenen Daten platzierter Text LLM-integrierte Anwendungen aus der Ferne beeinflussen kann. Die Autoren demonstrierten die Machbarkeit gegen reale Anwendungen, darunter Bing Chat mit GPT-4, und betrachteten Auswirkungen wie Datendiebstahl, Funktionsmanipulation und die Steuerung von API-Aufrufen.3 Das Beispiel ist ein Labor- und Forschungsnachweis; es ersetzt keine Aussage über die Verwundbarkeit einer konkreten heutigen Produktkonfiguration.

Bedeutung für die Abwehr

Betreiber sollten alle abgerufenen Inhalte als nicht vertrauenswürdig klassifizieren und ihre Herkunft bis zur Ausgabe beziehungsweise Aktion nachvollziehbar halten. Ein Modell, das fremde Dokumente lesen darf, sollte nicht automatisch über dieselben Rechte verfügen wie eine Komponente, die Daten exportiert oder externe Aktionen auslöst. Hilfreich sind getrennte Verarbeitungspfade, strikte Werkzeugberechtigungen, serverseitige Parameterprüfung und menschliche Freigaben bei irreversiblen Folgen.1

Für RAG gilt zusätzlich: Retrieval verbessert die Wissensgrundlage, beseitigt aber Prompt Injection nicht. Relevanzbewertung und Quellenprüfung sind Qualitätsmechanismen, keine Autorisierungsentscheidung. Sicherheitsprüfungen müssen daher den gesamten Pfad von externem Inhalt über Modellkontext bis zur möglichen Aktion testen, nicht nur den finalen Text der Antwort.

Quellen

  1. OWASP Foundation, „LLM01:2026 Prompt Injection“, 3. August 2026, https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/. ↩
  2. Fangzhou Wu, Ethan Cecchetti und Chaowei Xiao, „System-Level Defense against Indirect Prompt Injection Attacks: An Information Flow Control Perspective“, überarbeitete Fassung 10. Oktober 2024, https://arxiv.org/abs/2409.19091. ↩
  3. Kai Greshake et al., „Not what you’ve signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection“, überarbeitete Fassung 5. Mai 2023, https://arxiv.org/abs/2302.12173. ↩

Im Zusammenhang