RAG Prompt Injection

Was ist RAG Prompt Injection?

RAG Prompt Injection ist indirekte Prompt Injection, die über Inhalte zugestellt wird, welche eine Retrieval-Augmented-Generation-Pipeline in den Modellkontext abruft. Angreifer kontrollieren oder beeinflussen eine Quelle, bevor eine betroffene Person eine legitime Frage stellt. Ein Connector nimmt die Quelle auf, das Retrieval wählt Teile daraus aus, und der Kontextaufbau platziert dieses Material neben Anwendungsanweisungen und Nutzeraufgabe. Direkter Zugriff auf die betroffene AI-Anwendung ist nicht nötig.

RAG kann Antworten besser fundieren und ihre Relevanz erhöhen, bildet aber keine Sicherheitsgrenze. Parsing, Chunking, Embeddings und Retrieval neutralisieren die semantische Wirkung anweisungsartiger Sprache nicht. Microsofts aktuelle Leitlinie zur Retrieval-Hygiene behandelt Prompts, Dokumente, abgerufene Chunks, Tool-Ergebnisse und Schreibvorgänge ins Memory als nicht vertrauenswürdige Eingaben. Ein vertrauenswürdiger Retriever kann nicht vertrauenswürdige Inhalte liefern, genau wie ein vertrauenswürdiger Browser eine nicht vertrauenswürdige Seite abrufen kann. Quellenvertrauen, Anweisungsautorität, Datenvertraulichkeit und Aktionsautorisierung bleiben getrennte Entscheidungen.

Modellbeeinflussung ist nicht automatisch eine Schwachstelle. Ändert abgerufener Text Formulierung, Gewichtung oder vorgeschlagenen Plan, ist Beeinflussung eingetreten. Eine Sicherheitsauswirkung erfordert zusätzlich einen Daten- oder Fähigkeitspfad und eine fehlende, zu weit gefasste oder versagende Anwendungskontrolle. Ein belastbares Design nimmt mögliche Beeinflussung an und verhindert, dass abgerufener Inhalt sich selbst Zugriff, Befugnis oder eine externe Nebenwirkung verleiht. Die zugrunde liegende Architektur und warum Relevanz kein Vertrauen ist, erklärt RAG und Retrieval.

RAG Prompt Injection und Wissensvergiftung

RAG Prompt Injection, Wissensvergiftung und Schwächen von Vektorsystemen können gemeinsam auftreten, bezeichnen aber unterschiedliche Mechanismen. Wer sie als Synonyme verwendet, verdeckt die versagte Grenze und die passende Kontrolle.

Ein einzelnes Artefakt kann alle drei Klassen verbinden. Ein Beitrag kann falsche Aussagen und anweisungsartigen Text enthalten, während fehlerhafte Metadaten ihm zugleich zu große Reichweite geben. Der Vorfall braucht trotzdem getrennte Befunde zu Korpusintegrität, Prompt-Beeinflussung und Zugriffskontrolle. PoisonedRAG wird hier als Forschung zur Wissenskorruption eingeordnet, nicht automatisch als Prompt Injection.

Das Lab zur manipulierten Wissensbasis trennt Korpusintegrität von Prompt Injection: eine kontrollierte Simulation, in der falsches oder ungeprüftes Wissen keinen anweisungsartigen Text braucht und Herkunft, maßgebliche Quelle und Freigabestatus bestimmen, worauf sich eine Antwort stützen darf.

RAG-Pipeline und Vertrauensgrenzen von Ende zu Ende

Jede Komponente kann vertrauenswürdige Systeminfrastruktur sein, während der transportierte Quellinhalt nicht vertrauenswürdig bleibt. Der Connector kann korrekt authentifizieren, der Parser exakt wie vorgesehen arbeiten und der Index mathematisch relevante Treffer liefern, ohne einem Satz Anweisungsautorität zu geben. Vertrauen in Infrastruktur überträgt sich nicht auf ihre Ausgabe.

Vertrauens- und Autorisierungsmetadaten müssen jede Transformation überstehen. Quelle, Beitragende, Mandant, Dokumentversion, Zugriffslabel und Chunk-Herkunft dürfen nicht verschwinden, wenn Text zu Tokens oder Vektoren wird. Security Trimming erfolgt vor dem Aufbau des modellsichtbaren Kontexts. Das Ranking ordnet danach nur Kandidaten, die für das auslösende Principal bereits zulässig sind. Nach der Generierung bleibt die Antwort ein Vorschlag, bis die Anwendung Offenlegung, weiteres Retrieval, Schreiben, Tool Call oder Ziel autorisiert.

Erfolgskette der RAG Prompt Injection

Aus offensiver Sicht ist jede Stufe ein eigenes Problem. Prüfende müssen eine beeinflussbare Quelle bestimmen, den Eintritt ihres Inhalts in den Korpus belegen und untersuchen, ob er Parsing, Chunking und Indexierung übersteht und für realistische Anfragen betroffener Personen konkurrenzfähig bleibt. Selbst dann muss das Element in die Kandidatenmenge gelangen, legitime Autorisierung passieren, Reranking und Kontextlimits überstehen, modellsichtbar werden, Verhalten beeinflussen, einen Daten- oder Fähigkeitspfad erreichen, eine Anwendungskontrolle überwinden und die beabsichtigte Auswirkung erzeugen.

Eine vollständige Ende-zu-Ende-Sicherheitsauswirkung erfordert jede Stufe. Drei zentrale Erfolgsbedingungen bleiben getrennt: erstens Platzierung und Erreichbarkeit im Korpus, zweitens Retrieval-Erreichbarkeit unter realistischen Anfragen und drittens Modell- oder Aktionsbeeinflussung nach dem Abruf. Erfolg an einer frühen Schranke belegt keine Ausnutzbarkeit einer späteren. Korpuspräsenz beweist kein Retrieval, Retrieval keine Beeinflussung, Beeinflussung keinen Policy Bypass und ein Policy Bypass allein noch keine sicherheitsrelevante Nebenwirkung.

Kontrollen können die Kette an mehreren Stellen brechen: Schreibende und Connectoren begrenzen, Autorisierung bei der Indexierung erhalten, Kandidaten berechtigungsbewusst filtern, Kontext minimieren, verdächtige Beeinflussung erkennen, Fähigkeiten beschränken, Ziele validieren und unzulässige Auswirkungen ablehnen. Modellbeeinflussung bleibt von Sicherheitsauswirkung getrennt. Eine beeinflusste Antwort oder ein Vorschlag verlangt Untersuchung, wird aber erst dann zur Ende-zu-Ende-Schwachstelle, wenn das umgebende System das Überschreiten einer geschützten Grenze erlaubt.

Exposition bei Ingestion und zur Anfragezeit

Ein vergiftetes Dokument im Korpus ist noch keine erfolgreiche Prompt Injection. Es muss für eine Anfrage erreichbar sein, Autorisierung passieren, ausgewählt und modellsichtbar werden und Verhalten beeinflussen. Sicherheitsteams brauchen Evidenz aus Ingestion und Anfragezeit, weil die Reparatur nur einer Phase den anderen Pfad unerklärt lässt.

Was tatsächlich für das Modell sichtbar wird

In gewöhnlichen RAG-Architekturen "führt" das LLM ein Embedding im Allgemeinen nicht "aus". Embeddings oder andere Vektorrepräsentationen beeinflussen Kandidatenauswahl und Ranking, während das Modell normalerweise ausgewählten Text oder eine andere rekonstruierte oder gerenderte Darstellung erhält. Umsetzungen unterscheiden sich: Multimodalsysteme, gelernte Retriever und anbieterspezifische Kontextformate können andere Repräsentationen zeigen. Untersuchungen müssen deshalb den konkreten Laufzeitpfad feststellen, statt ein einheitliches Design anzunehmen.

Die Transformation eines Inhalts in ein Embedding bereinigt keine semantischen Anweisungen in Material, das später für das Modell dargestellt wird. Wählt Retrieval eine Quelle aus und rekonstruiert der Kontextaufbau ihren Text, ihre Zusammenfassung, Tabelle, OCR-Ausgabe oder benachbarte Passage, kann anweisungsartige Bedeutung modellsichtbar bleiben, obwohl Vektoroperationen bei der Auswahl geholfen haben.

Die Retrieval-Barriere: Erreichbarkeit vor Beeinflussung

Gespeicherter Inhalt wird für eine konkrete Anfrage erst relevant, wenn Retrieval ihn auswählt. Erreichbarkeit ist deshalb eine eigene Stufe der Erfolgskette: Vorhandensein im Korpus, Zulässigkeit für die Anfrage, Kandidatenauswahl, Ranking, Kontextaufnahme und Modellbeeinflussung sind nicht dasselbe Ereignis. Die Arbeit Overcoming the Retrieval Barrier für USENIX Security 2026 untersucht diese Ende-zu-Ende-Unterscheidung in realitätsnahen LLM-Systemen.

Defensive Tests dürfen einen synthetischen Chunk nicht zwangsweise in den Kontext einsetzen und das Ergebnis anschließend als praktische RAG-Kompromittierung melden. Dieses Experiment misst Beeinflussung nach Retrieval. Es misst nicht, ob normale Anfragen das Artefakt abrufen. Deshalb werden Retrieval Hit Rate, Beeinflussung unter der Bedingung des Abrufs und die Ende-zu-Ende-Kombination getrennt berichtet.

Techniken zur Optimierung von Retrieval-Triggern werden bewusst nicht wiedergegeben. Die Seite erläutert die Barriere, ihre offensive Bedeutung und ihre Messbarkeit sowohl für die autorisierte Prüfung als auch für die Abwehr, während Implementierungsdetails auf Optimierungsebene in der zitierten Forschung verbleiben.

Offensive Perspektive: Retrieval gewinnen

Für eine autorisierte offensive Prüfung genügt die Platzierung allein nicht. Ein angreiferbeeinflusstes Element konkurriert mit legitimen Korpusmaterial um die Anfragen, die Menschen tatsächlich stellen. Sein Pfad hängt von Embedding-Ähnlichkeit, Korpusdichte, Chunk-Grenzen und weiteren Transformationen, Query Rewrite, Kandidatenzahl, Metadatenfiltern, Security Trimming, Reranking, Kontextfenstergrenzen und jeder späteren Kontextauswahl ab. Die Prüfung fragt daher nicht nur, ob Inhalt gespeichert werden kann, sondern ob er jede unabhängige Schranke unter realistischer Identität, Aufgabe und Anfrageverteilung durchläuft.

Ein hochrelevantes Element kann an der Autorisierung scheitern. Ein autorisiertes Element kann die Kandidatenmenge oder den ausgewählten Kontext verfehlen. Ein abgerufenes Element kann ohne Modellbeeinflussung bleiben, und ein beeinflusster Vorschlag kann weiterhin durch Anwendungspolicy eingedämmt werden. Das sind getrennte Ausnutzbarkeitsschranken: vergifteter Inhalt existiert ≠ abgerufen ≠ Modell beeinflusst ≠ Policy umgangen ≠ Sicherheitsauswirkung.

Offensive Review-Fragen

Dieser Red-Team-Rahmen trennt die Evidenz für jede Schranke, ohne eine Anleitung zur Ausnutzung vorzugeben. Assessments verwenden autorisierte Identitäten, synthetische geschützte Daten und begrenzte Fähigkeiten und halten fest, was möglich war und was eingedämmt wurde.

Retrieval-Relevanz ist kein Vertrauen

Wiederholter Abruf kann die Salienz im Modell erhöhen, aber nie die Autorität. Ein Zitat kann genau auf eine bösartige, veraltete oder unzulässige Quelle zeigen. Diese Dimensionen gehören in getrennte Felder und Entscheidungen, nicht in einen vermischten Vertrauenswert.

Das Lab zu Retrieval-Relevanz und Vertrauen übt, Retrieval-Belege von Quellautorität und Sicherheitsbelegen zu trennen: eine kontrollierte Simulation, in der Rang, Ähnlichkeit und Zitate Kandidaten ordnen, während Herkunft, Versionsstatus, Zugriff und zweckbezogene Regeln zur maßgeblichen Quelle bestimmen, worauf sich eine Antwort stützen darf.

Provenienz durch Parsing, Chunking, Embeddings und Indizes

Eine belastbare Herkunftslinie beginnt mit stabilen Quell-, Dokument- und Versionskennungen, URI oder Repository-Ort, Ingestion-Principal und Connector, Mandant und Eigentümer, autoritativem ACL oder Sicherheitslabel sowie Zeitpunkt der Aufnahme. Abgeleitete Datensätze ergänzen Parser- und Transformationsversion, Chunk-ID und Quellpositionen, Embedding-Modell und Indexgeneration, Collection oder Namespace sowie die Herkunft von Zusammenfassungen, Caches, Index- und Embedding-Artefakten, zusammengeführten Passagen und synthetischen Chunks. Auch Microsofts Leitlinie zur Retrieval-Hygiene stellt Quellenprovenienz, berechtigungsbewusste Indexierung und Validierung bei jedem Lese- und Schreibvorgang in den Mittelpunkt sicheren Retrievals.

Autoritative Metadaten bleiben außerhalb angreiferveränderlicher Textfelder. Ein Satz im Dokument, der es als öffentlich, freigegeben oder einem anderen Mandanten zugehörig bezeichnet, ist Inhalt und keine Policy. Abgeleitete Chunks erben Richtlinienmetadaten aus einer autoritativen Kontrollebene. Widersprüche werden gemäß Anwendungsrichtlinie geschlossen behandelt, nicht vom Modell aufgelöst.

Chunking erzeugt ein subtiles semantisches Risiko. Eine Trennung kann einen Absatz von Überschrift, Warnhinweis, Quellenidentität oder Zugriffslabel lösen. Überlappung kann einen anweisungsartigen Abschnitt wiederholen und seine Salienz erhöhen. Zusammenfassung kann externe Sprache als scheinbar interne Schlussfolgerung umformulieren. Embeddings und Reindexierung transformieren die Darstellung, bereinigen aber keine semantischen Anweisungen. Jedes abgeleitete Artefakt braucht daher einen Weg zurück zum ursprünglichen Abschnitt und zur exakten Transformationskette.

Autorisierung und Security Trimming

Autorisierung gehört vor den Eintritt geschützter Inhalte in den Modellkontext. Filterung nach der Generierung ist zu spät für Daten, die das Modell nie hätte sehen dürfen, und kann Offenlegung in Antworten, Logs, Caches oder späterer Planung nicht zuverlässig rückgängig machen. Kontrollziel ist die Durchsetzung von auslösendem Principal, Mandant und aktuellen Ressourcenrechten bei Kandidatenzulassung und Kontextaufbau.

Der Reranker ist Verarbeitungsinfrastruktur und keine vertrauenswürdige Quelle für Inhalt oder Autorität. Er ordnet Kandidaten, die bereits autorisiert sein müssen, und kann zuvor zugelassene unzulässige Kandidaten nicht reparieren.

Widerruf muss Indizes, Caches und abgeleitete Chunks erreichen, nicht nur das Quellsystem. Mandantenübergreifendes Retrieval ist strukturell zu verhindern. Eine vom Modell erzeugte Folgeanfrage schafft keine Berechtigung, und jede Retrieval-Runde verwendet aktuelle Identität und Policy erneut. Produkte können dieses Ziel unterschiedlich umsetzen, aber keines darf die Entscheidung semantischer Relevanz überlassen.

Mandantenübergreifende und nutzerübergreifende Exposition

Das robustere Design überträgt Nutzer- und Mandantenidentität sowie aktuelle Autorisierung in jede Retrieval-Runde, einschließlich Query Rewrite und modellangeforderter Folgeabfragen. Wo praktikabel, sind Retrieval- und Service-Zugangsdaten begrenzt, kurzlebig und aufgabenbezogen statt dauerhaft und allgegenwärtig. Die Kandidatenzulassung richtet sich nach dem auslösenden Principal und nicht nur danach, was ein gemeinsames Servicekonto lesen kann.

Cache-Schlüssel, Indexpartitionen, Namespaces und Labels abgeleiteter Artefakte erhalten Mandanten- und Autorisierungsumfang. Geteilte Infrastruktur kann effizient und sicher sein, aber geteilter Speicher oder Compute darf nie geteilte Autorisierung bedeuten. Berechtigungsänderungen müssen jedes betroffene Derivat invalidieren oder neu aufbauen, bevor es wieder modellsichtbar werden kann.

Korpusprivatsphäre und Mandantenisolation beantworten, wer welche Daten abrufen darf. Prompt-Injection-Robustheit beantwortet, wie das System mit anweisungsartigen Inhalten nach einem autorisierten Abruf umgeht. Auch ein privater Korpus kann angreiferbeeinflusstes Material enthalten, während starke Injection-Kontrollen keinen mandantenübergreifenden Zugriff ausgleichen. Beide Eigenschaften werden getrennt getestet und berichtet.

Chunking, Kontextaufbau und abgeleitete Artefakte

Kontextaufbau ist eine sicherheitsrelevante Transformation, keine Formatierung. Chunk-Grenzen entscheiden, welche Einschränkungen erhalten bleiben. Überlappung und Deduplizierung entscheiden, was sich wiederholt. Kanonisierung entscheidet, welches Duplikat maßgeblich wird. Reihenfolge bestimmt Salienz. Zitatzuordnung entscheidet, ob Nutzende eine Aussage auf den genauen Quellabschnitt zurückführen können.

Bei der Ingestion erzeugte Zusammenfassungen, gecachte Retrieval-Ergebnisse, gespeicherte Antwortzusammenfassungen und Agent Memory sind Artefakte zweiter Ordnung. Sie können Beeinflussung nach Entfernung der Originalquelle bewahren, oft mit schwächerer Provenienz, weil ihr Text systemerzeugt erscheint. Das Löschen eines Dokuments entfernt nicht zwingend Chunks, Vektoren, Cache-Einträge, Zusammenfassungen oder kopiertes Memory. Jede Schicht braucht ausdrückliche Invalidierung und herkunftsbewusste Bereinigung.

Zitate verbessern Nachvollziehbarkeit, begründen aber kein Vertrauen. Ein Zitat kann korrekt auf eine bösartige, veraltete oder nicht autorisierte Quelle zeigen. Die Anwendung erhält die Quellenzuordnung für Untersuchungen und trifft Integritäts-, Zugriffs- und Autoritätsentscheidungen weiterhin getrennt.

Besonders exponierte RAG-Architekturen

Keine dieser Architekturen ist von sich aus verwundbar. Exposition ergibt sich aus Quellenkontrolle, Erreichbarkeit, modellsichtbaren Daten und verfügbaren Fähigkeiten abzüglich der deterministischen Kontrollen, die sie trennen.

Beispiel: geteilter Wissensassistent

Die Beeinflussung bleibt im Antwortvorschlag sichtbar, daher muss die Quelle untersucht und eingedämmt werden. Die Sicherheitsauswirkung ist dennoch begrenzt: Geschützte Inhalte außerhalb der Berechtigung der Person gelangten nie in den Modellkontext, und die sachfremde Aktion wurde nicht ausgeführt. Ohne Retrieval-ACLs hätten geschützte Inhalte in der Antwort offengelegt werden können; ohne Aktionskontrollen hätte dieselbe Beeinflussung eine externe Nebenwirkung erreicht.

Persistente und gespeicherte RAG Injection

RAG macht aus einer Quelle eine Familie von Artefakten: geparste Darstellung, Chunks, Embeddings, Indexeinträge, Caches, Zusammenfassungen und mitunter Memory für spätere Sitzungen. Prompt-Injection-Einfluss kann deshalb nach der ersten Anfrage fortbestehen und Personen erreichen, die die Originalquelle nie gesehen haben.

Quellentfernung, Indexneuaufbau, Cache-Löschung, Bereinigung von Zusammenfassungen und Memory sind verschiedene Vorgänge. Nur das Originaldokument zu löschen, kann abgeleitete Chunks in einer älteren Indexgeneration oder eine Modellausgabe im Cache zurücklassen. Ein sauberer Neuaufbau beginnt mit bekannt sauberen Quellen und geprüften Autorisierungsmetadaten, während forensische Kopien und Herkunftslinien erhalten bleiben.

Geteilte Korpora vergrößern die Reichweite, Mandantengrenzen sollten sie begrenzen. Untersuchungen müssen alle Personen, Mandanten und Anfragen bestimmen, die ein betroffenes Artefakt erhielten, einschließlich Zusammenfassungen zweiter Ordnung, welche die Beeinflussung nach Quarantäne der Quelle weitertrugen.

Agentisches RAG und Folgeaktionen

Bei agentischem RAG kann abgerufener Inhalt mehr als Antworttext beeinflussen: Planung, Tool-Wahl, Query Expansion, Folge-Retrieval, Schreibvorgänge und externe Kommunikation. Das schafft zusätzliche Richtlinienprüfungen, aber keine zusätzliche Autorität für das Modell.

Erkennung und Telemetrie

Logs können sensible Anfragen und abgerufene Texte enthalten. Erfassung braucht Zweckbindung, Zugriffskontrollen, Aufbewahrungsgrenzen und Schwärzung, wo Rekonstruktion keinen Rohinhalt verlangt. Telemetrie kann einen Quellabschnitt mit einem veränderten Vorschlag korrelieren, aber interne Modellkausalität meist nicht beweisen. Inhaltsdetektoren bleiben probabilistische Signale; Autorisierungs- und Ausführungsdaten belegen, was eine Grenze überschritten hat.

Prävention und sichere Architektur

1. 01
   Ingestion kontrollieren

   Schreibende und Connectoren authentifizieren, Schreibumfang begrenzen, Quellbesitz erhalten und einen Quarantänepfad für verdächtiges Material anbieten.

2. 02
   Metadaten schützen

   Provenienz, Mandant und ACL in einer autoritativen Ebene speichern, die Quellenautoren nicht über Dokumenttext umschreiben können.

3. 03
   Prüfen, ohne Autorität zu verleihen

   Inhaltsprüfung und Labels probabilistisch für Routing und Review nutzen, nie als Berechtigung.

4. 04
   Berechtigungsbewusst indexieren

   Ressourcenrechte in jeden Chunk und Datensatz tragen, Mandanten isolieren und fehlende Sicherheitsmetadaten gemäß Policy geschlossen behandeln.

5. 05
   Vor dem Kontext autorisieren

   Kandidaten für das aktuelle Principal filtern, bevor das Modell sie sieht, auch bei umgeschriebenen Anfragen und Folge-Retrieval.

6. 06
   Provenienz erhalten

   Quell- und Transformationslinie durch Chunks, Zusammenfassungen, Caches, Indizes, Embeddings, Kontextaufbau, Zitate und Memory bewahren.

7. 07
   Jeden Lese- und Schreibvorgang validieren

   Aktuelle Identität, Berechtigung und Integrität immer dann prüfen, wenn Retrieval Kontext liest oder ein Workflow abgeleiteten Zustand schreibt.

8. 08
   Daten und Fähigkeiten minimieren

   Nur aufgabennötigen Kontext zeigen und Agents minimale, kurzlebige, aufgabenbezogene Tools geben.

9. 09
   Aktionen und Ziele validieren

   Daten, Ressource, Aktion, Parameter und Ziel außerhalb des Modells autorisieren, Egress beschränken und Plan Drift überwachen.

10. 10
    Widerruf und Wiederherstellung entwerfen

    Berechtigungsänderungen, Quarantäne, Cache-Invalidierung und Reindexierung in einen bekannten, testbaren Zustand führen.

Menschliche Freigabe eignet sich für ausgewählte folgenreiche Aktionen, nicht als universeller Ersatz für Richtlinien. Sie bindet exakten Vorgang, Daten, Ziel und Nebenwirkungen und wird bei jeder Änderung ungültig. Der Abwehr-Hub ordnet diese Kontrollen in ein breiteres Defense-in-Depth-Modell ein.

Incident Response bei RAG Prompt Injection

Kontrollierte defensive Tests

Verwendet werden ein synthetischer, isolierter Korpus, ein Testindex und Testidentitäten. Erwartete Abrufe, Ablehnungen und Aktionsergebnisse stehen vor jedem Lauf fest. Variiert werden Quelltyp und Vertrauen in Schreibende, Ingestion-Pfad, Chunk-Strategie und Position, Indexversion, semantisches gegenüber hybridem Retrieval, sofern unterstützt, Top-k und Reranking, ACL- und Mandantengrenzen, Query Rewrite, Cache-Zustand und verfügbare Tools. Retrieval-Trigger werden weder optimiert noch veröffentlicht. Das Lab RAG Prompt Injection ist eine kontrollierte Simulation des RAG-Vertrauens- und Autorisierungspfads - autorisiertes Retrieval, Security Trimming, Chunk-Herkunft, Aufgabenumfang und Aktions-Policy - und keine Exploit-Anleitung.

Einen Test-Chunk zwangsweise in den Kontext einzusetzen, misst Beeinflussung und keine Ende-zu-Ende-RAG-Exposition. Hohe Beeinflussung bei niedriger Unauthorized Action Rate bedeutet, dass Autorisierung Auswirkungen eindämmt, aber die Exposition von Modellintegrität und Workflow weiterhin sinken muss. Jede Metrik bleibt separat, damit Retrieval-Qualität keine Zugriffsfehler und gute Erkennung keine schwache Autorisierung verdeckt.

Häufige Implementierungsfehler

Standards und Forschungskontext

OWASP LLM01:2026 behandelt abgerufene Dokumente, Tool-Ergebnisse und Memory als einen einzigen nicht vertrauenswürdigen Token-Strom ohne erzwungene Vertrauensgrenze und beschreibt RAG-Corpus-Vergiftung als Ausbreitungspfad statt als Minderung. OWASP LLM09:2026 behandelt die breitere Klasse von Vektor- und Embedding-Schwächen einschließlich unbefugtem Zugriff, Datenlecks und Retrieval-Manipulation. Sie ist verwandt, aber nicht identisch mit Prompt Injection. NIST AI 100-2e2025 und das NIST-Glossar definieren indirekte Prompt Injection über die Kontrolle einer Ressource statt über die primäre Nutzereingabe.

Microsofts Leitlinien zu indirekter Prompt Injection und Least Privilege stützen mehrschichtige Kontrollen, begrenzte Agentenbefugnisse und die Validierung folgenreicher Vorgänge außerhalb des Modells. Die Leitlinie Input, Context, and Retrieval Hygiene behandelt ausdrücklich Prompts, Dokumente, abgerufene Chunks, Tool-Ergebnisse und Schreibvorgänge ins Memory als nicht vertrauenswürdige Eingaben. Sie verlangt Quellenprovenienz, berechtigungsbewusste Indexierung und Validierung bei jedem Lese- und Schreibvorgang. Greshake et al. begründeten das breitere Problem indirekter Injection in realen Anwendungen. PoisonedRAG untersucht Wissenskorruption und wird hier entsprechend bezeichnet. Chang et al. zeigen in Overcoming the Retrieval Barrier, warum realistische offensive Analysen Retrieval unter Nutzeranfragen als eigene messbare Ende-zu-Ende-Stufe behandeln müssen. Dieser Artikel berichtet ihre Ergebnisse mit den Grenzen der getesteten Konfigurationen und gibt weder Angriffskonstruktion, Token-Optimierung, Trigger-Erzeugung, Code noch Payload-Texte wieder.

CaMeL und AttriGuard sind für die nachgelagerte Grenze relevant: Sie untersuchen architektonische Trennung von Kontroll- und Datenfluss sowie die Attribution von Tool Calls zu vertrauenswürdiger Absicht. Sie machen Retrieval nicht zur Autorisierung, und kein Forschungsergebnis wird hier als universelle Präventionsgarantie dargestellt.

Häufige Fragen