Retrieval Pivot Attacks in Hybrid RAG: Measuring and Mitigating Amplified Leakage from Vector Seeds to Graph Expansion

Die Studie zeigt, dass hybride RAG-Pipelines durch eine neue Sicherheitslücke namens „Retrieval Pivot Attacks" anfällig für Datenlecks sind, die durch die unkontrollierte Erweiterung von Vektor- zu Graphendaten entstehen, und demonstriert, dass eine Autorisierung an der Übergangsstelle dieses Risiko effektiv eliminiert.

Das Wesentliche

Stellen Sie sich vor, Sie haben einen sehr klugen, aber etwas naiven Assistenten, der für Sie Informationen in einer riesigen Bibliothek sucht. Dieser Assistent arbeitet in zwei Schritten, um die besten Antworten zu finden:

1. Der Suchmaschinen-Schritt (Vektor-Suche): Zuerst schaut er in einen digitalen Katalog. Wenn Sie nach "Kubernetes" fragen, findet er Dokumente, die das Wort enthalten. Aber hier ist er vorsichtig: Er weiß, dass Sie nur Zugang zu den "Grünen Regalen" (Ihrer Abteilung) haben. Also holt er nur Dokumente von dort.
2. Der Detektiv-Schritt (Graph-Erweiterung): Jetzt wird es spannend. Der Assistent liest die gefundenen Dokumente und sagt: "Aha! In diesem Dokument steht 'CloudCorp'. Ich sollte mal nachschauen, was es sonst noch über CloudCorp zu wissen gibt!" Er springt also zu einem anderen Teil der Bibliothek, der als Wissensnetz organisiert ist. Hier sind alle Begriffe miteinander verbunden wie ein riesiges Spinnennetz.

Das Problem: Die unsichtbare Tür

Das Papier beschreibt ein gefährliches Sicherheitsleck in genau diesem zweiten Schritt.

Die Analogie:
Stellen Sie sich vor, Ihr Assistent darf nur die "Grünen Regale" betreten. Er holt ein Dokument aus dem Grünen Regal. Darin steht der Name "CloudCorp".
Der Assistent denkt: "Okay, ich gehe jetzt zum 'Wissensnetz', um mehr über CloudCorp zu erfahren."
Das Problem: Das Wissensnetz ist ein riesiger Raum, in dem alle Abteilungen (Grün, Rot, Blau) ihre Akten haben. Die Tür zu diesem Raum ist offen. Der Assistent vergisst, dass er eigentlich nur für die "Grünen Regale" zuständig ist.

Er läuft also durch das Netz, findet den Begriff "CloudCorp" und springt von dort direkt zu einem Dokument, das eigentlich nur für die "Roten" (eine andere Abteilung) gedacht ist – vielleicht sogar ein streng geheimes Gehaltsverzeichnis.
Das Ergebnis: Ihr Assistent bringt Ihnen plötzlich geheime Informationen einer anderen Abteilung in Ihren Bericht, obwohl Sie gar keinen Zugriff darauf haben sollten.

Das Papier nennt dies einen "Retrieval Pivot Attack" (Such-Drehpunkt-Angriff). Der Assistent nutzt einen harmlosen Begriff aus Ihrem erlaubten Dokument als "Drehpunkt" (Pivot), um in verbotene Bereiche zu springen.

Warum ist das so schlimm?

1. Es passiert automatisch: Sie müssen nichts Böses tun. Selbst wenn Sie eine ganz normale, harmlose Frage stellen (z. B. "Wie funktioniert unsere Server-Infrastruktur?"), kann das System durch gemeinsame Begriffe (wie "CloudCorp" oder "Sicherheitsstandard ISO27001", die alle Abteilungen nutzen) versehentlich geheime Daten anderer Abteilungen in Ihre Antwort mischen.
2. Es ist extrem effektiv: Das Papier zeigt, dass in einem ungeschützten System fast jede Frage (95 %) versehentlich geheime Daten enthüllt.
3. Es ist tief verwurzelt: Das Problem liegt nicht in einem Fehler im Code, sondern im Design. Sobald man zwei sichere Systeme (die Suche und das Netzwerk) verbindet, entsteht eine neue, unsichere Tür dazwischen.

Die Lösung: Der Türsteher an der Schwelle

Die Autoren haben eine sehr einfache, aber geniale Lösung gefunden.

Die Analogie:
Stellen Sie sich vor, der Assistent läuft durch das Wissensnetz. An jeder Kreuzung, an der er von einem Begriff zu einem neuen Dokument springt, steht jetzt ein Türsteher.
Der Türsteher fragt bei jedem Sprung: "Darf diese Person (Sie) dieses spezifische Dokument sehen?"

• Wenn das Dokument aus der "Roten Abteilung" ist und Sie nur "Grün" sind: Stopp! Das Dokument wird nicht mitgenommen.
• Wenn das Dokument aus der "Grünen Abteilung" ist: Weiter!

Das Papier zeigt, dass dieser eine kleine Schritt – das Überprüfen der Berechtigungen bei jedem einzelnen Sprung im Netzwerk – das Problem zu 100 % löst.

• Keine Datenleckage mehr: Die geheime Information bleibt sicher.
• Kein großer Aufwand: Es kostet fast keine Zeit und benötigt keine neue Technologie. Die Daten (wer darf was sehen) sind bereits im System vorhanden, sie wurden nur bisher nicht an der richtigen Stelle geprüft.

Zusammenfassung in einem Satz

Wenn Sie einen KI-Assistenten nutzen, der von Textsuche zu einem Wissensnetz springt, müssen Sie sicherstellen, dass er an jeder einzelnen Station im Netzwerk prüft, ob er das, was er gerade findet, auch wirklich für Sie sehen darf – sonst holt er Ihnen versehentlich die Geheimnisse Ihrer Nachbarn mit nach Hause.

Technische Zusammenfassung

Hier ist eine detaillierte technische Zusammenfassung des Papers „Retrieval Pivot Attacks in Hybrid RAG" auf Deutsch:

Titel: Retrieval Pivot Attacks in Hybrid RAG: Messung und Minderung von verstärktem Datenleck von Vektor-Samen zu Graph-Erweiterung

1. Problemstellung

Hybride Retrieval-Augmented Generation (RAG)-Pipelines kombinieren zunehmend die Vektor-Similaritätssuche mit der Erweiterung durch Wissensgraphen (Knowledge Graphs), um mehrstufiges Schlussfolgern (Multi-Hop Reasoning) zu ermöglichen. Die Autoren identifizieren eine kritische Sicherheitslücke in dieser Architektur: den Retrieval Pivot.

• Der Pivot-Boundary-Fehler: Während die Vektor-Suche tenant-spezifische Zugriffskontrollen (z. B. Tenant-ID, Sensitivitätslevel) vor der Suche durchsetzt, fehlt diese Kontrolle oft beim Übergang zur Graph-Erweiterung.
• Der Mechanismus: Ein autorisierter Text-Chunk (der „Seed"), der durch Vektor-Suche gefunden wird, enthält Entitätsnamen (z. B. gemeinsame Infrastruktur, Lieferanten, Compliance-Standards). Diese Entitäten werden im Wissensgraphen verknüpft. Da Entitätsknoten im Graph oft keine Tenant-Metadaten tragen (da sie tenant-übergreifend genutzt werden), fungiert die Graph-Erweiterung als unkontrollierter Einstiegspunkt.
• Die Folge: Ein autorisierter Benutzer kann über eine 2-Hop-Verbindung (Chunk → Gemeinsame Entität → Unautorisierter Chunk eines anderen Tenants) auf sensible Daten zugreifen, die in einer reinen Vektor-Suche niemals erreicht worden wären. Dies wird als Retrieval Pivot Risk (RPR) bezeichnet.

2. Methodik und Experimentelles Setup

Die Studie formalisiert das Risiko und validiert es durch umfangreiche Experimente an drei verschiedenen Korpora:

• Metriken:
  • RPR (Retrieval Pivot Risk): Wahrscheinlichkeit, dass ein Kontext unautorisierte Items enthält.
  • Leakage@k: Anzahl der unautorisierten Items im Kontext.
  • Amplification Factor (AF): Das Verhältnis des Lecks im hybriden System im Vergleich zur reinen Vektor-Suche.
  • Pivot Depth (PD): Die minimale Anzahl von Graph-Hops vom Seed bis zum ersten unautorisierten Knoten.
• Korpora:
  1. Synthetischer Enterprise-Corpus: 1.000 Dokumente, 4 Tenants, 2.785 Graph-Knoten.
  2. Enron-E-Mail-Korpus: 50.000 E-Mails, 5 Abteilungen (realistische Daten).
  3. SEC EDGAR 10-K-Filings: 887 Sektionen von 20 Unternehmen (Finanzdaten).
• Angriffsmodelle:
  • Injection-Attacker: Fügt 10–20 manipulierte Dokumente ein.
  • No-Injection-Attacker: Nutzt nur natürliche, tenant-übergreifende Entitäten (z. B. gemeinsame Software-Namen), um Lecks auszulösen.
• Verteidigungsansätze: Evaluation von fünf Verteidigungsschichten (D1–D5), wobei der Fokus auf der Platzierung der Autorisierung liegt.

3. Schlüsselbeiträge

1. Formalisierung der Verwundbarkeit: Einführung des Konzepts „Retrieval Pivot Risk" und der zugehörigen Metriken, die zeigen, wie die Komposition zweier sicherer Retrieval-Modi (Vektor + Graph) eine neue Angriffsfläche schafft.
2. Strukturelle Invariante (PD = 2): Die Studie zeigt, dass in bipartiten Graphen (Chunk ↔ Entität) das Leck fast immer genau bei 2 Hops auftritt (Autorisierter Chunk → Geteilte Entität → Unautorisierter Chunk). Dies ist eine strukturelle Eigenschaft der Architektur, unabhängig von der Korpusgröße.
3. Organisches Leck: Es wird demonstriert, dass keine bösartige Injektion notwendig ist. Natürliche gemeinsame Entitäten in Multi-Tenant-Umgebungen reichen aus, um RPR-Werte von bis zu 0,95 zu erzeugen.
4. Effektive Abwehr: Nachweis, dass eine einzige, gut platzierte Verteidigung (Per-Hop-Autorisierung) das Problem vollständig löst, ohne signifikante Latenzkosten.

4. Ergebnisse

• Verstärkung des Lecks:
  • Reine Vektor-Suche (P1): RPR = 0,0 (keine Lecks).
  • Unverteidigter hybrider Pipeline (P3): RPR ≈ 0,95 (Synthetisch), 0,695 (Enron), 0,085 (EDGAR).
  • Amplification Factor: Der hybride Ansatz führt zu einer Verstärkung des Lecks um den Faktor 160–194× im Vergleich zur Vektor-Suche.
• Angriffserfolg: Alle vier definierten Angriffsstrategien (Seed Steering, Entity Anchor, Neighborhood Flooding, Bridge Node) erreichen bei der ungeschützten Pipeline eine Erfolgsrate von 100 % (RPR = 1,0).
• Verteidigungswirkung:
  • D1 (Per-Hop-Autorisierung): Wenn bei jedem Schritt der Graph-Erweiterung geprüft wird, ob der Knoten für den aktuellen Tenant und dessen Sensitivitätslevel freigegeben ist, sinkt der RPR auf 0,0 in allen Korpora und gegen alle Angriffsvarianten.
  • Kosten: D1 fügt weniger als 1 ms Latenz hinzu.
  • Kontextgröße: D1 reduziert den Kontext von ~110 Items (unverändert) auf ~50–56 autorisierte Items, entfernt aber effektiv alle unautorisierten Daten.
• Robustheit: Die Verteidigung bleibt auch bei zufälligen Metadaten-Fehlern (bis zu 5 %) stabil.

5. Bedeutung und Implikationen

• Architektonische Erkenntnis: Das Paper zeigt, dass Sicherheitskontrollen nicht nur am Eingang (Vektor-Suche) oder am Ausgang (LLM-Generation), sondern an der Schnittstelle zwischen Vektor- und Graph-Komponente implementiert werden müssen. Die Annahme, dass ein autorisierter Seed automatisch zu autorisierten Graph-Erweiterungen führt, ist falsch.
• Praktische Empfehlung: Für jede hybride RAG-Implementierung ist Per-Hop-Autorisierung (D1) die minimale, notwendige Sicherheitsmaßnahme. Sie nutzt bereits vorhandene Metadaten in Graph-Datenbanken und erfordert keine Änderung der Modelle.
• Agente-Systeme: Die Gefahr ist in autonomen Agenten-Systemen (z. B. LangGraph) besonders hoch, da diese Graph-Traversierungen ohne menschliche Aufsicht durchführen. Eine fehlende Per-Hop-Prüfung könnte zu massiven Datenlecks führen.
• Zukunft der Forschung: Die Studie hebt hervor, dass bestehende Sicherheitsforschung oft nur Vektor- oder nur Graph-Angriffe betrachtet, die hybride Schnittstelle jedoch ein neues, kritisches Forschungsfeld darstellt.

Fazit: Die Kombination von Vektor- und Graph-Retrieval führt zu einem signifikanten, strukturellen Sicherheitsrisiko, das durch natürliche Datenverknüpfungen entsteht. Dieses Risiko kann jedoch durch eine einfache, aber strikte Autorisierung an der Pivot-Grenze (jeder Graph-Schritt) vollständig eliminiert werden.