Eén kwaadaardig document kan een RAG-systeem vergiftigen: controleer zowel bron als vectorindex

Onderzoekers lieten met CorruptRAG zien dat één geprepareerd document al genoeg kan zijn om een RAG-assistent misleidende antwoorden te laten geven. Bescherm uw kennisbank daarom op twee niveaus: controleer herkomst, versie en hash van elk document vóór indexering, monitor embeddings, vectorindex en retrievalgedrag, en laat het systeem stoppen wanneer een integriteitscontrole faalt.

De studie Practical Poisoning Attacks against Retrieval-Augmented Generation beschrijft CorruptRAG, een aanval waarbij één poisoned text wordt geïnjecteerd. De kern: een aanvaller hoeft een kennisbank niet te overspoelen met honderden valse stukken. Eén zorgvuldig vervaardigd kwaadaardig document kan al voldoende zijn om de antwoorden van een RAG-systeem te sturen. RAG staat voor retrieval-augmented generation: een taalmodel haalt eerst relevante passages uit een eigen kennisbank op en formuleert daarmee zijn antwoord.

Dat maakt het onderwerp concreet voor iedere organisatie die interne documenten door zo'n assistent laat doorzoeken. De aanname dat een enkele foute upload wel zal verdrinken in de rest van de kennisbank, houdt geen stand.

Wat toont de CorruptRAG-studie precies aan over RAG-poisoning?

De ACM-studie demonstreert dat één poisoned tekst een RAG-systeem praktisch kan beïnvloeden, zonder dat de aanvaller veel documenten hoeft te injecteren. Dat is de nieuwswaarde. Volgens de studie kan één poisoned text de aanval relatief stil maken ten opzichte van grootschalige injectiecampagnes; de aanvaller heeft daarvoor nog steeds een mogelijkheid nodig om inhoud in de relevante kennisdatabase of ingestiepijplijn te plaatsen. De studie beschrijft daarmee een praktische aanvalsvector, niet alleen een scenario waarin meerdere documenten nodig zijn.

De tweede relevante bevinding komt uit de studie Influence Factors on RAG Poisoning, een volledige-factorial onderzoek met 432 configuraties. Daaruit blijkt dat de kans dat een vervuilde passage daadwerkelijk wordt opgehaald en het antwoord beïnvloedt, samenhangt met de retrieverarchitectuur, de dataset, de retrieval-diepte en de generator. Een grotere retrieval-diepte — in veel implementaties uitgedrukt als een hogere top-k, het aantal opgehaalde passages — verhoogt volgens de studie de kans dat poisoned passages worden opgehaald. De onderzoekers benadrukken dat de effecten voortkomen uit interacties tussen die componenten. Naar onze inschatting betekent dit dat deze cijfers geen universele benchmark zijn: hoe kwetsbaar uw systeem is, hangt af van uw eigen configuratie.

Waarom is het bronbestand alleen beschermen niet genoeg?

Omdat de schade niet in het document alleen ontstaat, maar in de keten erna. Een document wordt opgeknipt in stukken, omgezet naar embeddings (numerieke representaties die semantische gelijkenis meten) en opgeslagen in een vectorindex. De retriever bepaalt vervolgens welke stukken bij een vraag worden opgehaald. Elk van die schakels beïnvloedt of een vervuild stuk het antwoord bereikt.

Onze redactionele duiding: een kennisbank is pas verdedigbaar als documentintegriteit én de afgeleide vector- en retrievallaag samen worden bewaakt. Wie alleen de upload controleert, bewaakt de voordeur maar laat de gang erachter onbewaakt. En een belangrijke nuance: een overeenkomende hash bewijst alleen dat een document gelijk is aan een goedgekeurde versie, niet dat de inhoud juist of veilig is. Herkomst en integriteit zijn iets anders dan waarheid.

Welke integriteitscontroles adviseren OWASP en AWS voor een kennisbank?

De OWASP Foundation behandelt in haar RAG Security Cheat Sheet maatregelen voor documentintegriteit en voor embeddings en vectorindex als afzonderlijke controlegebieden. AWS verbindt in haar prescriptive guidance over data in generatieve AI datapoisoning met klassiek databeheer: broncuratie, versiebeheer en monitoring. Samengevat komen beide op een controleset op twee niveaus:

• Documentniveau: leg vóór indexering herkomst, uploader, goedkeuring, versie, hash en bestandstype vast; scan op verborgen instructies; verwerk wijzigingen via een aparte review- en signingprocedure.
• Vectorniveau: houd embeddingmodel en -versie, chunkrelaties, namespaces, toegangsmetadata per vectorchunk en indexmutaties controleerbaar; bewaar snapshots en logging van indexwijzigingen.
• Toegang en herkomst: filter toegang vóór retrieval en attribueer elk antwoord aan een bron met bijbehorende documenthash.
• Detectie en herstel: signaleer ongebruikelijke index- of retrievalwijzigingen, pas cascadeverwijdering toe en gebruik een beschermd manifest met documenthashes.
• Fail-closed gedrag: stop het antwoord wanneer een hash- of toegangscontrole faalt; val niet automatisch terug op het modelgeheugen.

Dat laatste punt verdient nadruk. Antwoorden zonder verifieerbare bronattributie, of antwoorden nadat retrieval- of integriteitscontroles falen, mogen niet stilletjes teruggrijpen op wat het model uit zijn training 'weet'. Juist dan verdwijnt het verschil tussen een gecontroleerd en een ongecontroleerd antwoord uit het zicht van de gebruiker.

Wat betekent dit voor bestuurders, juristen en CISO's die een RAG-assistent inzetten?

Onze analyse: omdat één geprepareerd document volgens de ACM-studie al effect kan hebben, moet een CISO eisen dat elke indexering een vastgelegde herkomst, goedkeuring en hash kent voordat een document doorgaat. Onze analyse: omdat de tweede studie laat zien dat retrieval-diepte de blootstelling vergroot, raakt een configuratiekeuze zoals top-k direct het securityrisico; daarom hoort die keuze thuis in het risicodossier van het systeem, niet alleen bij het ontwikkelteam. Onze analyse: omdat een overeenkomende hash geen waarheid bewijst, mag een jurist een RAG-antwoord niet als geverifieerd behandelen zonder bronattributie met documenthash; daarom hoort in de werkafspraak dat antwoorden zonder traceerbare bron niet worden gebruikt in besluitvorming. Onze analyse: omdat de uiteindelijke blootstelling mede door de vector- en retrievallaag wordt bepaald, moet een bestuurder budget vrijmaken voor monitoring van indexmutaties en retrievalgedrag, niet alleen voor uploadcontrole.

Praktisch samengevat, in volgorde van invoering:

1. Leg voor elk document herkomst, versie en hash vast en richt een signingprocedure voor wijzigingen in.
2. Maak de configuratie van retriever, retrieval-diepte en vectorindex onderdeel van uw AI-securitybeheersing voor AI-systemen.
3. Verplicht bronattributie met documenthash in elk antwoord en blokkeer antwoorden die daar niet aan voldoen, aansluitend bij het principe van verdedigbaar controlebewijs documenteren.
4. Monitor indexmutaties, bewaar snapshots en bereid cascadeverwijdering voor, zodat u bij een incident kunt terugdraaien, zoals bij een incident-responsdraaiboek voor AI-agents.

De open vraag blijft hoe precies de interactie tussen retriever, retrieval-diepte, dataset en generator de effectiviteit van een aanval bepaalt. Die afhankelijkheid betekent dat u uw eigen opstelling moet testen, aansluitend op het idee dat een intern herkomstdossier dat geen juistheid bewijst wel traceerbaarheid levert.

Bronnen: Het artikel steunt op de ACM-studie CorruptRAG, het arXiv-onderzoek Influence Factors on RAG Poisoning, de OWASP RAG Security Cheat Sheet en de AWS Prescriptive Guidance over data in generatieve AI.