Kann Ihre RAG-Pipeline zum Vektor für Datenexfiltration werden? Das Risiko, das Sicherheitsteams übersehen

Retrieval Augmented Generation (RAG) ist die Architektur, die Unternehmens-KI wirklich nutzbar macht: Anstatt sich ausschließlich auf Trainingsdaten zu verlassen, ruft die KI relevante Dokumente aus den eigenen Repositorys des Unternehmens ab und nutzt diese, um ihre Antworten zu untermauern.

Der geschäftliche Nutzen ist real – RAG-Pipelines machen KI-Assistenten präziser, aktueller und deutlich wertvoller für wissensintensive Aufgaben. Auch das Sicherheitsargument ist berechtigt, doch die meisten RAG-Implementierungen erfüllen es nicht. Im Kern ist eine RAG-Pipeline ein Hochdurchsatz-Dokumentenabrufsystem, das mit einer KI verbunden ist, die die Ergebnisse zusammenfasst, synthetisiert und präsentiert. Ohne Zugriffssteuerung pro Anfrage, Durchsetzung von Sensitivitätskennzeichnungen und Echtzeit-Monitoring entspricht dies auch einer exakten Beschreibung eines Tools zum unerwünschten Datenabfluss. Dieser Beitrag richtet sich an CISOs und Compliance-Beauftragte, die verstehen müssen, wie RAG-Pipelines zu Exfiltrationsvektoren werden – und welche Sicherheitsarchitektur dies verhindert.

Executive Summary

Kernaussage: Eine RAG-Pipeline, die Dokumente ausschließlich nach Relevanz abruft – ohne Zugriffskontrolle pro Anwender, ohne Prüfung von Sensitivitätskennzeichnungen und ohne Echtzeit-Monitoring – ist ein Datenabflussvektor innerhalb Ihres Sicherheitsperimeters. Die natürliche Sprachschnittstelle erleichtert die systematische Datenextraktion stärker als jedes herkömmliche Angriffswerkzeug. Die fünf Wege, wie RAG-Pipelines Exfiltration ermöglichen, sind alle vermeidbar; keiner wird durch die Standardkonfiguration eines RAG-Frameworks verhindert.

Warum Sie das interessieren sollte: RAG-Pipelines werden als Produktivitätswerkzeuge eingeführt und genehmigt, nicht als Systeme für den Datenzugriff. Ihre Sicherheitsüberprüfung – sofern sie überhaupt stattfindet – konzentriert sich auf die KI-Ebene: das Modell, das Prompt-Design, die Output-Filterung. Die Retrieval-Ebene – also die Komponente, die tatsächlich sensible Daten im großen Umfang verarbeitet – erhält häufig keine Sicherheitsüberprüfung, wie sie ein neues Dateizugriffssystem erhalten würde. Genau in dieser Lücke liegt das Exfiltrationsrisiko.

5 Wichtige Erkenntnisse

1. Die Retrieval-Komponente einer RAG-Pipeline ist ein Hochdurchsatzsystem für den Datenzugriff. Sie muss denselben Zugriffskontrollen, der Durchsetzung von Datenklassifizierung und den Anforderungen an Audit-Logging unterliegen wie jedes andere System, das sensible Unternehmensdaten im großen Umfang verarbeitet – was in den meisten Unternehmen nicht der Fall ist.
2. Übermäßige Berechtigungen beim Retrieval sind die strukturelle Schwachstelle, die die meisten RAG-Exfiltrationsszenarien ermöglicht. Läuft die Retrieval-Komponente unter einem Service-Account mit weitreichendem Repository-Zugriff und ohne nutzerbezogene Autorisierung auf der Retrieval-Ebene, hat jede Nutzeranfrage faktisch Zugriff auf den gesamten Datenbestand – einschließlich Dokumenten, auf die der Nutzer sonst keinen Zugriff hätte.
3. Indirekte Prompt Injection über abgerufene Inhalte ist der RAG-spezifische Angriffsvektor, der Sicherheitsteams am häufigsten überrascht. Ein Angreifer benötigt keinen Zugriff auf das KI-System – es reicht, ein bösartiges Dokument in ein vom RAG-System indiziertes Repository einzuschleusen. Wird dieses Dokument im Rahmen einer legitimen Anfrage abgerufen, werden die eingebetteten Anweisungen im Kontext der KI ausgeführt.
4. Bulk-Enumeration-Angriffe auf RAG-Pipelines sind mit rein abfragebasiertem Monitoring schwer zu erkennen, da jede einzelne Anfrage legitim wirkt. Die Erkennung erfordert nutzerbezogene Retrieval-Volumen-Baselines, Analyse über mehrere Sitzungen hinweg und Echtzeit-Integration mit SIEM, um systematische Muster im gesamten Anfrageverlauf zu identifizieren.
5. Prävention und Erkennung sind beide notwendig. Präventionsmaßnahmen – RBAC und ABAC pro Anfrage, Durchsetzung von Sensitivitätskennzeichnungen, Ratenbegrenzung – begrenzen das Schadensausmaß. Erkennungsmaßnahmen – Echtzeit-SIEM-Integration, Retrieval-Volumen-Alarmierung, Analyse von Anfrage-Mustern – erfassen Exfiltrationsversuche, die Präventionsmaßnahmen nicht vollständig verhindern. Keine der Maßnahmen ist allein ausreichend.

Was RAG tatsächlich mit Ihren Daten macht – und warum Sicherheitsteams es übersehen

Retrieval Augmented Generation funktioniert, indem ein Dokumentenkorpus in einer Vektordatenbank indexiert wird, die Anfrage in ein Vektor-Embedding umgewandelt wird, die semantisch ähnlichsten Dokumente im Index gefunden und zusammen mit der Anfrage in das Kontextfenster der KI übergeben werden. Die KI erstellt daraufhin eine Antwort, die auf den abgerufenen Inhalten basiert. Aus Anwendersicht wirkt dies wie ein intelligenter Assistent, der die Dokumente Ihres Unternehmens kennt.

Aus Sicht des Datenzugriffs passiert Folgendes: Die Nutzeranfrage wird in ein Retrieval-Muster umgewandelt, dieses Muster wird mit einer indexierten Version Ihres Dokumentenkorpus abgeglichen und die relevantesten Dokumente werden extrahiert und an ein generatives Modell übergeben, das deren Inhalte zusammenfasst und zurückgibt. Jeder Schritt dieser Pipeline berührt sensible Daten. Der Vektorindex enthält eine semantische Repräsentation jedes indexierten Dokuments. Der Retrieval-Schritt greift auf Dokumenteninhalte zu und überträgt diese. Das Kontextfenster der KI hält diese Inhalte während der Antwortgenerierung vor. Die Antwort selbst kann Inhalte von Dokumenten widerspiegeln, auf die der Nutzer eigentlich keinen Zugriff hat.

Sicherheitsteams, die nur die KI-Ebene – Modell, Antwortfilterung, Prompt-Design – prüfen und die Retrieval-Ebene als Infrastruktur betrachten, prüfen die weniger gefährliche Hälfte des Systems. Die Retrieval-Ebene entscheidet, ob Daten-Governance existiert oder nicht. Eine KI, die sich weigert, sensible Informationen auszugeben, kann keine Daten schützen, die bereits abgerufen und in ihr Kontextfenster geladen wurden – der Governance-Fehler geschieht upstream, auf der Retrieval-Ebene, bevor das Modell die Anfrage verarbeitet.

Fünf Wege, wie eine RAG-Pipeline zum Exfiltrationsvektor wird

Die Wege, über die RAG-Pipelines Datenabfluss ermöglichen, reichen von strukturellen Designfehlern, die jede Standardimplementierung betreffen, bis zu ausgefeilten Angriffen mit gezieltem Aufwand. Alle fünf Wege lassen sich mit der richtigen Architektur verhindern. Keiner wird durch die Standardkonfiguration eines gängigen RAG-Frameworks verhindert.

Der strukturelle Fehler, mit dem die meisten RAG-Pipelines ausgeliefert werden

Von den fünf Exfiltrationswegen ist die übermäßige Berechtigung beim Retrieval am weitesten verbreitet, weil sie Standard ist. Eine RAG-Pipeline mit einem Service-Account, der weitreichenden Repository-Zugriff hat, und einer reinen Relevanzsuche, die unabhängig von der Nutzerautorisierung die semantisch ähnlichsten Dokumente zurückgibt, ist der Weg des geringsten Widerstands. Sie erfordert keine zusätzliche Konfiguration, funktioniert sofort und liefert die beste Retrieval-Qualität – weil sie den gesamten Korpus durchsucht, nicht nur einen nutzerbezogenen Teil.

Die Sicherheitsfolge: Der Vorteil der Retrieval-Qualität geht zulasten der Zugriffskontrolle. Ein reines Relevanz-Retrieval ohne nutzerbezogene Autorisierung ruft nicht die Dokumente ab, die der Nutzer sehen darf – sondern die, die zur Anfrage passen. Das ist nicht derselbe Satz. Eine Anfrage nach „Finanzergebnis Q3″ kann ebenso Vorstandsdokumente mit vertraulichen Inhalten liefern wie die eigentlich autorisierte Zusammenfassung – das Retrieval-System kann nicht unterscheiden.

Die Lösung ist die Durchsetzung von RBAC und ABAC pro Anfrage auf der Retrieval-Ebene – nicht als nachgelagerter Filter, sondern als Einschränkung dessen, was das Retrieval-System für eine Nutzeranfrage überhaupt zurückgeben darf. Nachgelagerte Filterung (erst alles abrufen, dann entfernen, was der Nutzer nicht sehen darf) setzt sensible Inhalte bereits dem Kontextfenster der KI aus, bevor der Filter greift. Vorab-Autorisierung (nur abrufen, was der Nutzer sehen darf) stellt sicher, dass sensible Dokumente gar nicht erst in die KI gelangen. Der Unterschied ist architektonisch entscheidend: Nachgelagerte Filterung ist Output-Kontrolle; Vorab-Autorisierung ist Zugriffskontrolle.

Indirekte Prompt Injection: Der Angriff, der in Ihren eigenen Dokumenten steckt

Direkte Prompt Injection – Nutzer versuchen, die KI über ihre eigenen Anfragen zu manipulieren – ist gut verstanden und durch Input-Validierung und System-Prompt-Design relativ gut mitigiert. Indirekte Prompt Injection über die RAG-Retrieval-Ebene ist weniger verstanden und deutlich schwerer zu verhindern, da der Angriffsvektor die Datenquelle ist, der das Unternehmen selbst vertraut.

So funktioniert der Angriff: Ein Angreifer mit Schreibzugriff auf ein vom RAG-System indexiertes Repository – etwa ein Netzlaufwerk, ein Dokumentenmanagementsystem, eine Kollaborationsplattform – erstellt ein Dokument mit Anweisungen, die von der KI als Direktiven und nicht als Inhalt interpretiert werden. Führt eine legitime Nutzeranfrage dazu, dass dieses Dokument abgerufen wird, gelangen die eingebetteten Anweisungen zusammen mit legitimen Inhalten in das Kontextfenster der KI – und die KI kann sie ausführen, etwa indem sie andere abgerufene Dokumente ausgibt, Daten an externe Endpunkte überträgt oder Aktionen ausführt, die der Nutzer nicht beabsichtigt hat. Wenn die Anweisungen die KI anweisen, andere Dokumente im Kontext auszugeben, Inhalte an externe Endpunkte zu senden oder nicht angeforderte Aktionen auszuführen, kann die KI dem nachkommen – denn aus ihrer Sicht kamen die Anweisungen aus einer vertrauenswürdigen Datenquelle.

Die Auswirkung auf Data Loss Prevention ist erheblich: Ein Angreifer muss weder das KI-System noch die Retrieval-Infrastruktur oder Nutzerkonten kompromittieren. Es genügt, ein Dokument in ein indexiertes Repository einzuschleusen – eine Berechtigung, die in den meisten Unternehmen weit verbreitet ist. Jeder Auftragnehmer mit SharePoint-Zugang, jeder Kunde mit Zugriff auf einen geteilten Arbeitsbereich, jeder Lieferant, der Dokumente in eine Verarbeitungswarteschlange einreichen kann, ist ein potenzieller Angriffsvektor.

Korpus-Integritätskontrollen – Validierung der Dokumentenquellen und Scans nach eingebetteten Anweisungsmustern vor der Indexierung – reduzieren dieses Risiko erheblich. Ebenso eine zero trust Datenarchitektur, die einschränkt, welche Anweisungen die KI auf Basis abgerufener Inhalte ausführen darf, unabhängig vom Inhalt selbst. Beides eliminiert das Risiko nicht vollständig, weshalb Output-Monitoring auf anomale Inhaltsmuster – etwa Rohdaten-Dumps, base64-codierte Inhalte oder verdächtige strukturierte Daten – als zusätzliche Erkennungsebene notwendig ist.

Warum traditionelle DLP RAG-Exfiltration nicht erkennt

Unternehmen mit ausgereiften Data Loss Prevention-Programmen gehen oft davon aus, dass diese Kontrollen auch für RAG-Pipeline-Ausgaben greifen. In den meisten Fällen tun sie das nicht – oder sie erkennen nur die offensichtlichsten Fälle und übersehen die systematischen.

Traditionelle DLP arbeitet mit Datenmustern: regulären Ausdrücken, Schlagwortsuche, Dateityperkennung, Fingerprinting. Sie erkennt effektiv, wenn eine Datei mit dem Label „CONFIDENTIAL“ an eine externe E-Mail angehängt wird oder eine Sozialversicherungsnummer in einer Nachricht an eine externe Domain auftaucht. Die Ausgabe einer RAG-Pipeline sieht anders aus. Die KI fasst abgerufene Inhalte in natürlicher Sprache zusammen – als Zusammenfassungen, Analysen, Berichte. Sensible Informationen aus vertraulichen Dokumenten können als umformulierte Prosa, eingebettet in Empfehlungen oder verteilt über mehrere Antwortabschnitte erscheinen. Musterbasierte DLP, die auf strukturierte sensible Daten achtet, hat bei solchen synthetisierten Inhalten nur begrenzte Sichtbarkeit.

Gerade der Bulk-Enumeration-Angriff umgeht DLP gezielt, weil jede einzelne Anfrage und Antwort völlig legitim wirkt – ein autorisierter Nutzer stellt eine nachvollziehbare Frage und erhält eine plausible Antwort. Das Muster, das den Angriff verrät, ist verhaltensbasiert, nicht inhaltlich: die Anzahl der Anfragen, die systematische Variation der Suchbegriffe, die kumulierte Breite der abgerufenen Daten über mehrere Sitzungen. Die Erkennung erfordert Analyse der Audit-Trails auf der Retrieval-Ebene, nutzerbezogene Baseline-Modelle und SIEM-Integration, die Sitzungen aggregiert – Fähigkeiten, die upstream von klassischen DLP-Lösungen liegen.

Detection Controls: Was Echtzeit-Monitoring erkennen muss

Wann RAG-Exfiltration Meldepflichten auslöst

Die regulatorische Frage, die CISO- und Compliance-Paare bei RAG-Vorfällen am häufigsten falsch beantworten, ist, ob ein Datenzugriff über eine KI-Pipeline dieselben Meldepflichten auslöst wie ein klassischer Datenschutzverstoß. Die Antwort ist sowohl nach HIPAA als auch DSGVO: Unbefugter Zugriff auf geschützte Daten löst Meldepflichten aus – unabhängig vom genutzten Kanal. Eine KI-Pipeline ist kein sicherer Hafen.

Die operativ wichtigere Frage ist, ob das Unternehmen den Umfang des Zugriffs bestimmen kann – welche Datensätze wurden abgerufen, durch wessen Sitzung, über welchen Zeitraum. Hier werden Lücken im Audit-Trail der RAG-Pipeline zur Meldepflichtfalle. HIPAA verlangt, dass die betroffenen PHI und – soweit möglich – die betroffenen Personen identifiziert werden. Die DSGVO verlangt eine Beschreibung der Art des Verstoßes, der betroffenen Datenkategorien und der ungefähren Anzahl der Datensätze. Kann das Unternehmen diese Fragen nicht beantworten – weil die RAG-Pipeline nur Service-Account-Zugriffe statt nutzer- und dokumentenbezogener Retrieval-Events protokolliert – bleibt nur die Wahl zwischen Übermeldung auf Basis des maximal möglichen Umfangs und Untermeldung aufgrund unvollständiger Daten. Beides ist unter beiden Regelwerken nicht akzeptabel, und die Compliance-Folgen der Untermeldung sind gravierend.

Vollständige Audit-Trails mit doppelter Zuordnung – jeder Retrieval-Vorgang mit KI-Systemidentität, authentifizierter Nutzeridentität und abgerufenem Dokument – sind die Grundlage für eine präzise Meldung. Sie sind auch die Basis jeder Verteidigung gegen regulatorische Vorwürfe, dass Meldepflichten nicht erfüllt wurden. Eine RAG-Pipeline, die konforme Audit-Trails erzeugt, ist nicht nur ein besseres Sicherheitstool – sie ist ein nachweislich steuerbares System.

Wie Kiteworks die RAG-Retrieval-Ebene absichert

Die Sicherheitslücke in den meisten RAG-Implementierungen liegt nicht auf der KI-Ebene, sondern bei der Retrieval-Komponente, wo Dokumente abgerufen, extrahiert und an die KI übergeben werden. Diese Lücke lässt sich schließen, indem die RAG-Retrieval-Komponente als gesteuertes Datenzugriffssystem behandelt wird – mit denselben Kontrollen wie für jedes System, das sensible Unternehmensdaten im großen Umfang verarbeitet: Autorisierung pro Anfrage, Durchsetzung von Sensitivitätskennzeichnungen, Ratenbegrenzung und Echtzeit-Monitoring mit vollständiger Zuordnung.

Das Kiteworks AI Data Gateway und das Private Data Network bieten eine gesteuerte Retrieval-Ebene für RAG-Pipelines, die jeden Exfiltrationsweg gezielt adressiert. RBAC und ABAC pro Anfrage werden auf der Retrieval-Ebene durchgesetzt – nicht als nachgelagerter Filter, sondern als Zugriffsbeschränkung vor dem Retrieval.

Bevor ein Dokument in den KI-Kontext gelangt, prüft die Kiteworks Data Policy Engine, ob der authentifizierte Nutzer zugriffsberechtigt ist. Dokumente, die diese Prüfung nicht bestehen, werden nicht abgerufen; sie werden nicht erst nach dem Retrieval gefiltert. Datenklassifizierungen und Sensitivitätsrichtlinien werden auf derselben Ebene geprüft – ein als „Restricted“ gekennzeichnetes Dokument gelangt nie in den KI-Kontext eines Nutzers ohne entsprechende Berechtigung, unabhängig von seiner semantischen Relevanz für die Anfrage.

Ratenbegrenzung am Data Gateway begrenzt das Retrieval-Volumen pro Nutzer und Sitzung, sodass Bulk-Enumeration-Angriffe architektonisch begrenzt und nicht erst nachträglich erkannt werden. Jeder Retrieval-Vorgang – Anfrage, abgerufenes Dokument, Nutzeridentität, Autorisierungsentscheidung, Zeitstempel – wird in das Kiteworks-Audit-Log geschrieben und in Echtzeit ohne Verzögerung an SIEM übermittelt.

Sicherheitsteams sehen jeden RAG-Retrieval-Vorgang in Echtzeit, mit doppelter Zuordnung – KI-System und menschlicher Nutzer – wie es für die Bestimmung des Vorfallumfangs und regulatorische Meldungen erforderlich ist. Das zero trust Daten-Exchange-Framework, das sichere Filesharing, Managed File Transfer und Secure Email im Unternehmen steuert, gilt für jeden RAG-Retrieval – so unterliegt die Pipeline Ihres KI-Assistenten denselben Sicherheitsstandards wie alle anderen Datenkanäle und wird nicht als Sonderfall außerhalb der normalen Governance behandelt.

Für CISOs und Compliance-Beauftragte, die nachweisen müssen, dass ihre RAG-Pipeline nicht als Exfiltrationsvektor missbraucht werden kann – gegenüber Vorstand, Auditoren und Aufsichtsbehörden – bietet Kiteworks die gesteuerte Retrieval-Ebene, die diesen Nachweis ermöglicht. Um dies live zu erleben, vereinbaren Sie jetzt eine individuelle Demo.

Weitere Ressourcen

• Blog-Beitrag
  Zero‑Trust-Strategien für erschwinglichen KI-Datenschutz
• Blog-Beitrag
  Wie 77 % der Unternehmen bei KI-Datensicherheit scheitern
• eBook
  AI Governance Gap: Warum 91 % der kleinen Unternehmen 2025 russisches Roulette mit Datensicherheit spielen
• Blog-Beitrag
  Für Ihre Daten gibt es kein „–dangerously-skip-permissions“
• Blog-Beitrag
  Aufsichtsbehörden fragen nicht mehr, ob Sie eine KI-Policy haben. Sie wollen den Nachweis, dass sie funktioniert.