RAG-Systeme leaken Daten: KI ist eine Security-Aufgabe

Ein Sprachmodell, das auf Ihren internen Dokumenten antwortet, ist für viele Unternehmen der erste greifbare KI-Nutzen: Angebote, Handbücher, Vertragsklauseln, Tickets – auf Zuruf beantwortet, statt in Ordnerstrukturen gesucht. Die Technik dahinter heißt Retrieval-Augmented Generation (RAG): Das Modell bekommt zur Beantwortung einer Frage passende Ausschnitte aus Ihren Dokumenten mitgeliefert und formuliert daraus die Antwort. Der Reiz ist offensichtlich. Das Risiko wird meist übersehen.

Denn RAG ist im Kern eine Suchmaschine mit vorgeschaltetem Formulierungsmodell. Und eine Suchmaschine über Unternehmensdaten ist nur so vertrauenswürdig wie die Berechtigungen, die sie durchsetzt. Wird ein RAG-System gebaut, ohne die Zugriffsrechte des Quellsystems mitzuführen, passiert genau das, was passieren muss: Ein Nutzer bekommt Inhalte serviert, die er nie hätte sehen dürfen. Das ist kein exotischer Sonderfall, sondern die häufigste und teuerste RAG-Fehlfunktion.

Der Standardfehler: die Berechtigungen bleiben zurück

In einer sauber betriebenen Dateiablage entscheidet eine Zugriffsliste, wer ein Dokument öffnen darf. Der Vertriebsmitarbeiter sieht seine Angebote, nicht die Gehaltsliste der Geschäftsführung. Beim Aufbau eines RAG-Systems werden diese Dokumente jedoch zerlegt, in Vektoren umgerechnet und in einer Vektordatenbank abgelegt – und an dieser Stelle geht die Berechtigung häufig verloren. Die Vektordatenbank kennt dann nur noch Inhalte, keine Zugriffsrechte mehr. Wer fragt, bekommt geantwortet, was inhaltlich passt, nicht was er sehen darf.

Das OWASP-Projekt hat diese Klasse von Fehlern 2025 ausdrücklich aufgewertet. In der aktualisierten OWASP Top 10 for LLM Applications rückte „Sensitive Information Disclosure“ auf Platz 2 vor, und mit „Vector and Embedding Weaknesses“ (LLM08) kam eine völlig neue Kategorie hinzu, die genau diese RAG-spezifischen Schwächen benennt: manipulierte Suche, tenant- und berechtigungsübergreifender Zugriff, das Rückrechnen von Klartext aus Embeddings. Die Botschaft ist eindeutig: Wer RAG einsetzt, hat ein neues, eigenständiges Angriffs- und Leckage-Feld eröffnet.

Zwei reale Muster: Copilot als Anschauungsobjekt

Wie das in der Praxis aussieht, lässt sich an Microsoft 365 Copilot studieren – einem der am breitesten ausgerollten RAG-Systeme überhaupt.

Das erste Muster ist die schlichte Überteilung von Rechten. Copilot antwortet auf Basis dessen, worauf ein Nutzer laut Berechtigung zugreifen kann. Sind diese Berechtigungen im Unternehmen jahrelang großzügig vergeben worden – die berüchtigte SharePoint-Freigabe „für alle im Unternehmen“ –, macht KI diese Altlast plötzlich sichtbar und durchsuchbar. Der Analyse-Dienstleister Concentric fand, dass 15 Prozent der geschäftskritischen Ressourcen von Überteilung betroffen waren und von Personen eingesehen werden konnten, die keinen Zugriff haben sollten. Die KI hat das Problem nicht geschaffen. Sie hat es nur aus der Deckung geholt.

Das zweite Muster ist der gezielte Angriff auf die RAG-Kette. Unter dem Namen „EchoLeak“ (CVE-2025-32711, CVSS 9.3) beschrieb das Sicherheitsteam von Aim Labs 2025 einen Zero-Click-Angriff auf Microsoft 365 Copilot: Eine einzige präparierte E-Mail genügte – ohne dass der Empfänger sie öffnen oder anklicken musste –, um Copilot dazu zu bringen, interne Inhalte aus SharePoint, OneDrive und Teams zusammenzutragen und an einen fremden Server auszuleiten. Microsoft schloss die Lücke serverseitig und meldete keine Ausnutzung in freier Wildbahn. Der Fall bleibt lehrreich: Untrusted Input – hier eine E-Mail – konnte die Grenze zu vertrauenswürdigen internen Daten überschreiten. Ein verwandtes Forschungsergebnis der University of Texas („ConfusedPilot“, 2024) zeigte zudem, wie untergeschobene Dokumente ein RAG-System zu falschen Aussagen bewegen und dabei Zugriffskontroll-Fehlkonfigurationen ausnutzen können.

Multi-Tenant: das teuerste Leck

Am gravierendsten wird es, wenn ein RAG-System für mehrere Mandanten dieselbe Vektordatenbank nutzt – etwa ein Dienstleister, der für mehrere Kunden Wissen zugänglich macht. Ohne harte Trennung teilen sich die Dokumente verschiedener Kunden denselben Suchraum, und die Ähnlichkeitssuche kennt keine Kundengrenzen. Eine Anfrage von Kunde A kann dann Inhalte von Kunde B zurückliefern – nicht wegen eines spektakulären Hacks, sondern weil die Datenbank nie gelernt hat, dass es eine Grenze gibt.

Vektordatenbanken wurden vielfach nicht mit dokumentgenauer Zugriffskontrolle als Kernfunktion entworfen. Praktiker berichten von tenant-übergreifender Leckage in nahezu allen Testabfragen, sobald die Suche ungefiltert erfolgt. Und die Folgen sind nicht abstrakt: Ein Zugriffskontroll-Fehler in einer verbreiteten Vektordatenbank legte über 200.000 Gesundheitsdatensätze offen. Cross-Tenant-Leakage ist deshalb nicht nur ein technischer Makel, sondern ein Datenschutz-, Haftungs- und Reputationsereignis.

Der Fix ist keine KI-Magie, sondern Handwerk

Die gute Nachricht: Die Gegenmaßnahmen sind bekannt. Es sind dieselben Prinzipien, die auch außerhalb der KI eine belastbare Sicherheitsarchitektur ausmachen – konsequent auf die RAG-Kette angewendet.

Berechtigungen zuerst sauber machen. Bevor Daten in ein RAG-System fließen, gehört das Freigabe-Chaos aufgeräumt. RAG macht bestehende Über-Freigaben sichtbar; wer sie vorher nicht bereinigt, exportiert das Problem ins Modell.
Zugriffskontrolle bis auf Dokumentebene mitführen. Jeder in die Vektordatenbank abgelegte Ausschnitt trägt seine Berechtigungs-Metadaten – erlaubte Nutzer und Gruppen – als Bestandteil. Zum Abfragezeitpunkt wird zweistufig gefiltert: vor der Suche über Metadaten, nach der Suche über eine echte Berechtigungsprüfung gegen das Quellsystem. Ändern sich Rechte, greift die neue Berechtigung sofort, nicht erst nach der nächsten Neu-Indexierung.
Mandanten hart trennen. In Multi-Tenant-Szenarien wird die Tenant-Grenze auf Ebene des Vektor-Index erzwungen, nicht erst in der Anwendungslogik darüber.
Lückenlos protokollieren. Jeder Abruf hinterlässt eine Zeile: wer, welche Anfrage, welche Ausschnitte geliefert, welche verweigert. Ohne dieses Protokoll lässt sich weder ein Vorfall aufklären noch ein Audit bestehen.
Untrusted Input als solchen behandeln. E-Mails, hochgeladene Dateien, externe Web-Inhalte dürfen die Vertrauensgrenze zu internen Daten nicht unkontrolliert überschreiten – die Lehre aus EchoLeak.

Das ist, nüchtern betrachtet, klassische Zugriffskontrolle, Datenklassifizierung, Protokollierung und Netzsegmentierung. Die Fähigkeit, eine RAG-Architektur zu bauen, die ein Audit übersteht, ist keine KI-Kompetenz. Sie ist eine Security-Kompetenz.

Warum das eine Sicherheitsaufgabe ist, keine KI-Spielerei

Wer ein RAG-System als Datenprojekt behandelt – „wir kippen unsere Dokumente hinein und stellen ein Modell davor“ –, baut zuverlässig ein Leck. Wer es als Sicherheitsprojekt behandelt, stellt vor der ersten Antwort die richtigen Fragen: Welche Berechtigung hat der Anfragende? Welche Metadaten trägt jeder Ausschnitt? Wo verläuft die Mandantengrenze? Was steht im Protokoll? Diese Fragen entscheiden darüber, ob aus dem Produktivitätsgewinn ein Datenschutzvorfall wird.

Genau hier trennt sich der Weg. Souveräne KI auf den eigenen Daten entsteht nicht dadurch, dass ein Modell besonders leistungsfähig ist, sondern dadurch, dass die Architektur um das Modell herum die Zugriffsregeln des Unternehmens durchsetzt – belastbar, nachweisbar, prüffähig.

Wie sector7 unterstützt

Wir betreiben abgesicherte private Sprachmodelle und Managed RAG auf unserem eigenen Serverpark in Deutschland – die Daten verlassen die von uns kontrollierte Umgebung nicht. Der entscheidende Unterschied liegt in unserer Herkunft: sector7 kommt aus der Sicherheits- und Netzwerk-Praxis. Wir bauen die RAG-Kette so, wie wir Perimeter und Backups bauen – mit dokumentgenauer Zugriffskontrolle, harter Mandantentrennung, lückenloser Protokollierung und einer Architektur, die einer Prüfung standhält. Das verbindet unsere souveräne KI direkt mit unserer bestehenden Cyber-Security-Praxis und unserer herstellerzertifizierten Engineering-Erfahrung auf Juniper, Cisco, HPE, F5, Fortinet und Palo Alto Networks. Wir trainieren keine eigenen Basismodelle und versprechen keine autonome KI-Belegschaft; große GPU-Kapazität beziehen wir über souveräne Partner. Was wir liefern, ist das, was RAG sicher macht: Security-Handwerk. Aus einem inhabergeführten Haus in Solingen.

KI auf Ihren Daten ist eine Security-Aufgabe: warum RAG-Systeme Daten leaken