Indirekte Prompt Injection

Was ist indirekte Prompt Injection?

Indirekte Prompt Injection liegt vor, wenn angreiferkontrollierte, anweisungsähnliche Inhalte eine LLM-Anwendung über eine Ressource oder einen Inhaltspfad erreichen und nicht über die direkte Anfrage des primären Nutzers. Eine Website, E-Mail, ein Dokument, Suchergebnis, Wissensdatenbankeintrag, eine Quelldatei, ein Bild oder eine Tool-Ausgabe kann diesen Inhalt transportieren. Die Anwendung ruft die Ressource für eine legitime Aufgabe ab oder verarbeitet sie und macht eine Darstellung davon für das Modell sichtbar.

Der Angreifer muss die betroffene Anwendung möglicherweise nie selbst verwenden. Ebenso muss er nicht wissen, welcher Nutzer die Verarbeitung auslösen wird. Stattdessen kontrolliert oder beeinflusst er eine Ressource, die ein System voraussichtlich durchsucht, abruft, indexiert, zusammenfasst, klassifiziert oder analysiert. NIST beschreibt diesen Unterschied als Kontrolle einer Ressource statt direkten Anfragezugriffs. Der Mensch, der eine Nachricht öffnet oder eine Zusammenfassung anfordert, ist damit nicht zwingend das primäre Ziel. Die eingebettete Sprache kann sich gezielt an das verarbeitende AI-System richten.

Schädlicher Inhalt kann für Leser offensichtlich, visuell unauffällig, in Metadaten enthalten oder Teil einer nicht textuellen Darstellung sein, die das System in modellsichtbare Informationen umwandelt. Sichtbarkeit für Menschen ist nicht das entscheidende Merkmal. Relevant ist, ob angreiferbeeinflusster Inhalt in die AI-Verarbeitung gelangt und dort Aufgabe, Ausgabe, Plan oder vorgeschlagene Aktion verändert.

Wie indirekte Prompt Injection funktioniert

Die Anwendung behandelt externes Material als Daten. Ein Browser-Assistent ruft eine Website ab, ein E-Mail-Assistent liest eine Nachricht, ein Dokumentendienst extrahiert Text aus einem PDF und ein RAG-System sucht passende Abschnitte in einem Index. In jedem Fall beschafft eine Systemkomponente Inhalt und überführt ihn oder eine transformierte Darstellung davon in den Kontext des Modells.

Das Modell soll anschließend Anwendungsanweisungen, Nutzeraufgabe und externes Material gemeinsam interpretieren. Natürliche Sprache in dieser Ressource kann Fakten darstellen, eine Person zitieren, gewöhnliche Prosa enthalten oder wie eine Anweisung klingen. Verändert eine solche Formulierung die Interpretation der Modellaufgabe, überschreitet der Inhalt eine semantische Vertrauensgrenze. Abruf, Parsing und Speicherung können dabei technisch genau wie vorgesehen funktioniert haben.

Hier liegt ein wichtiger Unterschied: Vertrauen in Parser oder Speicher ist nicht dasselbe wie semantisches Vertrauen. Eine Datei kann gültig, frei von Schadsoftware, korrekt signiert und fehlerfrei eingelesen sein. Trotzdem kann sie Sprache enthalten, die das Modell umlenken soll. Ebenso kann ein Connector authentisch und korrekt implementiert sein, aber angreiferkontrollierte Daten aus einer öffentlichen Website, einem geteilten Postfach, einem kollaborativen Dokument, einem Ticketsystem oder einem Drittdienst zurückgeben.

Quellinhalt kann dynamisch während einer Anfrage eintreffen oder bereits Tage zuvor in einen Korpus aufgenommen worden sein. Im gespeicherten Fall kann die Manipulation bestehen bleiben, bis betroffenes Dokument, Chunk, Cache-Eintrag oder Indexdarstellung entfernt wurde. Der spätere Nutzer, dessen Anfrage den Abruf auslöst, muss keinerlei Beziehung zum Angreifer haben.

Erfolgskette des Angriffs

Ein vollständiger Pfad besitzt getrennt prüfbare Tore. Der Angreifer muss zunächst eine Quelle kontrollieren oder beeinflussen und den relevanten Workflow erreichen. Ihre Bedeutung muss Retrieval, Parsing, Extraktion, Zusammenfassung oder andere Transformationen überstehen, bevor sie modellsichtbar wird. Erst danach lässt sich eine Beeinflussung von Modell oder Plan beobachten. Eine materielle Schwachstelle braucht zusätzlich einen erreichbaren Daten- oder Fähigkeitspfad und eine Anwendungskontrolle, die fehlt, versagt oder mehr erlaubt, als Principal und Aufgabe zulassen.

Erfolg an einem Tor belegt nicht, dass das nächste ausnutzbar ist: Quellenplatzierung ist keine Verarbeitungserreichbarkeit, Erreichbarkeit keine Modellsichtbarkeit, Sichtbarkeit keine Beeinflussung, Beeinflussung keine Policy-Umgehung und eine Policy-Umgehung keine tatsächliche Wirkung, solange geschützte Daten, Befugnisse oder Nebenwirkungen nicht erreicht werden.

Die Kette lässt sich an mehreren Stellen unterbrechen: beim Retrieval, beim Aufbau des Kontexts, durch reduzierte Fähigkeiten, durch Ablehnung eines nicht autorisierten Zugriffs oder einer Aktion, durch Zielvalidierung oder vor der Ausführung einer Nebenwirkung. Prüfungen sollten deshalb getrennt erfassen, wo eine Beeinflussung gelang und wo Eindämmung wirkte. Nicht jede veränderte Modellausgabe ist bereits eine ausnutzbare Sicherheitslücke.

Offensive Review-Fragen

Eine autorisierte Prüfung sollte den vollständigen Pfad beschreiben, ohne aus der Kontrolle einer Quelle automatisch auf eine Auswirkung zu schließen. Die folgenden Fragen gelten vektorübergreifend. Umsetzungsdetails bleiben den spezialisierten Unterseiten vorbehalten.

Was im Modellkontext tatsächlich passiert

Nicht jedes Produkt stellt alle genannten Quellen bereit. Auch Nachrichtenstrukturen und Rollen unterscheiden sich zwischen Anbietern. Strukturierte Rollen, Datenbegrenzungen, Inhaltskennzeichnungen und getrennte Felder können dem Modell helfen, Aufgabenanweisungen von Arbeitsmaterial zu unterscheiden. Sie verbessern die Robustheit, schaffen in einer probabilistischen Sprachverarbeitung aber keine deterministische Isolation.

Die umgebende Anwendung muss die maßgebliche Provenienz jedes externen Elements erhalten. Sie sollte wissen, welcher Connector den Inhalt lieferte, von welcher Ressource und welchem Principal er stammt, wann er aufgenommen oder abgerufen wurde, welche Vertrauensrichtlinie gilt und welcher Nutzer aktuell Zugriff verlangt. Diese Fakten gehören als strukturierte Daten in die Anwendung. Das Modell darf sie nicht allein aus Text ableiten müssen.

Die Modellausgabe ist keine Autorisierung. Auch wenn das Modell einen Tool Call selbstsicher vorschlägt oder externen Text als sicher bezeichnet, muss die Anwendung Identität, Ressourcenberechtigung, Aktion, Parameter, Ziel und aktuelle Policy unabhängig prüfen. Das Modell kann bei der Interpretation helfen. Es kann nicht vertrauensunwürdigen Inhalt mit Befugnissen ausstatten.

Vertrauensgrenzen und Datenprovenienz

"Intern" ist keine Vertrauensklasse. Ein internes Wiki kann Beiträge vieler Beschäftigter enthalten. Eine Supportdatenbank speichert möglicherweise kundengesteuerte Felder. Ein geteiltes Repository kann Pull Requests externer Mitwirkender enthalten. Ein Postfach empfängt Nachrichten aus dem öffentlichen Internet. Für jede Quelle ist zu prüfen, wer sie schreiben darf, wie sie geprüft wird und welche Befugnisse der konsumierende Workflow besitzt.

Dokumente sollten für Sicherheitsentscheidungen zunächst als nicht vertrauenswürdig gelten. Eine höhere Einstufung braucht belastbare Angaben zu Provenienz, Verwahrungskette, wirksamen Berechtigungen und Schreibkontrolle. Allein die interne Ablage verleiht weder Anweisungsautorität noch belegt sie, dass das Dokument einen Workflow sicher steuern darf.

Quellidentität, initiierender Principal, Mandant, Ingestion-Pfad, Retrieval-Ereignis, Policy-Version, Ressourcenberechtigungen, Zeitstempel und Transformationen müssen außerhalb des LLM erhalten bleiben. Werden Inhalte in Chunks geteilt oder zwischen Systemen kopiert, braucht jeder abgeleitete Eintrag ausreichend Lineage zur ursprünglichen Ressource. Andernfalls erkennen Incident Responder zwar eine auffällige Modellausgabe, können aber weder die verursachende gespeicherte Quelle noch weitere betroffene Nutzer zuverlässig bestimmen.

Vier Sicherheitsfragen

Diese Dimensionen sind unabhängig. Eine Quelle kann authentisch, korrekt signiert oder intern gehostet sein und trotzdem keine Anweisungsautorität besitzen. Umgekehrt darf ein Modell vertrauliche Daten für einen bestimmten Zweck sehen, ohne dadurch die Erlaubnis zur Offenlegung, Übertragung oder sachfremden Verwendung zu erhalten.

Die Trennung verhindert eine Aufwertung von Vertrauen über Zwischenschritte. Quellenauthentizität beantwortet, woher Inhalt stammt, nicht ob seine Sprache das System steuern darf. Modellsichtbarkeit beantwortet, was verarbeitet wird, nicht was Modell oder Agent offenlegen oder ausführen dürfen.

Praxisbeispiele

Die folgenden Beispiele beschreiben vollständige Wege ohne optimierte Angriffstexte. Jedes trennt eine Veränderung des Modellverhaltens von der Frage, ob tatsächlich eine relevante Sicherheitsgrenze überschritten wurde.

Website-Zusammenfassung oder Browser-Assistent. Ein Nutzer bittet um die Zusammenfassung einer öffentlichen Seite. Die Website enthält Text, der sich an automatisierte Leser richtet und eine andere Aufgabe verlangt. Das Modell liefert eine verzerrte Zusammenfassung oder folgt der gewünschten Darstellung der Seite. Das ist ein Fehler der Anweisungskontrolle. Zu einer materiellen Sicherheitslücke wird er, wenn der Assistent zusätzlich privaten Kontext offenlegt, fremde Ressourcen besucht oder ohne Autorisierung Informationen nach außen übermittelt.

E-Mail-Assistent. Ein Angreifer sendet eine Nachricht, die später von einem Assistenten zusammengefasst oder eingeordnet wird. Der Inhalt versucht, die Klassifizierung zu beeinflussen, Zugriff auf sachfremde Datensätze anzustoßen oder den Empfänger einer Folgemitteilung zu ändern. Erstellt der Assistent nur einen sichtbar geprüften Entwurf, kann die Auswirkung begrenzt bleiben. Darf er dagegen selbstständig Kundendaten abrufen oder Nachrichten senden, sind unabhängige Autorisierungs- und Zielkontrollen zwingend.

RAG- oder Dokumenten-Wissensbasis. Ein Angreifer oder Mitwirkender mit geringem Vertrauen fügt ein Dokument hinzu, das später für die Anfrage eines anderen Nutzers als relevant eingestuft wird. Ein abgerufener Chunk versucht, die Aufgabe neu zu definieren oder anderen Kontext offenzulegen. Das Modell kann diesen Chunk mit legitimen Quellen verbinden. Eine Auswirkung über Nutzergrenzen hinweg entsteht nur, wenn Ingestion, Retrieval, Modellverhalten und fehlende nachgelagerte Kontrollen zusammenwirken.

Tool-Ausgabe oder Agentenkette. Ein Agent ruft ein vertrauenswürdiges Ticketsystem auf. Eine Ticketbeschreibung enthält Sprache, die den Agenten zu einem Zugriff auf ein sachfremdes Repository und anschließend zu einem externen Bericht bewegen soll. Der Connector hat korrekt gearbeitet. Seine Ausgabe transportierte trotzdem nicht vertrauenswürdigen Inhalt. Jeder folgende Zugriff und jede Kommunikation muss gegen Principal und Aufgabe autorisiert werden.

Häufige Vektoren indirekter Prompt Injection

Diese Kategorien bezeichnen Übertragungsflächen und Mechanismen. Sie können sich überschneiden: Ein PDF gelangt in einen RAG-Korpus, ein Suchergebnis verweist auf eine Website und die Ausgabe eines Agents wird zur Eingabe eines anderen. Auch Verschleierung und Kodierung können über extern bereitgestellte Inhalte transportiert werden; das verändert Darstellungs- und Umgehungseigenschaften, nicht die Einteilung in direkt und indirekt.

Persistente und gespeicherte Prompt Injection

Indirekte Beeinflussung kann länger bestehen als die Anfrage, durch die sie erstmals aufgenommen wurde. Relevante Speicherorte sind RAG-Korpora und Vektorindizes, Agent Memory, Gesprächszusammenfassungen, Scratchpads und geteilter Zustand, Datenbankfelder und kollaborative Datensätze, Caches sowie weitere abgeleitete Artefakte. Dadurch kann ein einzelner Beitrag spätere Nutzer, Sitzungen, Agents oder Aufgaben beeinflussen.

Persistenz zweiter Ordnung entsteht, wenn eine modellgenerierte Zusammenfassung, ein Memory-Eintrag, ein extrahierter Fakt, eine gecachte Antwort oder ein abgeleiteter Chunk den Einfluss erhält, nachdem die ursprüngliche Quelle geändert oder entfernt wurde. Das Löschen des Ausgangsdokuments kann die wirksame Anweisung deshalb in nachgelagertem Zustand zurücklassen. Ein unauffälliges Derivat kann außerdem die Provenienz verschleiern.

Die Eindämmung muss dem Lineage-Graphen folgen. Incident Responder müssen gegebenenfalls betroffene Chunks, Zusammenfassungen, Caches, Memory-Einträge, Indizes und Embeddings isolieren oder neu erstellen. Gleichzeitig sind Originalartefakte, Kennungen, Zeitstempel und Transformationsverlauf als Beweise zu sichern. Die Neuverarbeitung aus einer bekannten, sauberen Quelle ist sicherer als die Annahme, eine Löschung in einem Speicher entferne alle Ableitungen.

RAG Prompt Injection

Retrieval-Augmented Generation nimmt üblicherweise Dokumente auf, extrahiert und segmentiert deren Inhalt, erzeugt Darstellungen wie Embeddings, speichert sie in einem Index oder einer Vektordatenbank und ruft für spätere Anfragen passende Chunks ab. Diese Verarbeitung verbessert den Zugriff auf Fachwissen. Sie neutralisiert aber keine anweisungsähnliche Sprache. Ein Embedding bildet Inhalt für Retrieval ab. Es bescheinigt weder Vertrauen noch die Eignung des Inhalts als Steuerung.

Retrieval-Relevanz und Vertrauen beantworten unterschiedliche Fragen. Ein Chunk kann für eine Anfrage hochrelevant sein und zugleich von einem Angreifer stammen, veraltet, außerhalb der Berechtigungen des Nutzers oder als Anweisungsquelle ungeeignet sein. Der Retriever kann ihn korrekt auswählen, während das Modell seine Sprache fälschlich als Teil der Aufgabe und nicht als zu analysierenden Beleg behandelt.

Bei Ingestion-Time Poisoning gelangt angreiferkontrolliertes Material vor einer Opferanfrage in den Korpus oder verändert ihn. Die Exposition zur Anfragezeit entsteht, wenn das Retrieval dieses Material auswählt und dem Modell zuführt. Eine vollständige Prüfung betrachtet beide Phasen: Wer darf Quellen hinzufügen oder ändern? Bleibt die Herkunft bei Transformationen erhalten? Wie setzt Retrieval Nutzer- und Mandantenberechtigungen durch? Welche Kontrollen begrenzen Ausgabe und Aktion?

Autorisierung gehört vor den Aufbau des Kontexts. Security Trimming und ACL-bewusstes Retrieval müssen Berechtigungen auf Mandanten-, Dokument- und bei Bedarf Chunk-Ebene durchsetzen, bevor Material modellsichtbar wird. Chunking und Indexierung müssen Autorisierungsmetadaten und Quell-Lineage erhalten, damit ein abgeleiteter Chunk die Beschränkungen seines Ursprungs nicht verliert. Reranking und Relevanzwerte ordnen erlaubte Kandidaten, sind aber weder Autorisierung noch Vertrauensnachweis.

Gespeicherter Inhalt kann über Sitzungen hinweg bestehen und bei einem geteilten Korpus mehrere Nutzer betreffen. Der Umfang hängt von Dokumentberechtigungen, Retrieval-Filtern, Indexgrenzen, Cache-Verhalten und nachgelagerten Befugnissen ab. Das bedeutet nicht, dass jedes RAG-System grundsätzlich unsicher ist. Kuratierte Quellen, starke Zugriffskontrolle, provenienzbewusstes Retrieval, begrenzte Ausgaben und fehlende Aktionsrechte ergeben ein anderes Risikoprofil als offene Ingestion-Pipelines mit mächtigen Agents.

Bei der Eindämmung sind nicht nur die Quelle, sondern auch abgeleitete Chunks, gecachte Retrieval-Ergebnisse, Zusammenfassungen, Indexeinträge und Embeddings zu entfernen oder zu isolieren, sofern sie Erreichbarkeit oder Einfluss erhalten. Vor dem Neuaufbau aus vertrauenswürdigen Eingaben braucht die Untersuchung ausreichende Beweise und Provenienz dazu, welche Anfragen, Nutzer und Modellaufrufe diese Artefakte verarbeitet haben.

Warum AI Agents die Auswirkung erhöhen

Ein Assistent, der nur Text ausgibt, beeinflusst vor allem das, was ein Nutzer sieht. Ein Agent kann Ziele interpretieren, Tools auswählen, Parameter und Ziele bestimmen, weitere Daten abrufen, extern kommunizieren oder persistenten Zustand schreiben. Indirekte Injection kann deshalb nicht nur eine Antwort, sondern auch die nächsten Systemschritte verändern.

Externer Inhalt kann die Zielinterpretation verschieben, unnötiges Retrieval auslösen, ein folgenreicheres Tool auswählen, die Datenauswahl erweitern, einen Empfänger verändern, Aktionsparameter manipulieren oder Memory für spätere Aufgaben erzeugen. Ein modellgenerierter Plan kann schlüssig wirken und sich dennoch vom Zweck des Nutzers entfernen. Je mehr delegierte Befugnis und Autonomie ein Agent besitzt, desto wichtiger ist unabhängige Durchsetzung.

Das Modell darf eine Aktion vorschlagen. Es darf nicht entscheiden, dass sie autorisiert ist. Jede folgenreiche Operation muss an initiierende Identität, zulässige Ressource, erlaubte Aktion, validierte Parameter, freigegebenes Ziel und aktuelle Policy gebunden sein. So bleibt unvorhersehbares Modellverhalten ein begrenzter Vorschlag statt selbst verliehener Befugnis.

Multi-Agent Prompt Injection und Delegation

Jede Nachricht zwischen Agents ist eine Vertrauensgrenze. Ein koordinierender Agent kann abgerufenen Inhalt, eine Zusammenfassung, einen Plan oder ein Tool-Ergebnis an einen spezialisierten Agent mit anderem Privilegienumfang weitergeben. Über mehrere Hops kann der Inhalt seine Quellenkennzeichnung verlieren und wie eine vertrauenswürdige Anweisung einer Systemkomponente wirken. Multi-Agent-Koordination vergrößert damit die Zahl der Stellen, an denen nicht vertrauenswürdige Beobachtungen mit delegierter Autorität verwechselt werden können.

So kann Vertrauen ähnlich wie bei einem Confused Deputy fälschlich weitergereicht werden: Eine weniger privilegierte Komponente fordert eine höher privilegierte zum Handeln auf, und der Empfänger hält den Wortlaut des Senders für einen Beleg der Nutzerautorisierung. Dass ein anderer Agent eine Aussage erzeugt oder übermittelt hat, macht die zugrunde liegende Website, das Dokument, Tool-Ergebnis oder die modellgenerierte Behauptung nicht vertrauenswürdig.

Jeder Hop muss initiierende Identität, Quellprovenienz, Aufgabenabsicht und Autorisierungskontext als strukturierte Daten erhalten. Der empfangende Agent oder das Tool prüft Berechtigungen für die eigene Ressource und Aktion erneut, statt Autorität aus der Prosa eines anderen Agents zu übernehmen. Least Privilege, enge Delegation und Revalidierung an jedem Hop begrenzen die zusätzliche Komplexität, auf die auch aktuelle Microsoft-Leitlinien hinweisen.

Fähigkeiten, Autorisierung und Freigaben

Tool-Verfügbarkeit ist eine Schnittstellenentscheidung und keine Erlaubnis für eine konkrete Operation. Fähigkeiten sollten an aktuelle Aufgabe, Principal, Ressourcen, Aktionsklasse, Ziel und Zeitfenster gebunden sein. Das ist robuster als Umgebungs-Credentials, die über sachfremde Pläne hinweg nutzbar bleiben. Eine stabile Agentenidentität unterstützt Audit und Policy, kurzlebige oder Just-in-Time-Rechte begrenzen die Reichweite einer kompromittierten Interpretation.

Muster für menschliche Freigabe. Eine aussagekräftige Freigabe zeigt mindestens initiierenden Principal, Quelle, betroffene Ressource oder Daten, exakte Aktion, relevante Parameter, Ziel und erwartete Nebenwirkungen. Sie ist eine zusätzliche Kontrolle für ausgewählte folgenreiche oder außergewöhnliche Operationen und kein universeller Ersatz für klare Policies und geringe Privilegien.

Potenzielle Auswirkungen

Die folgenden Folgen hängen von Architektur, Berechtigungen, verfügbaren Daten und nachgelagerten Kontrollen ab. Sie sind mögliche Auswirkungen und keine garantierten Ergebnisse jeder manipulierten Ressource.

Plan Drift

Plan Drift ist eine Abweichung zwischen der initiierenden Aufgabe und den Schritten, die das Modell vorschlägt oder ausführt. Im Beispiel ist das Lesen des angeforderten Dokuments erwartbar. Der Zugriff auf eine fremde private Ressource und eine externe Aktion sind für die Zusammenfassung nicht notwendig. Diese zusätzlichen Schritte sind ein nützliches Signal dafür, dass externer Inhalt den Workflow umgelenkt haben könnte.

Drift ist kein deterministischer Angriffsnachweis. Komplexe Aufgaben können sich legitim entwickeln, und ein schädlicher Plan kann oberflächlich zum Nutzerziel passen. Die Erkennung sollte Ziele, Datenabhängigkeiten, ausgewählte Tools, Ziele und Nebenwirkungen vergleichen und diese Hinweise mit Provenienz und Autorisierungsentscheidungen verbinden.

Tool-Chain-Analyse

Tool-Chain-Analyse bewertet die Beziehung zwischen Aktionen, statt jeden Aufruf isoliert zu betrachten. Dateileser, Extraktor und E-Mail-Versand können jeweils erlaubte Tools sein. Ihre Abfolge kann dennoch vertrauliche Daten aus einer internen Vertrauensdomäne an ein externes Ziel übertragen. Die Kette muss mit Nutzeraufgabe, Principal, Ressourcenberechtigungen, erlaubten Zielen und vorherigen Autorisierungsentscheidungen korreliert werden.

Ein vertrauenswürdiges Tool macht seine Ausgabe nicht vertrauenswürdig. Ebenso macht ein freigegebenes Tool nicht jede Sequenz sicher. Parameter und Datenfluss sind an jeder Grenze zu validieren, einschließlich der Daten, die ein Tool an das Modell und ein späteres Tool weitergibt.

Informationsflusskontrolle

Kontrollen des Informationsflusses begrenzen, wie Daten zwischen Vertrauensdomänen bewegt werden dürfen. Nicht vertrauenswürdiger Website- oder Dokumentinhalt darf eine Zusammenfassung dieser Ressource beeinflussen. Er darf aber weder die Aufnahme vertraulicher Datensätze in die Antwort autorisieren noch interne Daten nach außen senden oder den Ressourcenbereich des aktuellen Principals erweitern.

Dieses Prinzip benötigt strukturierte Provenienz und Policy außerhalb des Modells. Quelle, Mandant, Klassifikation, Eigentümer, zulässiger Zweck und Zielbeschränkungen bleiben beim Retrieval und bei Tool Calls erhalten. Vor einer Nebenwirkung prüft die Anwendung, ob der vorgeschlagene Fluss von Quelldaten zum Ziel zulässig ist. Erklärung oder Konfidenz des Modells sind kein Autorisierungsnachweis.

Nützliche Kontrollen sind mandantenbewusstes Retrieval, feldbezogene Zugriffsprüfungen, Ziel-Allowlisten, Data Loss Prevention, Egress-Policy, begrenzte Credentials und die Trennung von Lese- und Schreibrechten. Sie verhindern nicht jeden Interpretationsfehler. Sie begrenzen, welche Fehler zu Offenlegungen oder unautorisierten Aktionen werden können.

Erkennung

Erkennung und Durchsetzung erfüllen unterschiedliche Aufgaben. Inhaltsprüfung, Klassifikatoren, modellbasierte Critics und Verhaltensanalyse sind probabilistisch. Sie können Prüfungen priorisieren, offensichtliche Fälle stoppen und Kontext liefern. Falschmeldungen und übersehene Angriffe bleiben möglich. Autorisierung, Ressourcenzugriff, Parameterprüfung und Egress-Beschränkungen sollten deterministisch sein, wo sich die Richtlinie deterministisch ausdrücken lässt.

Protokollierung und Telemetrie

Eine Untersuchung benötigt eine durchgehende Spur von der initiierenden Aufgabe über externe Inhalte, Retrieval, Modellentscheidungen, Policy-Prüfungen und Tools bis zu realen Nebenwirkungen.

Prompts, abgerufene Inhalte, E-Mails, Dokumente und Tool-Ergebnisse können selbst personenbezogene, vertrauliche oder regulierte Informationen enthalten. Es gelten Datenminimierung, Zugriffskontrolle, gegebenenfalls Schwärzung, begrenzte Aufbewahrung und sichere Löschung. Forensische Lineage soll erhalten bleiben, ohne ein unnötig breites zweites Archiv sensibler Inhalte zu schaffen.

Incident Response

Es genügt nicht, den beobachteten Wortlaut in eine Blockliste aufzunehmen. Zu klären ist, warum die Ressource einen sensiblen Kontext erreichte, weshalb ihre Provenienz fehlte oder nicht berücksichtigt wurde und welche nachgelagerte Kontrolle die Modellinterpretation an geschützte Daten oder Befugnisse gelangen ließ.

Prävention und Minderung

Das Systemdesign sollte davon ausgehen, dass einige indirekte Injections die Inhaltsprüfung umgehen. Mehrschichtige Abwehr verringert die Wahrscheinlichkeit einer Beeinflussung und begrenzt ihre Folgen.

1. 01
   Externe Inhalte prüfen und klassifizieren

   Parsing, Quellenanalyse, Datenkennzeichnung und probabilistische Detektoren als Prüfsignale statt vollständiger Schutzmaßnahme verwenden.

2. 02
   Provenienz erhalten

   Quellidentität, Vertrauen, Mandant, Berechtigungen, Ingestion-Verlauf und Retrieval-Lineage außerhalb des Modells weiterführen.

3. 03
   Nicht vertrauenswürdigen Inhalt trennen

   Klare Kontextgrenzen, enge Aufgaben, begrenzte Transformationen und Quarantänepfade einsetzen.

4. 04
   Modellsichtbare Geheimnisse minimieren

   Vertrauliche Daten, Credentials und breiten Kontext nur bereitstellen, wenn Aufgabe und Principal sie benötigen.

5. 05
   Least Privilege anwenden

   Agents erhalten begrenzte Tools, Datenrechte, kurzlebige Credentials und minimale Schreibbefugnis.

6. 06
   Jede Aktion autorisieren

   Principal, Ressource, Aktion, Mandant, Ziel und aktuelle Policy außerhalb des LLM durchsetzen.

7. 07
   Tools und Parameter validieren

   Erlaubte Operationen, typisierte Schnittstellen, Parametergrenzen, Zielprüfungen und Geschäftsregeln nutzen.

8. 08
   Netzwerk und Egress beschränken

   Erreichbare Dienste, externe Ziele, Protokolle und Datenbewegungen begrenzen.

9. 09
   Aussagekräftige Freigabe verlangen

   Bei folgenreichen oder ungewöhnlichen Aktionen Quelle, Daten, Ziel und Wirkung vor einer menschlichen Entscheidung zeigen.

10. 10
    Ausführung isolieren

    Je nach Fall Sandboxing, Quarantäne, Nur-Lese-Modi, Transaktionsgrenzen und Rollback einsetzen.

11. 11
    Pläne und Tool-Ketten überwachen

    Task Drift, riskante Aktionsfolgen, Ablehnungen und unerwartete Flüsse zwischen Vertrauensdomänen erkennen.

12. 12
    Adversarial testen

    Quelltypen, Persistenz, Retrieval, Tools, Autorisierung, Egress, Isolation und Telemetrie nach relevanten Änderungen prüfen.

Sichere Architektur

Der robustere Pfad nimmt nicht an, dass Prüfung oder Modell schädlichen Inhalt immer erkennen. Die Prüfung liefert Signale und Provenienz. Das LLM schlägt eine Interpretation oder einen Plan vor. Die Planvalidierung prüft den Bezug zur Nutzeraufgabe. Policy und Autorisierung bewerten Identität, Ressource, Aktion, Mandant, Parameter und Ziel. Für außergewöhnliche Aktionen mit hoher Auswirkung kann eine menschliche Freigabe zusätzlichen Kontext einbringen. Das Tool bleibt auf die notwendige Fähigkeit beschränkt.

Jede Schicht muss sicher fehlschlagen. Ein übersehener Klassifikatorfund darf keine Befugnis erzeugen. Ein überzeugender Plan darf Zugriffskontrollen nicht umgehen. Eine Freigabeansicht darf Ziel und betroffene Daten nicht verbergen. Ein Tool-Fehler darf keine umfassendere Ersatzberechtigung auslösen. Ziel ist die Begrenzung der Folgen und nicht die perfekte Vorhersage des Modellverhaltens.

Faktoren für den Schweregrad

Der Schweregrad ergibt sich aus nachgewiesener Erreichbarkeit und Auswirkung. Das Angriffsmuster erhält keinen pauschalen Zahlenwert.

Threat-Modeling-Checkliste

Indirekte Prompt Injection testen

Tests gehören in eine kontrollierte Umgebung mit synthetischen Inhalten, nicht produktiven Identitäten, begrenzten Tools und reversiblen Nebenwirkungen. Erwartete Policy-Ergebnisse werden vorab festgelegt, damit die Prüfung Sicherheitsgrenzen und nicht nur subjektive Antwortqualität misst.

Diese Dimensionen sollten nicht zu einem Gesamtwert verschmolzen werden. Ein System kann deutliche Modellbeeinflussung zeigen und trotzdem alle nicht autorisierten Nebenwirkungen eindämmen. Ebenso kann es viele Injections erkennen und bei übersehenen Fällen an der Autorisierung scheitern. Synthetische Daten, nicht produktive Systeme und vorab festgelegte Soll-Ergebnisse halten die Messung defensiv, reproduzierbar und sicher.

Eine bestandene Testsuite ist ein Nachweis für eine konkrete Konfiguration, aber kein Beweis, dass indirekte Prompt Injection beseitigt wurde. Beeinflusste, blockierte, erkannte, eingedämmte und erfolgreiche Pfade werden getrennt dokumentiert. Zu prüfen sind Modellverhalten und reale nachgelagerte Effekte.

Häufige Fehlannahmen

Direkte vs. indirekte Prompt Injection

Der Unterschied bezeichnet den Übertragungsweg und keine automatische Rangfolge des Schweregrads. Beide Varianten können harmloses Fehlverhalten oder materielle Systemauswirkungen verursachen. Der Weg über den primären Nutzer wird unter Direkte Prompt Injection erläutert.

Verwandte Angriffsklassen

Mehrere Klassen können im selben Vorfall zusammenkommen, sollten aber nicht gleichgesetzt werden. Die Begriffe bezeichnen unterschiedliche Platzierungsmechanismen, kompromittierte Grenzen oder Ziele. OWASP-Zuordnungen werden nur verwendet, wenn die geprüfte Quelle sie ausdrücklich trägt.

Forschung und Designrichtungen

Neuere Forschung untersucht Kontrollen, die eine fortbestehende Anfälligkeit des zugrunde liegenden Modells voraussetzen. Defeating Prompt Injections by Design von Debenedetti et al. beschreibt CaMeL als schützende Systemschicht. Kontroll- und Datenfluss werden ausgehend von der vertrauenswürdigen Anfrage getrennt, während fähigkeitsbasierte Kontrollen nicht autorisierte Datenflüsse verhindern sollen. Für das Design ist entscheidend, dass die Durchsetzung außerhalb der Fähigkeit des Modells liegt, konkurrierender Sprache zu folgen.

AttriGuard von He et al. untersucht kausale Attribution auf Aktionsebene für Agents mit Tools. Die Leitfrage lautet, ob ein vorgeschlagener Tool Call durch die Nutzerabsicht gestützt oder kausal von einer nicht vertrauenswürdigen Beobachtung ausgelöst wird. Dieser Ansatz ergänzt Autorisierung um Hinweise darauf, warum eine Aktion in den Plan gelangte. Er macht die Modellbewertung nicht selbst zur Berechtigung.

Overcoming the Retrieval Barrier von Chang et al. betont die End-to-End-Evaluation realistischer Systeme: Vergifteter Inhalt muss tatsächlich abgerufen werden, bevor er das Modell beeinflussen kann. Retrieval-Erreichbarkeit ist damit Teil der Erfolgskette und der defensiven Messung, keine vorauszusetzende Randbedingung. Diese Perspektive führt die an realen Anwendungen orientierte Arbeit von Greshake et al. fort, ohne einer einzelnen Technik vollständigen Schutz zuzuschreiben.

Standards und Klassifikationen

OWASP LLM01:2026 unterscheidet direkte und indirekte Injection, nennt externe Quellen wie Websites und Dateien als Übertragungswege und behandelt abgerufene Dokumente und Memory als einen einzigen nicht vertrauenswürdigen Token-Strom ohne erzwungene Vertrauensgrenze. MITRE ATLAS katalogisiert indirekte LLM-Prompt-Injection als AML.T0051.001.

NIST AI 100-2e2025 stellt Terminologie für adversariales maschinelles Lernen bereit. Das NIST-Glossar beschreibt indirekte Prompt Injection als Prompt Injection, die über die Kontrolle einer Ressource statt über nutzerbereitgestellte Eingaben ausgeführt wird. Weitere CWE-, CAPEC- oder Framework-Zuordnungen werden hier nicht vorgenommen.

Häufig gestellte Fragen