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

Dit onderzoek toont aan dat hybride Retrieval-Augmented Generation-systemen kwetsbaar zijn voor 'Retrieval Pivot Attacks' waarbij vector-gebaseerde zoekopdrachten via entiteitslinks ongeautoriseerde toegang tot gevoelige gegevens mogelijk maken, en demonstreert dat het afdwingen van autorisatie op de grens van de grafexpansie deze lekken effectief elimineert.

De kern

Hier is een uitleg van het paper in eenvoudig Nederlands, met behulp van alledaagse metaforen.

🕵️‍♂️ Het Probleem: De "Valse Vriend" in de Bibliotheek

Stel je voor dat een groot bedrijf een super slimme digitale bibliothecaris heeft die alle documenten van het bedrijf kent. Dit is een Hybrid RAG-systeem (een combinatie van twee zoekmethodes).

1. De Vector-zoektocht (De Google-achtige zoekbalk): Als je een vraag stelt, zoekt de bibliothecaris eerst naar documenten die qua inhoud lijken op je vraag. Dit werkt veilig: als je een gewone werknemer bent, krijg je alleen documenten van jouw afdeling.
2. De Grafische uitbreiding (De "Wie kent wie?"-netwerk): Om het antwoord nog beter te maken, kijkt de bibliothecaris daarna naar de verbindingen tussen de gevonden documenten. Als er in een document een naam staat (bijv. "CloudCorp"), loopt hij door het netwerk om te zien wat er nog meer over "CloudCorp" te vinden is.

Het gevaar (De Pivot-aanval):
Het probleem zit hem in de overgang tussen stap 1 en stap 2.
Stel, jij (een ingenieur) vraagt: "Hoe werkt onze server?"

• De bibliotheek geeft je veilig documenten over jouw server.
• Maar in die documenten staat de naam "CloudCorp" (een leverancier die iedereen gebruikt).
• De bibliothecaris denkt: "Ah, ik ga nu kijken wat er nog meer over CloudCorp staat!" en rent het netwerk in.
• Omdat "CloudCorp" ook in documenten staat van de HR-afdeling (waar jouw salarisgegevens staan) en de Financiële afdeling (waar topgeheime plannen staan), springt de bibliothecaris daar naartoe.
• Resultaat: Jij krijgt per ongeluk je eigen salarisgegevens en topgeheime plannen van een ander bedrijf in je antwoord, terwijl je alleen naar je serverkeuze keek.

De paper noemt dit een "Retrieval Pivot Attack". Het is alsof je een veilig huis binnenkomt via de voordeur (vector), maar via een verborgen gang (het graafnetwerk) per ongeluk de kluis van de buren binnenloopt.

---

🧪 Wat hebben ze ontdekt? (De Experimenten)

De onderzoekers hebben dit getest met drie verschillende "bibliotheken":

1. Een nep-bedrijf met 1.000 documenten.
2. De echte Enron-e-mails (50.000 e-mails van een failliet energiebedrijf).
3. Echte SEC-rapporten (financiële verslagen van grote bedrijven).

De schokkende bevindingen:

• Het gebeurt vanzelf: Je hoeft geen hacker te zijn die kwaadaardige documenten injecteert. Omdat bedrijven vaak dezelfde leveranciers, software of mensen delen, zijn deze "gevaarlijke verbindingen" al aanwezig.
• Het is extreem gevaarlijk: Zonder beveiliging krijgt een gebruiker in 95% van de gevallen per ongeluk gevoelige informatie van anderen te zien.
• De "2-stappen-regel": Het lekke gat zit altijd op precies 2 stappen verwijderd van je originele zoekopdracht.
  • Stap 1: Jouw veilige document.
  • Stap 2: De gedeelde naam (bijv. "CloudCorp").
  • Stap 3: Het geheime document van een ander.
  • Zodra je stap 2 passeert, ben je al in de verkeerde buurt.

---

🛡️ De Oplossing: De "Paspoortcontrole" bij elke Kamer

De paper stelt een oplossing voor die verrassend simpel is, maar enorm effectief.

Stel je voor dat de bibliothecaris niet alleen naar de voordeur kijkt, maar ook bij elke kamerdeur die hij opent, even checkt of jij daar mag zijn.

De oplossing (D1 - Per-hop Autorisatie):
Elke keer als de bibliothecaris een nieuwe naam of document vindt in het netwerk, moet hij vragen: "Mag deze gebruiker dit document zien?"

• Als het antwoord nee is (bijv. het is een HR-document en jij bent een ingenieur), dan stopt hij daar en gaat hij niet verder.
• Hij gooit het document weg voordat het bij jou terechtkomt.

Waarom is dit zo goed?

• Het werkt direct: Het blokkeert 100% van de lekkage, zelfs bij de Enron-e-mails en de SEC-rapporten.
• Het is snel: Het kost bijna geen tijd (< 1 milliseconde).
• Het is veilig: Je hoeft geen nieuwe software te bouwen; je gebruikt de bestaande labels (wie mag wat zien) die al in het systeem zitten.

---

🎯 Samenvatting in één zin

Hybride zoeksystemen die documenten koppelen aan netwerken van namen, laten per ongeluk gevoelige data van anderen lekken via gedeelde namen (zoals leveranciers), maar dit kan volledig worden opgelost door bij elke stap in het netwerk te controleren of de gebruiker daar ook daadwerkelijk toestemming voor heeft.

De kernboodschap: Vertrouw niet alleen op de voordeur (de zoekbalk); controleer ook elke kamerdeur die je opent in het netwerk.

Technische samenvatting

Hier is een gedetailleerde technische samenvatting van het paper "Retrieval Pivot Attacks in Hybrid RAG" in het Nederlands.

Titel: Retrieval Pivot Attacks in Hybrid RAG: Het Meten en Mitigeren van Geamplificeerde Lekkage van Vectorzaden naar Grafexpansie

Auteur: Scott Thornton (Perfecxion.ai)

---

1. Het Probleem: De "Pivot Boundary" in Hybrid RAG

Retrieval-Augmented Generation (RAG) systemen worden steeds vaker hybride ingericht: ze combineren vector-similariet-zoekopdrachten (voor semantische relevantie) met kennisgraf-expansie (voor multi-hop redenering). Hoewel beide componenten afzonderlijk veilig kunnen zijn, introduceert hun samenstelling een nieuw, kritiek beveiligingsprobleem: de Retrieval Pivot Risk (RPR).

• De Kwetsbaarheid: In een hybride pipeline worden eerst documenten ("zaden") opgehaald via een vectordatabase (waarbij tenant-beperkingen worden afgedwongen). Deze zaden worden vervolgens gebruikt om een kennisgraf te doorlopen via entiteiten (bijv. bedrijfsnamen, personen, systemen).
• De Faille: De grafexpansie-engine heeft vaak toegang tot het volledige kennisgraf, inclusief data van andere tenants of hogere gevoeligheidsniveaus. Omdat de vector-lookup al is voltooid, wordt de autorisatie niet opnieuw gecontroleerd wanneer de graf wordt doorlopen.
• Het Resultaat: Een geautoriseerde zoekopdracht kan via gedeelde entiteiten (bijv. een gemeenschappelijke leverancier of infrastructuur) "pivotten" naar gevoelige data van andere tenants. Dit gebeurt zelfs zonder kwaadaardige injectie; de natuurlijke structuur van multi-tenant data volstaat.

2. Methodologie en Experimenteel Opzet

De auteurs hebben een robuust evaluatiekader ontwikkeld om dit risico te kwantificeren en te testen op drie verschillende corpora:

1. Synthetisch Enterprise Corpus: 1.000 documenten over 4 tenants, met 2.785 grafknooppunten en 15.514 randen.
2. Enron Email Corpus: 50.000 e-mails, gesegmenteerd per afdeling als tenants.
3. SEC EDGAR 10-K: Financiële rapporten van 20 bedrijven over 4 sectoren.

Metrieken:

• Retrieval Pivot Risk (RPR): De waarschijnlijkheid dat een zoekopdracht ongeautoriseerde items bevat.
• Leakage@k: Het aantal ongeautoriseerde items in de context.
• Amplification Factor (AF): Hoeveel keer meer lekkage er optreedt in hybride systemen vergeleken met vector-only systemen.
• Pivot Depth (PD): Het aantal hops (stappen) in de graf dat nodig is om van een geautoriseerd zaad naar ongeautoriseerde data te komen.

Aanvalsmodellen:
De auteurs definiëren vier niet-adaptieve aanvallen (A1-A4) die variëren van "Seed Steering" (manipulatie van vector-zoekresultaten) tot "Bridge Node Attacks" (creëren van kunstmatige cross-tenant connecties). Cruciaal is dat ze aantonen dat geen enkele injectie nodig is; organische gedeelde entiteiten volstaan voor lekkage.

3. Belangrijkste Bijdragen

1. Formalisatie van RPR: Het paper introduceert een nieuwe kwetsbaarheid die ontstaat door de compositie van twee veilige retrieval-modi. Het definieert de "Pivot Boundary" als het architecturale punt waar autorisatie opnieuw moet worden afgedwongen.
2. Structurale Invariant (PD = 2): De auteurs ontdekken dat lekkage in bipartiete grafen (chunk -> entiteit -> chunk) bijna altijd optreedt op exact 2 hops.
   • Hop 0: Geautoriseerd zaad (vector).
   • Hop 1: Gedeelde entiteit (geen eigenaar/label).
   • Hop 2: Ongeautoriseerde chunk (via de entiteit).
3. Organische Lekkage: Het bewijs dat dit probleem inherent is aan multi-tenant systemen. Zelfs met "goede" zoekopdrachten en zonder kwaadaardige documenten, lekt er data door natuurlijke connecties (bijv. dezelfde leverancier in verschillende afdelingen).
4. Defensie Strategie (D1): Het identificeren van Per-Hop Autorisatie als de enige noodzakelijke en voldoende oplossing.

4. Resultaten

• Extreme Lekkage in Onverdedigde Systemen:
  • In het synthetische corpus had de hybride pipeline (zonder verdediging) een RPR van 0,95 (95% van de zoekopdrachten lekte data).
  • De vector-only baseline had een RPR van 0,0.
  • De Amplification Factor (AF) bedroeg tussen de 160x en 194x. Dit betekent dat hybride systemen niet alleen bestaand risico vergroten, maar nieuw risico creëren waar er voorheen geen was.
• Cross-Dataset Validatie:
  • Enron: RPR = 0,695.
  • EDGAR: RPR = 0,085 (lager door minder organische connecties, maar nog steeds aanwezig).
  • De PD = 2 structuur bleek consistent over alle drie de corpora, ongeacht de grootte of het domein.
• Effectiviteit van Defensie (D1):
  • Door Per-Hop Autorisatie toe te passen (het opnieuw controleren van tenant- en gevoeligheidslabels bij elke stap in de grafexpansie), daalde de RPR naar 0,0 in alle scenario's.
  • Dit gebeurde met een verwaarloosbare latency-toename (<1ms).
  • De verdediging werkte ook tegen metadata-vervalsing tot 5% en diverse aanvalstypes.

5. Betekenis en Conclusie

Dit paper is van groot belang voor de beveiliging van Enterprise AI-systemen:

• Fundamentele Architectuurfout: Het toont aan dat het vertrouwen op autorisatie alleen bij de vector-lookup onvoldoende is voor hybride RAG. De grafexpansie is een "verwarde ondergeschikte" (confused deputy) die namens de gebruiker handelt maar de beperkingen van die gebruiker niet respecteert.
• Oplossing is Eenvoudig: De kwetsbaarheid is geen complex probleem dat ingewikkelde AI-modellen vereist om op te lossen. Het is een grensafdwingingsprobleem. Het opnieuw toepassen van bestaande metadata (tenant ID, gevoeligheidsniveau) op elke grafknoop lost het probleem volledig op.
• Praktische Aanbeveling: Organisaties die Hybrid RAG (zoals Microsoft GraphRAG, LangChain met grafen) implementeren, moeten Per-Hop Autorisatie direct implementeren. Dit is de minimale veilige configuratie.
• Toekomstige Richting: Het paper suggereert dat toekomstige systemen "entiteit-bewuste" autorisatie moeten ontwikkelen (waarbij gedeelde entiteiten wel toegestaan zijn, maar de daaropvolgende chunks wel worden gefilterd) om de bruikbaarheid van de graf te behouden zonder de veiligheid te riskeren.

Kortom: Zonder specifieke verdediging op de graf-expansiegrens zijn hybride RAG-systemen structureel onveilig voor multi-tenant omgevingen, met een hoog risico op datalekken die niet voorkomen in traditionele vector-only systemen.