Ein E-Mail-Assistent empfängt eine Nachricht mit der Bitte um eine Zusammenfassung, ruft zugehörige Unternehmensdokumente ab, nutzt ein Kalendertool und erstellt eine prägnante HTML-Antwort. Eine einzige, nicht vertrauenswürdige E-Mail kann als Inhalt in diesen Ablauf gelangen, wobei das Modell deren Text gemeinsam mit den eigentlichen Aufgabenanweisungen verarbeitet. Wenn dieser Inhalt die Ausgabe von „Fasse diese Nachricht zusammen“ hin zu einer unbeabsichtigten Aktion verändert, liegt eine Prompt Injection vor – eine Eingabe, die das Verhalten des Modells über die vom Anwendungszweck vorgesehene Aufgabe hinaus beeinflusst.
Bei unserem Assistenten gibt es fünf Stellen, an denen Inhalte in die Anfrage an das Modell einfließen. Der Benutzer liefert den E-Mail-Text, das Abrufsystem (Retriever) liefert indizierte Textpassagen, angebundene Tools liefern Daten, das Modell gibt Text oder Tool-Argumente aus und die Rendering-Komponente wandelt diese Ausgabe in HTML um. Jeder dieser Schritte weist ein unterschiedliches Vertrauensniveau auf, doch das Modell empfängt einen kombinierten Token-Datenstrom anstatt einer durch die Anwendung erzwungenen Sicherheitsgrenze.
Bevor wir Schutzmaßnahmen bewerten, untersuchen wir, an welchen Stellen Daten in diesem Ablauf zu Anweisungen werden können.
Der Ablauf verdeutlicht, warum eine reine Filterung des Chat-Eingabefelds nicht ausreicht. Eine externe E-Mail kann die eingeschleuste Anweisung enthalten, ein Retrieval-Prozess kann sie in den Kontext einbetten, und das Ergebnis eines Tools kann sie in einem späteren Schritt wiederholen. Das HTML-Rendering stellt eine weitere kritische Schnittstelle dar, da eine Ausgabe, die für das Modell lediglich Text ist, im Browser zu einem aktiven Link, Markup oder einer Anfrage werden kann. Kennzeichnen Sie jede Quelle vor der Einbindung in den Kontext als vertrauenswürdig, bedingt vertrauenswürdig oder nicht vertrauenswürdig und speichern Sie diese Kennzeichnung in den Protokollen.
Genau dieser gemischte Datenfluss bildet den Anwendungsbereich von OWASP LLM01:2026. Er deckt sowohl die direkte Einschleusung (Injection) über Benutzereingaben als auch die indirekte Einschleusung über abgerufene Dokumente, E-Mails, Webseiten, Tool-Ausgaben, persistenten Speicher sowie Bilder, Audio- und Videodateien ab. Ein direkter Fall beginnt mit einer Nachricht des Benutzers. Ein indirekter Fall liegt vor, wenn der Textkörper einer E-Mail im Retrieval-Index unseres Assistenten Inhalte liefert, die der Benutzer weder verfasst noch gesehen hat.
Jeden Fall können wir anhand von drei Achsen klassifizieren. Die Eingabeschnittstelle (Delivery Surface) bezeichnet den Punkt, an dem der Inhalt in das System gelangt, etwa über eine E-Mail oder eine Tool-Antwort. Die Weiterleitung (Propagation) beschreibt den nächsten Schritt des Datenflusses, beispielsweise von einem Retrieval-Ergebnis in den persistenten Speicher. Die Kodierung (Encoding) bezieht sich auf die Darstellungsform, etwa als Klartext, mittels versteckter Unicode-Zeichen oder als in ein Bild eingebettete Anweisungen. Diese Klassifizierung ermöglicht es uns, den tatsächlichen Übertragungsweg zu überprüfen, anstatt uns lediglich auf bestimmte Phrasenmuster zu konzentrieren.
Herkömmliche Parametrisierung verhindert, dass Daten die Syntax einer Abfrage verändern, da die Datenbank Parameter separat behandelt. Aktuelle LLM-Anwendungen bieten keine vergleichbare, saubere Trennung, wenn Anweisungen und Daten als Tokens im selben Kontext eintreffen. Trennzeichen und Bezeichnungen können zwar die Absicht verdeutlichen, setzen jedoch keine Zugriffsberechtigungen durch. Die Sicherheitsgrenze muss stattdessen außerhalb des Modells liegen; dort prüft Code die Berechtigungen, validiert Argumente und schränkt den Wirkungsbereich der Ausgabe ein.
Arbeitshypothese Gehen Sie davon aus, dass jede Eingabe in das Modell die Ausgabe beeinflussen kann – selbst wenn sie über ein internes Abrufsystem (Retrieval-System) gelangt ist.
Sobald eine eingeschleuste E-Mail die Ausgabe beeinflusst, hängt das Ergebnis davon ab, was die umgebende Anwendung zulässt. Wenn der Assistent verborgene Systeminhalte oder einen abgerufenen privaten Textabschnitt preisgibt, entspricht das Szenario der Schwachstelle OWASP LLM08:2026 (Hidden Context Exposure). Erzeugt er HTML, das der Renderer ohne Bereinigung (Sanitization) akzeptiert, oder Tool-Argumente, die nachgelagerter Code ohne Validierung ausführt, liegt OWASP LLM10:2026 (Improper Output Handling) vor. LLM01 ist die Kompromittierung auf der Eingabeseite, die diese Folgen auslöst.
Dieselbe Injection kann auch versuchen, eine unsichere Kalenderaktion auszulösen oder Daten dauerhaft im Abruf-Korpus zu speichern. Diese Risiken verschärfen sich, wenn ein Modell weitreichende Tools aufrufen kann; die Anfrage des Modells darf jedoch niemals als eigene Autorisierung dienen. Der Kalenderdienst sollte die Berechtigung des Benutzers prüfen, beschreibbare Felder einschränken und für folgenschwere Änderungen eine Bestätigung verlangen. Der Renderer sollte nur sichere Ausgabeformate zulassen. Jede Ebene begrenzt einen anderen Pfad, nachdem sich die Modellausgabe geändert hat.
Vergleichen Sie die Ergebnisse, um zu ermitteln, welche Grenze den jeweiligen Vorgang stoppen muss.