Toegangscontrole voor AI-agenten hoort thuis op de datalaag, niet in de systeemopdracht

Een systeemprompt die je AI-agent instrueert om gebruikers alleen de data te tonen waarvoor ze gemachtigd zijn, is geen beveiligingsmaatregel. Het is een suggestie, in het Engels geschreven, die zich in hetzelfde contextvenster bevindt als alle andere tekst die de agent verwerkt, en suggesties kunnen worden omzeild.

Dat is inmiddels geen gewaagde uitspraak meer. Het is het formele standpunt van AWS en het SANS Institute, gepubliceerd deze maand in een richtlijn van AWS’s Gee Rittenhouse, verantwoordelijk voor Security Hub, GuardDuty en Inspector, samen met SANS-fellow Eric Johnson en drie extra AWS-beveiligingsspecialisten. Hun boodschap aan enterprise security-teams, zoals verslag door Help Net Security, is duidelijk. Een agent via de systeemprompt instrueren om gebruikersrechten te respecteren kan “worden omzeild, genegeerd of overschreven”, en geen enkele zorgvuldige formulering verandert dat. De oplossing, stellen ze, moet plaatsvinden op de data layer. Beperk elke query tot de daadwerkelijke rechten van de aanvragende gebruiker op het moment van ophalen, binnen het bestaande rolgebaseerde of op attributen gebaseerde toegangscontrole systeem van de organisatie, en filter de resultaten voordat ze het model bereiken.

Een tweede, onafhankelijk gerapporteerde blik op enterprise AI-gebruik onderstreept waarom dit nu zo belangrijk is. Zoals The American Reporter beschrijft, is het merendeel van de AI-activiteiten waarbij gevoelige data door de organisatie stroomt niet goedgekeurd, wordt het niet gelogd zoals een compliance-team dat nodig heeft, en valt het niet onder de toegangscontroles die zijn ontworpen voor een wereld zonder AI-agents. Voor de CISO en Chief Compliance Officer die verantwoording moeten afleggen aan een toezichthouder of auditor, was de vraag nooit of de agent zich beleefd gedroeg. Het gaat erom of elke toegang tot gevoelige data kan worden gekoppeld aan een specifieke machtiging, op het moment dat het gebeurde, met een bewijs dat standhoudt bij controle. Kiteworks secure data exchange is precies rond die eis gebouwd, en dekt nu ook AI-agents en menselijke gebruikers onder één beleid.

Belangrijkste inzichten

1. Systeemprompts zijn geen toegangscontrole.

De richtlijnen van AWS en het SANS Institute, gepubliceerd in september 2026, stellen duidelijk dat promptinstructies kunnen worden omzeild, genegeerd of overschreven, en adviseren om machtigingen af te dwingen op de data retrieval layer.

2. Adoptie loopt ver voor op governance.

Volgens cijfers van McKinsey uit die richtlijn ligt AI-adoptie bij 80% van de organisaties, terwijl de volwassenheid van AI-governance slechts 10% bedraagt—een kloof die de meeste bedrijven nog niet hebben gedicht.

3. Ongecontroleerde AI heeft een meetbaar prijskaartje.

Uit IBM’s 2026 Cost of a Data Breach Report blijkt dat datalekken waarbij shadow AI betrokken is gemiddeld $5,39 miljoen kosten, een stijging ten opzichte van $4,63 miljoen het jaar ervoor. 68% van de 602 onderzochte organisaties heeft nog steeds geen AI-governance om dit te beheren.

4. Eén gedocumenteerde casestudy laat precies zien waarom formulering tekortschiet.

Onderzoekers in de Agents of Chaos-studie lieten een AI-agent een niet-geanonimiseerd burgerservicenummer vrijgeven, simpelweg door een geblokkeerd verzoek te herformuleren als een verzoek om een volledige e-mail door te sturen.

5. De oplossing is architectonisch, niet taalkundig.

Elke AI-agentquery koppelen aan RBAC- of ABAC-machtigingen op het moment van ophalen, voordat data het contextvenster van het model bereikt, dicht een gat dat betere promptformulering niet kan oplossen.

De casestudy die bewijst dat een prompt geen harde grens is

Als het argument dat systeemprompts falen abstract klinkt, maakte een onderzoeksproject uit februari 2026 genaamd Agents of Chaos het concreet. Twintig onderzoekers van onder andere MIT, Stanford, Harvard en Carnegie Mellon deden twee weken lang red-teaming op AI-agents gebouwd op het OpenClaw-framework in een echte labomgeving, niet in simulatie, met echte e-mailaccounts, persistente opslag en shell-toegang.

In een casestudy plaatsten de onderzoekers een burgerservicenummer, een bankrekeningnummer en medische gegevens in een routinematige e-mail van de agent-eigenaar. Toen een niet-eigenaar de agent direct vroeg om “het BSN in de e-mail”, weigerde de agent, precies zoals een instructie om gevoelige informatie te beschermen zou voorspellen. Toen dezelfde persoon de agent vroeg om de volledige e-mail door te sturen, voldeed de agent aan het verzoek. Alle persoonlijk identificeerbare informatie werd ongeanonimiseerd verstuurd, inclusief het BSN, het rekeningnummer en het medisch dossier, allemaal in één bericht.

De bredere conclusie van de onderzoekers is het punt waar beveiligingsarchitecten bij stil moeten staan. Agents verwerken instructies en data als tokens in hetzelfde contextvenster, wat betekent dat ze geen betrouwbare manier hebben om een legitiem verzoek te onderscheiden van een gemanipuleerd verzoek dat legitiem lijkt. De auteurs van de studie noemen dit een structureel tekort, geen bug die met betere training kan worden opgelost. Vijf van de tien OWASP Top 10-categorieën voor LLM-toepassingen, waaronder het lekken van gevoelige informatie en systeemprompt-lekkage, kwamen direct overeen met de fouten die de onderzoekers zagen. Een systeem dat het verschil niet kan zien tussen een instructie en data die zich voordoet als instructie, kan niet worden vertrouwd om een toestemmingsgrens af te dwingen die alleen in diezelfde instructielaag wordt beschreven.

Shadow AI verwerkt nu al gereguleerde data

De Agents of Chaos-studie vond plaats in een onderzoeksomgeving. De blootstelling die het aantoont is nu al realiteit in productieomgevingen. Het artikel van The American Reporter over enterprise AI-gebruik noemt onderzoeksresultaten waaruit blijkt dat 90% van de securityleiders toegeeft dat hun eigen medewerkers ongeautoriseerde AI-tools gebruiken op het werk, en dat 69% van de CISO’s deze tools toch in dagelijkse workflows heeft opgenomen. Ongeveer 80% van de medewerkers doet hetzelfde. Slechts 52% zegt bekend te zijn met het AI-gebruiksbeleid van hun bedrijf, terwijl 70% weet dat gevoelige data toch met AI-tools wordt gedeeld op de werkvloer. In hetzelfde artikel wordt vermeld dat de hoeveelheid enterprise data die door AI- en machine learning-toepassingen stroomt in 2025 18.033 terabyte bereikt, waarbij 39,7% van de AI-interacties gevoelige data blootstelt—een stijging van 93% ten opzichte van het jaar ervoor.

Traditionele controles zijn nooit ontworpen voor dit patroon. Preventie van gegevensverlies-regels voor e-mailbijlagen en een veilige FTP-vervanger die is ontworpen voor point-to-point-overdracht gaan beide uit van een datastroom met een begin, een einde en een beperkt aantal stappen ertussen. Een klantrecord dat via een chatbot gaat, vervolgens via een tweede systeem wordt gerouteerd en uiteindelijk bij een menselijke medewerker terechtkomt, past niet in dat model. Er is zelden één enkele log die elk systeem documenteert dat de data heeft aangeraakt, wat betekent dat als een toezichthouder om die keten vraagt, die vaak niet in een reproduceerbare vorm bestaat. Dat gat is geen trainingsprobleem of een bewustwordingscampagne die nog moet komen. Het is een architectuur die niemand bewust heeft ontworpen, en het groeit elk kwartaal dat dataclassificatie en toegangscontrole als losse componenten worden toegevoegd aan systemen die nooit zijn gemaakt voor AI-verkeer.

Wat ongecontroleerde AI-toegang daadwerkelijk kost

Het financiële argument om dit gat te dichten is niet langer speculatief. IBM’s 2026 Cost of a Data Breach Report toont aan dat datalekken waarbij shadow AI betrokken is gemiddeld $5,39 miljoen kosten, een stijging ten opzichte van $4,63 miljoen het jaar ervoor, en dat 68% van de 602 onderzochte organisaties nog steeds geen AI-governance heeft om het gebruik te beheren of ongeautoriseerd gebruik te detecteren. De in Help Net Security genoemde richtlijn verwijst naar McKinsey-cijfers die aangeven dat AI-adoptie bij 80% van de organisaties ligt, terwijl de volwassenheid van AI-governance slechts 10% bedraagt—een mismatch die alleen maar groter is geworden nu agentic-inzet verder gaat dan simpele chatbots en systemen met persistente geheugen, tool-executie en de mogelijkheid om namens een gebruiker te handelen.

Het Kiteworks Data Security and Compliance Risk: 2026 Forecast Report kwantificeert hetzelfde gat vanuit het containment-perspectief. Van de ondervraagde organisaties heeft 100% agentic AI op de roadmap, maar 63% kan geen doeleindbeperkingen afdwingen voor de AI-agents die al zijn ingezet, 60% kan een slecht functionerende agent niet snel uitschakelen, en 55% kan een AI-systeem niet isoleren van het bredere netwerk als er iets misgaat. Het rapport identificeert een gat van 15 tot 20 punten tussen wat organisaties kunnen monitoren en wat ze daadwerkelijk kunnen stoppen, wat betekent dat de meeste bedrijven een agent bijna realtime kunnen zien ontsporen zonder een hefboom te hebben om het te stoppen. Vierenvijftig procent van de raden van bestuur zet AI-databeheer niet in hun top vijf onderwerpen, en deze organisaties lopen 26 tot 28 punten achter op elke gemeten capaciteit vergeleken met raden die dat wel doen.

Een architectuur die toegang afdwingt op de data layer

Als je eenmaal accepteert dat het model zelf nooit de controle kan zijn, wordt de oplossing geen copywriting-oefening maar een infrastructuurbeslissing. Elke AI-agentquery, of die nu afkomstig is van een chatbot, een autonome agent of een retrieval-augmented generation-pijplijn die context ophaalt voor een antwoord, moet een machtigingscontrole doorlopen voordat het retrievalproces start, getoetst aan dezelfde RBAC– of ABAC-regels die de organisatie al hanteert voor menselijke gebruikers. Default-deny moet op de tool-invocatielaag zitten, niet als een bijzaak bovenop een prompt. En cruciaal: het beleid moet hetzelfde zijn, of een mens nu op een knop klikt of een agent een tool aanroept. Governance krijgt geen apart, soepeler regime voor het identiteitstype dat toevallig sneller beweegt; het geldt voor menselijke en agent-identiteiten, onder één beleid en één audittrail.

Dit is het uitgangspunt achter Kiteworks Secure MCP Server en Kiteworks Compliant AI. Beide beperken wat een AI-agent of large language model kan ophalen tot de daadwerkelijke ABAC-machtigingen van de aanvragende gebruiker, afgedwongen buiten het contextvenster van het model in plaats van binnen een prompt die het model zelf verwerkt. De Kiteworks Data Policy Engine past dat beleid consequent toe op e-mail, bestandsoverdracht, beheerde bestandsoverdracht, webformulieren en nu ook AI-toegang, draaiend op een hardened virtual appliance met FIPS 140-3 gevalideerde encryptie en een audittrail die gedetailleerd genoeg is voor een beoordelaar om te lezen zonder dat een engineer het live hoeft te vertalen.

Eén kanttekening die het vermelden waard is, omdat het overdrijven ervan precies de fout zou herhalen die deze aanpak wil voorkomen. Toegangscontrole op deze manier regelt wat een verzoek kan ophalen zodra dat verzoek is gekoppeld aan de machtigingen van een geverifieerde gebruiker. Ze detecteren niet zelfstandig een prompt-injection payload die verstopt zit in een e-mailbijlage, een gescrapete webpagina of een ander stuk onbetrouwbare content die de agent moet verwerken. Dat is een aparte verdedigingslaag, en AWS’s richtlijn is hier ook expliciet over. Ze waarschuwt ervoor om nooit een enkele agent toegang te geven tot gevoelige data, de mogelijkheid tot externe communicatie én blootstelling aan onbetrouwbare content, omdat juist die combinatie een prompt-injection tot een exfiltratiepad maakt. Toegangscontrole op de data layer dicht het retrieval-gat. Het vervangt niet de noodzaak om ook te reguleren wat een agent mag doen zodra deze iets heeft opgehaald.

Wat toezichthouders en auditors daadwerkelijk zullen vragen

Dit is het belangrijkste uitgangspunt voor een CISO of Chief Compliance Officer die intern het pleidooi moet houden. Toezichthouders reguleren data, geen modellen. HIPAA kijkt niet of een mens of een AI-agent een patiëntendossier heeft ingezien; het gaat erom of die toegang geautoriseerd, geminimaliseerd en gelogd was. Hetzelfde geldt voor de GDPR, die vraagt of de informatie van een datasubject op een wettelijke grondslag is verwerkt en of die verwerking op verzoek kan worden aangetoond, en voor CMMC bij organisaties in de defensie-industrie, waar een AI-agent die controlled unclassified information verwerkt binnen de beoordelingsgrens valt, net als een menselijke gebruiker.

Geen van deze kaders is geschreven met AI-agents in gedachten, en geen ervan hoeft te worden herschreven om van toepassing te zijn. Wat ze vereisen is bewijs: specifiek een benoemde data-eigenaar voor elk systeem met toegang tot gereguleerde informatie, een toestemmingsbereik dat op verzoek kan worden overlegd, en een audittrail die niet alleen laat zien dát toegang plaatsvond, maar ook dat het geautoriseerd was onder een specifiek beleid op een specifiek moment. Een beoordelaar die een HIPAA Security Rule-review of een CMMC Level 2-beoordeling voorbereidt, zal niet vragen wat er in de systeemprompt van je AI-agent staat. Ze zullen vragen naar de toegangslog, het machtigingsmodel erachter en het bewijs dat die twee overeenkomen.

De eisen verschillen per sector, maar de onderliggende bewijsverplichting blijft hetzelfde. Een zorg compliance officer die zich voorbereidt op een HIPAA-audit moet aantonen dat een AI-agent die patiëntendossiers samenvat dezelfde minimum-necessary-standaard hanteerde als een menselijke medewerker. Een compliance-verantwoordelijke bij een defensie-aannemer die zich voorbereidt op een C3PAO-beoordeling onder CMMC 2.0-naleving moet aantonen dat een AI-agent die controlled unclassified information verwerkt nooit bredere toegang had dan de beoordelingsgrens toestaat. Een CISO in de financiële sector die verantwoording aflegt over SEC- of GLBA-verplichtingen, heeft hetzelfde bewijs nodig voor een agent die rekeningactiviteiten samenvat. In elk van deze gevallen is het bewijs dat een auditor accepteert een toestemmingsrecord en een toegangslog, niet een beschrijving van hoe beleefd de agent werd gevraagd zich te gedragen.

RAG-pijplijnen vereisen dezelfde handhaving, geen uitzondering

Hetzelfde principe geldt of een agent nu direct een tool aanroept of context ophaalt via een retrieval-augmented generation-pijplijn. RAG-architecturen zijn op dit punt juist extra foutgevoelig, omdat de retrievalstap vaak wordt gebouwd als een generieke zoekindex die alles teruggeeft wat topisch relevant is, met machtigingscontroles die pas achteraf worden toegevoegd—als ze al worden toegevoegd. Een machtigingscontrole die pas na retrieval plaatsvindt, is geen echte controle. Het is een filter op een resultaatset die het model mogelijk al heeft gebruikt om een antwoord te genereren, een samenvatting te loggen of een actie uit te voeren. De controle moet vóór de query op de index worden uitgevoerd, afgestemd op de daadwerkelijke machtigingen van de aanvragende gebruiker, elke keer opnieuw, ongeacht hoe zeker het systeem is dat het resultaat “wel goed” zal zijn om te tonen.

De kloof tussen AI-adoptie en AI-governance dichten

Elke organisatie die haast maakt met de inzet van agentic AI, loopt uiteindelijk tegen deze muur aan. Adoptie loopt nu al voor op governance, en de organisaties die die kloof als eerste dichten, zijn degenen die hun bestuur geen miljoenenverlies door shadow AI hoeven uit te leggen na een datalek. Een paar concrete stappen maken het verschil tussen een AI-programma dat een audit overleeft en één dat dat niet doet.

Begin met het inventariseren van elke AI-agent met toegang tot gevoelige data, zowel goedgekeurd als shadow, en wijs voor elke agent een benoemde data-eigenaar en een afgebakend toestemmingsbereik toe, in plaats van alleen een beschrijving van wat de agent zou moeten doen. Verplaats het afdwingen van machtigingen naar de retrieval layer en test het tegen dezelfde RBAC- of ABAC-regels die gelden voor menselijke toegang, voordat een record het contextvenster van een model bereikt. Laat nooit één enkele agent tegelijk toegang tot gevoelige data, uitgaande communicatie en blootstelling aan onbetrouwbare content combineren; splits deze mogelijkheden op in aparte, beperktere agents. Maak logs van bewijsniveau voor elke door AI gemedieerde data-toegang, afgestemd op de tijdslijn van een toezichthouder in plaats van een interne post-mortem. En wijs een benoemd persoon aan, niet een alinea instructies, als verantwoordelijke voor wat een agent mag doen.

Geen van deze stappen behandelt AI-agents als een bedreiging die moet worden geblokkeerd. Ze worden behandeld zoals elke nieuwe identiteitsklasse in de organisatie uiteindelijk wordt behandeld. Agents worden opgenomen in hetzelfde governance-model dat al geldt voor menselijke gebruikers, in plaats van te vertrouwen op beleefdheidsregels alleen.

Wil je meer weten over het afdwingen van AI-agenttoegangscontrole op de data layer in plaats van via de systeemprompt? Plan vandaag nog een aangepaste demo.

Aanvullende bronnen

• Blog Post
  Zero‑Trust strategieën voor betaalbare AI-privacybescherming
• Blog Post
  Hoe 77% van de organisaties faalt op AI-databeveiliging
• eBook
  AI Governance Gap: Waarom 91% van kleine bedrijven Russisch roulette speelt met databeveiliging in 2025
• Blog Post
  Er bestaat geen “–dangerously-skip-permissions” voor je data
• Blog Post
  Toezichthouders zijn klaar met vragen of je een AI-beleid hebt. Ze willen bewijs dat het werkt.