Eén kwaadaardig document kan een RAG-systeem vergiftigen

U moet uw kennisbank op twee niveaus tegelijk verdedigen: controleer elk document op herkomst en integriteit voordat het wordt geïndexeerd, en monitor vervolgens de vectorindex en het retrievalgedrag om te voorkomen dat vervuilde passages het antwoord bereiken.

Een analyse van 3 november 2026 van praktische vergiftigingsaanvallen op retrieval-augmented generation stelt dat één zorgvuldig vervaardigd kwaadaardig document volstaat om een RAG-assistent misleidende antwoorden te laten geven. Het onderzoek demonstreert dit met CorruptRAG, een aanval waarbij slechts één vervuild document wordt ingespoten. In onze beoordeling betekent dit dat de aanname — dat een enkele foute upload zal verdrinken in de rest van de kennisbank — niet meer houdbaar is. Elke organisatie die interne documenten door zo'n assistent laat doorzoeken, moet ervan uitgaan dat één document volstaat om schade aan te richten.

Waarom één document genoeg is

De CorruptRAG-aanval werkt omdat een aanvaller niet honderden valse stukken hoeft in te spuiten. Een enkele, goed voorbereide tekst kan al voldoende zijn om de antwoorden van het systeem te sturen. Dit maakt de aanvalsvector praktisch: een aanvaller heeft slechts één mogelijkheid nodig om inhoud in de kennisbank of ingestiepijplijn te plaatsen. Dat kan gebeuren via een gecompromitteerde bron, een onvoldoende gecontroleerde upload, of een zwakke plek in de integratiepijplijn.

De werkelijke schade ontstaat niet in het document alleen, 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.

Hoe configuratie uw blootstelling bepaalt

Een tweede onderzoek, Influence Factors on RAG Poisoning, testte 432 verschillende configuraties. Daaruit bleek dat de kans dat een vervuilde passage daadwerkelijk wordt opgehaald en het antwoord beïnvloedt, samenhangt met vier factoren: 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 de kans dat vervuilde passages worden opgehaald.

Dit betekent dat uw systeem niet universeel kwetsbaar is. Hoe kwetsbaar uw opstelling is, hangt af van uw eigen configuratie. Een configuratiekeuze zoals top-k is daarom niet alleen een ontwikkelingsbesluit; het raakt rechtstreeks uw securityrisico en hoort thuis in het risicodossier van het systeem.

Welke controles moet u kunnen aantonen

1. Documentherkomst vastleggen — registreer voor elk document wie het heeft geüpload, wanneer, en van welke bron het afkomstig is voordat indexering plaatsvindt.
2. Integriteit met hash controleren — bereken en bewaar een cryptografische hash van elk document en verifieer deze voordat het wordt verwerkt.
3. Vectorindex en embeddings monitoren — volg mutaties in de vectorindex en controleer of embeddings onverwachte verschuivingen vertonen.
4. Retrievalgedrag traceren — registreer welke passages worden opgehaald en in welke volgorde, zodat u kunt zien welke documenten het antwoord beïnvloeden.
5. Systeem stoppen bij integriteitsfouten — zorg dat het systeem geen antwoorden genereert wanneer een controle faalt, in plaats van stilletjes terug te vallen op trainingskennis.

Wat een hash wel en niet bewijst

Een overeenkomende hash bewijst dat een document gelijk is aan een goedgekeurde versie. Het bewijst niet dat de inhoud juist of veilig is. Herkomst en integriteit zijn iets anders dan waarheid. Dit onderscheid is cruciaal voor wie RAG-antwoorden moet gebruiken in besluitvorming: een jurist mag een antwoord niet als geverifieerd behandelen zonder bronattributie met documenthash. 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 u moet organiseren

Praktisch samengevat, in volgorde van invoering: zorg dat elke indexering een vastgelegde herkomst, goedkeuring en hash kent voordat een document doorgaat; maak budget vrij voor monitoring van indexmutaties en retrievalgedrag, niet alleen voor uploadcontrole; zorg dat configuratiekeuzes zoals top-k in het risicodossier van het systeem staan; en leg vast dat antwoorden zonder traceerbare bron niet worden gebruikt in besluitvorming.

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. Een intern herkomstdossier bewijst geen juistheid, maar het levert wel traceerbaarheid — en dat is wat u nodig hebt om te weten wat er is gebeurd wanneer iets misgaat.