Toegangsrechten in RAG: wie mag welke bedrijfskennis terugvinden?

Beschrijf gebruikers en informatiegrenzen

Begin met rollen die in het werk herkenbaar zijn. Denk aan een medewerker, een teambeheerder en een externe klantgebruiker. Beschrijf vervolgens welke informatie iedere rol voor welke taak nodig heeft. Alleen een lijst rollen is onvoldoende wanneer dezelfde rol binnen verschillende klanten of vestigingen wordt gebruikt. De organisatie- en recordgrens moet dan apart worden vastgelegd.

Een fictief adviesbureau beheert documenten voor meerdere opdrachtgevers. Twee projectmedewerkers hebben dezelfde functietitel maar mogen verschillende dossiers zien. Een zoekopdracht met dezelfde woorden moet daarom niet noodzakelijk dezelfde passages opleveren. Gebruik zulke verschillen als concrete ontwerpvoorbeelden. Daarmee wordt duidelijk welke context de applicatie betrouwbaar moet kennen voordat zij informatie selecteert.

Onderscheid connectorrechten en gebruikersrechten

Een technische verbinding kan toestemming hebben om een verzameling documenten te verwerken. Die bevoegdheid dient een ander doel dan het recht van een eindgebruiker om een specifieke bron te lezen. Leg beide apart vast. Anders kan een brede import onbedoeld veranderen in een brede publicatie zodra de toepassing antwoorden begint te formuleren.

Vraag bij iedere connector hoe oorspronkelijke rechten beschikbaar komen en hoe wijzigingen worden doorgegeven. Bij sommige bronnen is aanvullende registratie of een eigen selectie nodig. Neem geen automatische overname van bestaande rechten aan zonder controle in de gekozen combinatie van bron en platform. Het voorstel moet expliciet maken wat wordt afgedwongen, wat nog onderzocht wordt en welke bronnen voorlopig buiten de toepassing blijven.

OWASP: Authorization Cheat Sheet ↗

Selecteer toegestane bronnen vóór antwoordgeneratie

Ontwerp de zoekstap zo dat zij alleen passages teruggeeft die voor de vastgestelde gebruiker en taak zijn toegestaan. Een instructie aan het taalmodel om vertrouwelijke informatie niet te tonen is geen vervanging voor die selectie. Wanneer verboden inhoud al in de antwoordcontext staat, is de beoogde informatiegrens op een belangrijk punt al gepasseerd.

Maak de controle ook onafhankelijk van de formulering van de vraag. Een gebruiker die een andere naam, documentreferentie of organisatie in zijn vraag noemt, krijgt daarmee geen extra rechten. De applicatie moet de relevante identiteit en context uit een vertrouwde route vaststellen. Leg vast hoe de zoekvoorziening reageert wanneer die informatie ontbreekt of niet betrouwbaar kan worden gecontroleerd.

Bij toegang via een portaal gelden grenzen per organisatie en record. Deze gids werkt die afbakening verder uit: Rollen en toegangsrechten in een klantportaal: wie mag welk dossier gebruiken?.

OWASP: Authorization Cheat Sheet ↗OWASP GenAI: Prompt Injection ↗

Geef citaten dezelfde toegangsgrens als antwoorden

Een antwoord kan keurig begrensd lijken terwijl een bronlink, titel of voorvertoning toch gegevens van een ander dossier toont. Beoordeel daarom het hele zichtbare resultaat. Denk aan citaten, paginanummers, bronlabels, voorgestelde vervolgvragen en meldingen over documenten die wel of niet gevonden zijn. Elk onderdeel kan meer onthullen dan de ontwikkelaar bij alleen antwoordtekst beoordeelt.

Test ook het openen van een bron. Een gevonden passage verwijzen naar een onbeveiligde kopie maakt de oorspronkelijke controle zinloos. Als een link naar het eigen bronsysteem leidt, moet de gebruiker daar passende toegang behouden. Laat de interface duidelijk maken wanneer een bron niet geopend kan worden, zonder tegelijk onnodige details uit die bron prijs te geven.

Houd gesprekken en caches binnen de juiste context

Een antwoordcache kan verwerking versnellen, maar moet passen bij de informatiegrens. Dezelfde vraag van twee gebruikers kan verschillende toegestane bronnen hebben. Een cache die uitsluitend op vraagtekst wordt hergebruikt kan dan een antwoord uit de verkeerde context teruggeven. Spreek af welke gebruikers- en bronversiecontext bij hergebruik nodig is en wanneer eerder materiaal ongeldig wordt.

Ook gesprekshistorie verdient aandacht. Een medewerker kan van klantdossier wisselen of een gesprek delen met een collega. Onderzoek welke eerdere passages daarna nog beschikbaar zijn. Het doel is niet iedere geschiedenis weg te gooien, maar een bewuste regel voor hergebruik, delen en vervallen. Die regel moet in de feitelijke applicatie worden uitgevoerd en met realistische overgangen worden getest.

Maak intrekken een normale gebruikssituatie

Rechten blijven niet gelijk. Een medewerker wisselt van team, een externe gebruiker verlaat een project of een bron wordt tijdelijk vertrouwelijk gemaakt. Leg vast hoe snel zo'n wijziging in zoeken, antwoorden en opgeslagen materiaal moet doorwerken. Een controle die alleen tijdens de eerste import klopt, is onvoldoende voor een toepassing die dagelijks wordt gebruikt.

Bereid een proef voor waarin iemand eerst toegang heeft en die later verliest. Controleer nieuwe vragen, oude bronlinks en eventueel hergebruik van antwoorden. Maak onderscheid tussen wat technisch direct wordt ingetrokken en wat door synchronisatie vertraagd kan zijn. Als de beoogde verwerking niet snel genoeg is, moet het ontwerp een andere grens of tijdelijke blokkade kunnen toepassen.

Gebruik een gerichte matrix met negatieve proeven

Maak voor de pilot een kleine matrix van gebruiker, brongebied en handeling. Noteer niet alleen wat mag, maar ook wat expliciet geweigerd moet worden. Een externe gebruiker kan bijvoorbeeld een projecthandleiding lezen maar geen interne evaluatienotities. Dezelfde vraag moet in beide rollen worden geprobeerd, met dezelfde woorden en met een directe verwijzing naar het verboden document.

Voeg een onbekende gebruiker en een niet-beschikbare rechtenbron toe. Een nuttige proef kijkt niet alleen of toegang bij normale werking klopt, maar ook hoe de toepassing reageert op ontbrekende context. Bewaar de uitkomsten en de verwachte grens als herhaalbare gevallen. Daardoor kan een latere connector- of indexwijziging aan dezelfde afspraken worden getoetst.

OWASP: Authorization Cheat Sheet ↗

Beperk onderzoeksmateriaal en foutregistratie

Voor diagnose zijn een bronreferentie, taakcontext en foutsoort vaak nuttiger dan een volledige kopie van ieder gesprek. Bepaal welke gegevens echt nodig zijn om een toegangsprobleem te onderzoeken en wie die registratie mag lezen. Anders kan een goed begrensde gebruikersinterface alsnog een brede verzameling gevoelige informatie in een logomgeving laten ontstaan.

Maak onderzoek uitvoerbaar met herkenbare referenties en een verantwoordelijke. Een melding dat een bron ten onrechte beschikbaar was moet kunnen leiden tot tijdelijk uitschakelen, gericht onderzoek en een nieuwe controle. Schrijf ook op hoe gebruikers een probleem kunnen melden. Een technisch ontwerp zonder bereikbare eigenaar laat onduidelijkheid over wie daadwerkelijk kan ingrijpen.

Lever een aantoonbaar rechtenontwerp op

Een bruikbare oplevering bevat de gebruikersmatrix, gebruikte identiteitscontext, bronselectieregels, afspraken over intrekking en de resultaten van de afgesproken proeven. Maak daarbij onderscheid tussen aangetoonde werking en onderdelen die aanvullend onderzoek vragen. Een reeks geslaagde pilotgevallen bewijst niet dat elke mogelijke aanval of broncombinatie is afgedekt.

Plan herbeoordeling bij nieuwe brongebieden, externe gebruikers of een andere manier van delen. Zulke uitbreidingen kunnen de informatiegrens veranderen, ook wanneer het chatvenster er hetzelfde blijft uitzien. Door rechten als een beheerd onderdeel van de toepassing te behandelen, blijft uitbreiding een bewuste projectkeuze met controleerbare afspraken over wie welke bedrijfskennis kan gebruiken.

Van uitleg naar een concrete projectkeuze

Leg je aannames, open vragen en oplevercriteria vast in de bijbehorende tool. Gebruik de dienstengidsen om uitvoering en afbakening te bespreken.

• RAG Systeem Laten Bouwen ↗
• AI Knowledge Base ↗

Vragen over dit onderwerp

Verder met een aansluitende vraag