Een gebruiker krijgt in SharePoint een melding ‘Access denied’, maar ontvangt via de bedrijfschatbot toch een samenvatting van hetzelfde document. Dat is geen hallucinationprobleem. De chatbot heeft dan waarschijnlijk echte informatie ontvangen die te breed, te vroeg of op basis van verouderde rechten werd opgehaald.

De kern van RAG toegangscontrole is eenvoudig: een taalmodel mag geen document, chunk of toolresultaat ontvangen waarvoor de aanvragende gebruiker geen toestemming heeft. Toegangscontrole hoort daarom vóór en tijdens retrieval plaats te vinden, niet pas wanneer de LLM al context heeft gekregen.

Dat is essentieel voor enterprise RAG beveiliging. Een vectorzoekmachine bepaalt welke informatie semantisch relevant is. Zij weet niet automatisch welke informatie een specifieke gebruiker mag zien. Relevantie is geen autorisatie.

RAG maakt een tweede autorisatielaag noodzakelijk

Een traditionele applicatie controleert rechten meestal wanneer een gebruiker een bron raadpleegt. Denk aan een document in SharePoint, een pagina in Confluence, een ticket in Jira of een record in een CRM-systeem.

Een RAG-pipeline werkt anders. Ze maakt een afgeleide representatie van die brondata:

Brondata
→ extractie
→ chunking
→ embeddings
→ vectorindex
→ retrieval
→ reranking
→ context voor de LLM
→ antwoord, cache of tool call

In elke stap kunnen toegangsrechten verloren gaan, verkeerd worden vertaald of verouderen. Een embedding bevat immers vooral een wiskundige representatie van inhoud en semantische gelijkenis. Zonder aanvullende metadata bevat die embedding geen betrouwbare informatie over wie de inhoud mag raadplegen.

Daarom is toegang tot de chatbot op zich onvoldoende. Ook toegang tot de index is onvoldoende. De relevante vraag is steeds:

Mag deze gebruiker deze specifieke informatie op dit moment ophalen en gebruiken?

Dat is document-level access control: toegangscontrole per document, record, sectie of chunk.

Wat is authorization drift?

Authorization drift is de afwijking tussen de actuele toegangsrechten in het bronsysteem en de rechten die een RAG-systeem tijdens retrieval toepast.

Een realistisch voorbeeld:

  1. Een medewerker is lid van de groep hr-management.
  2. HR-documenten worden geïndexeerd met die groepsinformatie als metadata.
  3. De medewerker verlaat de groep of verandert van functie.
  4. SharePoint trekt de toegang onmiddellijk in.
  5. De vectorindex wordt pas uren later bijgewerkt.
  6. De RAG-assistent zoekt nog met de oude groepsmetadata.
  7. De medewerker ontvangt alsnog informatie uit een vertrouwelijk HR-document.

De bronbeveiliging hoeft in dit scenario niet defect te zijn. Het probleem zit in de afgeleide RAG-laag die een verouderde kopie van het autorisatiemodel vertrouwt.

Authorization drift kan ontstaan tussen verschillende componenten:

  • het bronsysteem en de ingestielaag;
  • documentrechten en chunkmetadata;
  • identity claims en retrievalfilters;
  • de index en een centrale autorisatieservice;
  • retrieved context en caches;
  • retrievalrechten en rechten voor acties via tools.

Voor security managers is dit een belangrijk onderscheid. Een RAG-assistent is niet alleen een interface op bestaande data. Hij vormt een nieuwe toegangsketen die zelfstandig beveiligd, gemonitord en getest moet worden.

Hoe kan een chatbot meer zien dan de gebruiker?

Er zijn een aantal terugkerende oorzaken van RAG data leakage.

ACL-metadata gaat verloren tijdens ingestie of chunking

Een document kan correcte rechten hebben in het bronsysteem, maar tijdens parsing of chunking zijn ACL-metadata verliezen. Het resultaat is dan een chunk zonder tenant-ID, classificatie of lijst met toegestane groepen.

Dit gebeurt bijvoorbeeld wanneer een document opnieuw wordt geïndexeerd zonder volledige metadata, wanneer PDF-extractie de parent-relatie niet bewaart, of wanneer afzonderlijke secties andere gevoeligheidsniveaus hebben dan het oorspronkelijke document.

Daarom moet iedere chunk minimaal kunnen worden gekoppeld aan:

  • een stabiele bron-ID;
  • het parent-document;
  • een tenant-ID;
  • classificatie en relevante attributen;
  • gebruikers-, groeps- of beleidsinformatie;
  • de versie en timestamp van de laatste rechtencontrole.

Een document-ID op indexniveau is niet genoeg wanneer de retrievallaag op chunks zoekt en chunks afzonderlijk naar een LLM stuurt.

Rechten in de index zijn verouderd

Rechten veranderen vaker dan de inhoud van documenten. Een medewerker wisselt van afdeling, een externe consultant verliest toegang, een project wordt afgesloten of een document wordt verwijderd.

Een nachtelijke synchronisatie kan aanvaardbaar zijn voor publieke kennisbanken. Voor HR-dossiers, klantdata, juridische documenten, financiële informatie of security-incidenten is dat vaak onvoldoende.

Maak daarom expliciet onderscheid tussen content freshness en permission freshness. Een document kan inhoudelijk onveranderd zijn, maar toch onmiddellijk een nieuwe autorisatiebeslissing vereisen.

Groepsrechten worden verkeerd vertaald

Complexe rechten zijn zelden beperkt tot één rol. Denk aan nested groups, uitzonderingen, expliciete deny-regels, projectlidmaatschappen, regionale beperkingen of klantrelaties.

Veel implementaties gebruiken bovendien display names in plaats van onveranderlijke identity-ID’s. Dat verhoogt het risico op foutieve mappings. Ook een gedeelde link of publiek document binnen één omgeving wordt soms onterecht vertaald naar brede toegang binnen de volledige index.

De client bepaalt het filter

Een retrieval-API die de frontend laat bepalen welke tenant, rol of groep geldt, creëert een directe aanvalsmogelijkheid. Dit is onveilig:

{
  "tenant_id": "acme",
  "role": "administrator"
}

De gebruiker, browser of LLM mag deze waarden niet als autoritatieve claims kunnen aanleveren. De backend moet identiteit, tenant, groepen en attributen afleiden uit een gevalideerd token of een vertrouwde identity provider.

Context of antwoorden worden verkeerd gecachet

Een antwoord voor gebruiker A mag niet hergebruikt worden voor gebruiker B omdat de vraag sterk lijkt. Ook contextcaches kunnen tot datalekken leiden wanneer ze niet worden gekoppeld aan de effectieve rechten van de gebruiker.

Een veilige cache is minstens gescoped op:

  • tenant;
  • gebruiker of entitlement-set;
  • policyversie;
  • index- en documentversie;
  • query- en modelversie;
  • gevoeligheidsniveau.

Bij een intrekking van rechten moeten relevante caches ongeldig worden gemaakt.

Waarom filtering achteraf niet genoeg is

Een veelvoorkomend patroon is:

Query
→ vector search over alle documenten
→ top-k resultaten
→ filter toegestane resultaten
→ LLM

Dit lijkt efficiënt, maar is voor gevoelige data geen betrouwbare primaire beveiligingsgrens.

Ten eerste kunnen de best scorende resultaten volledig ongeautoriseerd zijn. Als die achteraf worden verwijderd, blijven mogelijk geen goede toegestane resultaten over. Dat schaadt niet alleen de security, maar ook de kwaliteit van het antwoord.

Ten tweede hebben applicaties, rerankers, logging- en tracingcomponenten de ongeautoriseerde inhoud mogelijk al verwerkt voordat de filter wordt toegepast. Een fout in een vervolgcomponent kan dan alsnog tot lekken leiden.

Ten derde kunnen retrievalscores, aantallen resultaten of foutmeldingen indirect informatie onthullen over het bestaan van gevoelige documenten.

Het voorkeursmodel is daarom:

Gebruikersvraag
→ gevalideerde identiteit en claims
→ policybeslissing
→ security-aware retrievalfilter
→ vector search binnen toegestane scope
→ reranking van toegestane resultaten
→ contextconstructie
→ LLM

Post-filtering blijft nuttig als extra verdedigingslaag, zeker bij complexe uitzonderingen of relationele rechten. Maar het mag niet de enige controle zijn als ongeautoriseerde kandidaten al door andere componenten kunnen worden verwerkt.

Retrieval-time authorization als primaire grens

Retrieval-time authorization betekent dat het systeem opnieuw beslist welke resources een gebruiker mag ophalen op het moment van de vraag.

Dat kan op verschillende manieren.

Metadatafiltering voor eenvoudige en stabiele rechten

Voor relatief eenvoudige scenario’s kan server-side filtering op metadata voldoende zijn. Bijvoorbeeld:

tenant_id = current_user.tenant_id
AND classification <= current_user.clearance
AND (
  is_public = true
  OR current_user.id IN allowed_users
  OR current_user.group_ids OVERLAP allowed_groups
)

Dit werkt goed voor vaste tenantgrenzen, afdelingen, classificatieniveaus, regio’s en interne versus publieke content. De voorwaarden zijn wel streng: metadata moet volledig, correct, beschermd tegen manipulatie en voldoende actueel zijn.

ABAC voor RAG bij multidimensionale rechten

Bij role-based access control krijgt een gebruiker toegang op basis van een rol, zoals legal-team of finance-manager. In enterpriseomgevingen is dat vaak te beperkt.

ABAC voor RAG gebruikt meerdere attributen van de gebruiker, het document en de context. Bijvoorbeeld:

Toestaan wanneer:
- user.tenant_id gelijk is aan document.tenant_id
- user.department gelijk is aan document.department
- user.region gelijk is aan document.region
- user.clearance voldoende is voor document.classification

ABAC is bijzonder relevant wanneer toegang afhankelijk is van project, klant, locatie, contracttype, dossierrelatie of tijdstip. Het helpt om het feitelijke bedrijfsbeleid beter te vertalen naar de retrievallaag.

Centrale autorisatieservice voor complexe relaties

Wanneer rechten voortkomen uit veel relaties en uitzonderingen, kan een centrale policy decision point of fine-grained authorization-service geschikter zijn dan uitsluitend indexmetadata.

De retrievalservice vraagt dan bijvoorbeeld: ‘Mag gebruiker 42 document 123 lezen?’ Of zij bepaalt vooraf welke documentenset voor die gebruiker toegankelijk is.

Een hybride model is in de praktijk vaak het meest werkbaar:

  1. Gebruik indexmetadata voor snelle pre-filtering op tenant, regio en classificatie.
  2. Controleer gevoelige documenten, uitzonderingen en recente intrekkingen bij de bron of een centrale policyservice.
  3. Verwerk revocations event-driven.
  4. Voer periodieke reconciliatie uit tussen bronrechten en indexmetadata.
  5. Weiger toegang wanneer de autorisatie niet betrouwbaar kan worden vastgesteld.

Fail closed is hier cruciaal. Als de policyservice niet beschikbaar is, mag de oplossing niet terugvallen op een ongefilterde vector search.

Een veilige RAG-keten in de praktijk

Een robuuste architectuur volgt deze volgorde:

Gebruiker
→ API/backend met gevalideerde identiteit
→ autorisatie- of policylaag
→ search binnen toegestane scope
→ reranker met uitsluitend toegestane kandidaten
→ context builder en citation validation
→ LLM
→ outputcontrole en toolautorisatie

Daarbij zijn vijf ontwerpregels bijzonder belangrijk.

1. Geef identiteit betrouwbaar door

Gebruik gevalideerde tokens en controleer onder meer issuer, audience, handtekening en vervaldatum. Log zowel de oorspronkelijke gebruiker als de technische service die de query uitvoert.

Een breed service account zonder on-behalf-of-context ondermijnt document-level access control. De database of vectorstore ziet dan alleen een technisch account met te ruime rechten.

2. Beperk reranking en context tot toegestane chunks

Een reranker is geen neutrale stap. Als hij restricted documenten verwerkt, kunnen die documenten in logs, state of cache terechtkomen. Laat rerankers daarom alleen werken op kandidaten die vooraf al binnen de toegestane scope vallen.

Controleer bovendien vóór contextconstructie opnieuw dat elke chunk een geldige autorisatiebeslissing heeft en dat citaties niet verwijzen naar bronnen die de gebruiker niet mag openen.

3. Behandel retrieved documenten als data, niet als instructies

Autorisatie voorkomt niet dat een geautoriseerd document kwaadaardige instructies bevat. Indirecte prompt injection kan een model proberen te beïnvloeden via tekst in een opgehaald document.

Markeer retrieved content daarom expliciet als onbetrouwbare data. Beperk welke tools een agent kan aanroepen, valideer toolparameters server-side en laat de LLM nooit zelfstandig haar eigen rechten wijzigen.

4. Autoriseer tools afzonderlijk

Leestoegang is geen schrijfrecht. Een gebruiker die een ticket mag bekijken, mag niet automatisch een ticket aanpassen. Iemand die HR-beleid mag lezen, mag niet zonder meer persoonsgegevens exporteren of documenten extern versturen.

Iedere tool call vereist daarom een afzonderlijke policybeslissing op basis van gebruiker, actie, resource en context.

5. Maak de permission freshness meetbaar

Definieer een expliciete SLA voor rechten. Bijvoorbeeld: groepswijzigingen binnen vijf minuten verwerkt, high-risk revocations onmiddellijk verwerkt en verwijderde documenten binnen een vastgelegde termijn niet meer retrievable.

Meet minstens:

  • het percentage chunks met geldige ACL-metadata;
  • de tijd tussen bronwijziging en indexupdate;
  • de tijd tussen revocation en blokkade bij retrieval;
  • retrievals zonder policybeslissing;
  • cross-tenant retrievalpogingen;
  • cache-hits buiten dezelfde entitlement-scope;
  • antwoorden met uitsluitend geautoriseerde citaties.

Checklist voor RAG toegangscontrole

Gebruik deze vragen bij architectuurreviews, security assessments en productbeslissingen:

  • Is duidelijk welk systeem autoritatief is voor toegangsrechten?
  • Heeft iedere chunk een tenant-ID en voldoende ACL- of ABAC-metadata?
  • Worden identity claims uitsluitend uit vertrouwde tokens of identity providers afgeleid?
  • Worden securityfilters server-side afgedwongen?
  • Kan de client, prompt of LLM de filtervoorwaarden beïnvloeden?
  • Wordt de vector search uitgevoerd binnen de toegestane scope?
  • Komen ongeautoriseerde kandidaten ooit in reranking, logging, tracing of caches terecht?
  • Hoe snel worden groepswijzigingen, verwijderingen en intrekkingen verwerkt?
  • Wat gebeurt er wanneer de autorisatieservice niet beschikbaar is?
  • Zijn negatieve tests voor cross-tenant toegang, verlopen tokens en recente revocations geautomatiseerd?

Deze vragen sluiten aan bij bredere security governance. Wie AI-systemen inzet voor operationele of risicogevoelige processen, moet toegangscontrole behandelen als een continu beheersvraagstuk, niet als een eenmalige configuratie. Dat geldt ook voor organisaties die hun bredere aanpak rond security en risk controls verder professionaliseren.

FAQ

Is metadatafiltering voldoende voor RAG security?

Metadatafiltering kan voldoende zijn voor eenvoudige, stabiele toegangsmodellen, bijvoorbeeld tenantisolatie, vaste groepsrechten of classificatieniveaus. Het is minder geschikt als enige control bij dynamische rechten, nested groups, relationele toegang, expliciete deny-regels of strenge eisen voor onmiddellijke revocation.

Wat is het verschil tussen pre-filtering en post-filtering?

Bij pre-filtering zoekt het systeem alleen binnen documenten die de gebruiker mag zien. Bij post-filtering zoekt het eerst breed en verwijdert het daarna ongeautoriseerde resultaten. Pre-filtering beperkt het risico dat restricted content door rerankers, logs of caches wordt verwerkt. Post-filtering is vooral een aanvullende controle.

Moet elke vectorchunk eigen toegangsmetadata hebben?

Ja, wanneer retrieval op chunkniveau plaatsvindt. Elke chunk moet ten minste kunnen worden gekoppeld aan het parent-document, de tenant, relevante autorisatieattributen en de actuele status van de rechten. Anders kan de retrievallaag niet betrouwbaar beslissen of die specifieke tekst naar de LLM mag.

Lost een system prompt het probleem op?

Nee. Een prompt die het model verbiedt vertrouwelijke informatie te delen, is geen security boundary. Als de LLM de content al heeft ontvangen, kan zij die verkeerd samenvatten, indirect onthullen of verwerken in een ongewenste tool call. Autorisatie moet gebeuren voordat context aan het model wordt gegeven.

Zijn aparte vectorindices per tenant altijd nodig?

Niet altijd. Een gedeelde index kan veilig zijn als tenantfilters verplicht en server-side worden afgedwongen. Voor harde grenzen, zoals verschillende klanten, nationale jurisdicties, legal privilege of export-controlled data, kunnen aparte indices, namespaces of infrastructuurgrenzen wel de blast radius verkleinen.

Conclusie

Een veilige RAG-assistent moet niet vooral goed kunnen weigeren. Hij moet vooral voorkomen dat ongeautoriseerde informatie ooit in zijn context terechtkomt.

Authorization drift ontstaat wanneer bronrechten, indexmetadata en runtimebeslissingen uit elkaar gaan lopen. De oplossing is geen extra promptregel, maar een security-aware retrievalketen waarin identiteit, actuele rechten, tenantisolatie, cachevalidatie en toolautorisatie samenkomen.

Voor organisaties die RAG van pilot naar productie brengen, is de belangrijkste controlevraag daarom niet of het model een ongewenst antwoord kan weigeren. De vraag is: kan een gebruiker ooit een chunk ophalen die hij in het bronsysteem niet mag openen?

STARLABS Consulting helpt organisaties om AI-, data- en securityarchitectuur met die vraag als uitgangspunt te beoordelen en te versterken.