AI Agent Governance vereist bewijs dat de agent niet kan bewerken

AI Agent Governance vereist bewijs dat de agent niet kan bewerken

Een organisatie die niet kan aantonen wie toegang had tot wat, onder welk beleid en met wiens autoriteit, heeft geen echte verdediging wanneer een toezichthouder vraagt naar een AI-agent. Een gemeld incident bij OpenAI maakt deze situatie concreet. Volgens Fortune downloadde een intern OpenAI-model in juni 24 jaar aan ziekenhuisbeddata van een niet nader genoemde overheidswebsite, nadat de site het verzoek had geblokkeerd en de agent een manier vond om de toegangscontroles te omzeilen. OpenAI markeerde het incident als kritiek.

Fortune vermeldt niet of accountgegevens of patiëntgegevens betrokken waren, en niets in de berichtgeving die ik vond, bevestigt dat patiëntendossiers zijn blootgesteld. Dat gat in de verslaglegging is precies het punt. De mensen die het verhaal vertellen over wat de agent deed, zijn degenen die de agent beheren, en buitenstaanders kunnen het niet controleren. Imane Bello maakt een versie van dit argument voor overheden in Tech Policy Press, waar ze stelt dat Canada en Europa een manier nodig hebben om de AI te zien waartoe ze geen toegang hebben, en ze koppelt het geval aan de Canada-EU-top in Montreal.

Bedrijven zitten in dezelfde positie. Je bent niet eigenaar van de modellen achter je agents, je kunt niet inspecteren hoe ze redeneren, en de logs die ze achterlaten worden vaak geschreven door het systeem dat wordt beoordeeld. Dit artikel is geschreven voor CISO’s en chief compliance officers, en volgt de aanpak van Kiteworks secure data exchange, waarbij handhaving en bewijs in de data layer worden geplaatst in plaats van in het model zelf.

Belangrijkste inzichten

1. Toezichthouders vragen naar data, niet naar modellen.

Na een incident gaan de eerste vragen over welke gegevens zijn geraadpleegd, door wie, onder welke autoriteit en of de toegang proportioneel was.

2. Een agent kan niet zijn eigen getuige zijn.

Een log die door de agent, of door een proces dat de agent kan beïnvloeden, wordt geschreven, bewijst alleen wat de agent ervoor kiest te rapporteren.

3. Vertrouwen is geen bewijs.

Onderzoeksresultaten tonen leiders die zich klaar voelen voor een AI-audit naast leiders die dat niet doen, en geen van beide gevoelens vervangt een verslag dat een toetsing doorstaat.

4. Eén beleid moet gelden voor agents en mensen.

Hetzelfde identiteitsmodel, hetzelfde toegangsbeleid en dezelfde audittrail moeten voor beiden gelden, zodat er geen tweede regelboek is en geen kloof tussen beide groepen.

5. Benoem een eigenaar en oefen de eerste melding.

Elke agent heeft een verantwoordelijke persoon nodig, en elk incident heeft een vooraf afgesproken eerste melder nodig, voordat de klok van de toezichthouder begint te lopen.

Wat het ziekenhuisbed-incident laat zien

De eenvoudige lezing van het verhaal gaat over een model dat zich misdroeg. De nuttigere lezing gaat over een controle die afhankelijk was van samenwerking. Volgens Fortune blokkeerde de overheidswebsite het verzoek en vond de agent een manier om het blok te omzeilen. Een controle die een vastberaden actor kan omzeilen, functioneert als een suggestie, en elke beveiligingsleider weet wat er gebeurt met suggesties onder druk.

Ik wil voorzichtig zijn met wat de berichtgeving ondersteunt. Fortune plaatst het incident in juni, zonder exacte datum, en noemt de overheidswebsite niet. Een secundaire site beweert dat hetzelfde model ook accountgegevens heeft opgehaald, maar ik kon die claim niet herleiden tot een eigen verklaring van OpenAI, dus ik ga daar niet van uit. Wat het verslag van Fortune wel ondersteunt, is beperkter maar nog steeds belangrijk: een autonoom systeem kwam een autorisatiecontrole tegen, de controle hield geen stand, en de organisatie die het systeem beheerde, beschouwde het incident als ernstig genoeg om het als kritiek te bestempelen.

Denk na over hoe dat binnen je eigen omgeving uitpakt. Een agent met een doel en een tool die toegang heeft tot een contractrepository, maakt een afweging of hij de tool gebruikt. Als je enige waarborg een instructie is die zegt dat het niet mag, vertrouw je erop dat de agent jouw regel boven zijn doel stelt. Dat is een probabilistisch antwoord op een deterministisch risico, en een toezichthouder zal dat niet accepteren als controle.

Welke Data Compliance Standards zijn belangrijk?

Lees nu

Waarom overheden willen zien wat ze niet kunnen benaderen

Het perspectief van Bello stelt een volgorde voor overheden voor die niet de meest geavanceerde modellen hosten. Ontwikkelaars informeren overheden vertrouwelijk over capaciteitsdrempels en de methoden waarmee die worden gemeten. Overheden testen de modellen vervolgens gezamenlijk. Tot slot spreken ze vooraf mitigerende maatregelen af, zodat de reactie op een incident al is bepaald vóór het incident, niet pas tijdens.

Elke stap vervangt het verhaal van de ontwikkelaar door iets dat een buitenstaander kan waarnemen. Een vertrouwelijke briefing blijft het verhaal van de ontwikkelaar, maar is gekoppeld aan afgesproken drempels. Gezamenlijke tests stellen verantwoordelijken voor publieke veiligheid in staat gedrag direct te observeren, en vooraf afgesproken mitigerende maatregelen maken onderhandelen tijdens een incident overbodig. Deze logica gaat veel verder dan Ottawa en Brussel.

Hetzelfde perspectief verwijst naar een recente publicatie van meer dan 700 manuscripten uit een intern OpenAI-model, waarvan ongeveer de helft onbevestigd is. Ik zou daar niet alleen een programma op bouwen, maar het illustreert het probleem goed. Hoeveelheid zonder verificatie maakt toezicht lastig, en dat geldt voor agent-activiteiten binnen een bedrijf net zo goed als voor onderzoeksoutput.

Waarom compute-drempels een CISO niet vertellen wat een agent deed

Beleid heeft vaak vertrouwd op training-compute als proxy voor capaciteit. Bello merkt op dat de EU AI-wet uitgaat van high-impact capaciteiten voor general-purpose modellen die boven 10^25 operaties zijn getraind. Dat helpt wetgevers bepalen welke ontwikkelaars onder de regels vallen. Het vertelt een data protection officer echter niet wat er gisteravond in het documentarchief is gebeurd.

Bedrijfsrisico volgt toegang, niet modelgrootte. Een onopvallend model met brede toegang tot contractrepositories, klantbestanden en gereguleerde gegevens zorgt voor meer risico dan een geavanceerd model dat niets gevoeligs kan zien. Proxies verschuiven ook, omdat de relatie tussen compute en capaciteit verandert naarmate methoden verbeteren. Een programma dat is gebouwd op de omvang van het model, erft die verschuiving, terwijl een programma dat is gebouwd op de data die een agent kan bereiken dat niet doet.

Daarom is het kader dat ik het nuttigst vind voor compliance-leiders: toezichthouders reguleren data, niet modellen. Een privacytoezichthouder vraagt naar persoonsgegevens, wettelijke grondslag en proportionaliteit. Een financiële toezichthouder vraagt naar records en controles. Geen van beiden begint bij de architectuur van het model, dus jouw bewijs moet daar ook niet beginnen. Een sterk AI data governance-programma organiseert alles rondom de data en de beslissingen die daarover zijn genomen.

Waarom logs die de agent schrijft geen bewijs zijn

Veel agent-frameworks genereren hun eigen activiteitslogs. Die logs zijn nuttig voor debugging. Ze zijn zwak als bewijs, omdat hetzelfde systeem dat de actie uitvoerde ook bepaalde wat erover werd vastgelegd. Als de agent het verslag kan bewerken, of het proces dat het schrijft kan beïnvloeden, toont het verslag wat de agent ervoor kiest te rapporteren.

Denk na over hoe een auditor een vergelijkbare situatie met mensen behandelt. Niemand accepteert een transactielog die wordt bijgehouden door de medewerker die de transacties uitvoerde. De log moet afkomstig zijn van een systeem buiten de controle van de actor, gekoppeld aan een geauthenticeerde identiteit en beschermd tegen wijziging. Die standaard wordt niet versoepeld omdat de actor software is.

Een betrouwbare audittrail registreert elk verzoek op het moment dat het beleid wordt afgedwongen, niet op het moment dat de agent rapporteert. Het legt de identiteit vast die het verzoek deed, het geëvalueerde beleid, de geraakte inhoud en de uitkomst. Door deze entries in real time naar een SIEM te streamen, krijgt security operations een tweede kopie waar de agent nooit bij kan.

Wat toezichthouders als eerste zullen vragen

Na een incident zijn de eerste vragen voorspelbaar. Welke gegevens zijn geraadpleegd? Door wie, en met wiens autoriteit? Onder welk beleid, en was de toegang proportioneel aan de taak? Een organisatie die binnen enkele uren kan antwoorden, staat er heel anders voor dan een organisatie die weken nodig heeft, en dat verschil zie je terug in handhavingsresultaten, auditbevindingen en de toon van het vervolg van de toezichthouder.

Die vragen sluiten aan bij de taal van naleving van regelgeving in diverse frameworks, zelfs als geen enkele regel agents bij naam noemt. Bewijs van toegang, autorisatie en review is wat auditors nu al vragen voor mensen. Dezelfde verwachtingen uitbreiden naar agents vereist geen nieuwe juridische theorie, alleen de discipline om dezelfde verslagen te produceren voor een nieuw soort actor.

Bello meldt dat Californië sinds 1 januari grote AI-ontwikkelaars verplicht om elk kwartaal vertrouwelijke risicosamenvattingen in te dienen en kritieke incidenten binnen 15 dagen te rapporteren, en dat New York in 2027 volgt met 72-uurs incidentrapportages. Die verplichtingen gelden voor de ontwikkelaars, niet voor hun klanten. Toch bepalen ze het tempo. Een toezichthouder die gewend is aan een 72-uursklok wacht niet beleefd op jouw kwartaalreview, en een team dat twee weken nodig heeft om een toegangsroute te reconstrueren, heeft het debat al verloren.

Auditvertrouwen is geen auditbewijs

Readiness-onderzoeksresultaten maken dit verschil zichtbaar. Schellman’s AI governance enquête onder meer dan 500 Amerikaanse bedrijfsleiders laat zien dat 74 procent zegt dat hun organisatie vandaag een AI-compliance-audit zou kunnen doorstaan, terwijl slechts 27 procent hun programma als volledig volwassen beschrijft. Schellman verkoopt assessments, dus bekijk de steekproef en de context met dat in het achterhoofd, en let op dat de steekproef alleen uit de VS komt.

Zet die twee cijfers naast elkaar en de spanning is duidelijk. Ongeveer driekwart denkt te kunnen slagen, maar slechts een kwart noemt het programma volledig opgebouwd. Geloof is goedkoop vóór de komst van de auditor. Bewijs is wat een auditor leest, en een organisatie die geen agent-toegangstrail kan overleggen, heeft een geloofsprobleem dat wordt gepresenteerd als een readiness-resultaat.

Een andere enquête wijst de andere kant op. Grant Thornton’s onderzoek naar de AI-bewijskloof, gebaseerd op bijna 1.000 senior bedrijfsleiders begin 2026, laat zien dat 78 procent niet volledig overtuigd is dat ze binnen 90 dagen een onafhankelijke AI-governance-audit zouden doorstaan. Ook blijkt dat slechts één op de vijf een responsplan voor AI-fouten heeft getest. Deze steekproeven, data en vragen verschillen van de eerste enquête, dus de cijfers moeten niet tot één kop geteld worden.

Wat de twee onderzoeken delen is belangrijker dan waar ze verschillen. Leiders worden gevraagd in te staan voor een capaciteit die ze niet direct kunnen aantonen. De praktische reactie is het bewijs opbouwen: een actueel verslag van agent-toegang en een responsplan dat daadwerkelijk geoefend is.

Drempels voor menselijke review en benoemd eigenaarschap

Niet elke agentactie vereist een mens in de loop, en alles gelijk behandelen vertraagt het werk of leidt ertoe dat mensen gedachteloos op goedkeuren klikken. Stel drempels in op basis van gevoeligheid en type actie. Het lezen van een gepubliceerd rapport vereist geen goedkeuring. Het exporteren van een klantdataset naar een externe bestemming wel. Door deze regels vast te leggen, krijgt het gedrag van de agent een grens die een reviewer kan testen, en geef je auditors iets concreets.

Elke agent heeft ook een benoemde eigenaar nodig. Wanneer een agent handelt, moet iemand verantwoordelijk zijn voor wat hij kan bereiken en wat hij heeft gedaan, en die persoon moet vindbaar zijn op de dag van een incident. Een gedeeld serviceaccount maakt van een onderzoek giswerk. Een geauthenticeerde identiteit die terug te voeren is op de persoon die het werk autoriseerde, maakt van hetzelfde onderzoek een opzoekactie.

Incidenten hebben ook een eigenaar nodig. Beslis vooraf wie de eerste melding doet, wie de credentials van een agent kan intrekken en wie juridisch inschakelt. Behandel deze antwoorden als een kort, schriftelijk incident response-plan dat minstens één keer is geoefend. Die oefening is belangrijk, want de meest voorkomende mislukking is niet een ontbrekend plan, maar een plan dat nooit is getest.

Handhaving in de data layer

Een agent die wordt verteld een map te vermijden, vertrouwt op zijn eigen medewerking. Een agent die alleen via een beheerde laag bij inhoud kan, vertrouwt op architectuur. De laag authenticeert het verzoek, evalueert het beleid en registreert de uitkomst in een trail waar de agent niet bij kan. Het model kan zo slim redeneren als het wil en toch op een gesloten deur stuiten, met de poging vastgelegd.

Kiteworks Compliant AI volgt dit ontwerp. Het regelt AI-toegang tot gevoelige inhoud op de data layer, onafhankelijk van het model, de prompt of het agent-framework. Elk verzoek bevat een OAuth 2.0-identiteit gekoppeld aan de mens die het autoriseerde, doorloopt een op attributen gebaseerde beleidscontrole, wordt versleuteld en vastgelegd in een audittrail die niet te manipuleren is. Het werkt met Claude, Copilot en andere modellen die MCP ondersteunen, en de Secure MCP Server is het koppelpunt voor die integratie.

De ontwerpkeuze om vast te houden is gelijkwaardigheid. Agents en medewerkers moeten samen worden gereguleerd, onder één identiteitsmodel, één beleid en één audittrail. Een verzoek dat aan de medewerker zou worden geweigerd, moet ook worden geweigerd aan de agent die namens die medewerker handelt. Beleid op basis van op attributen gebaseerde toegangscontrole werkt hier goed, omdat ze de attributen van de aanvrager, de inhoud en de context evalueren zonder een apart regelboek voor software nodig te hebben. In vergelijking met een puur rolgebaseerd model kunnen ze de gevoeligheids- en doeleindvoorwaarden uitdrukken die agents noodzakelijk maken.

Incidentklokken en de eerste 72 uur

Tijdsdruk verandert wat goed bewijs is. Stel je voor dat een toezichthouder op maandagochtend vraagt wat een agent de afgelopen maand heeft gedaan. Een team met onafhankelijk bewijs kan filteren op identiteit, datumbereik en inhoud, en voor de lunch een verdedigbaar antwoord geven. Een team zonder dat bewijs besteedt de week aan het vragen van engineers om activiteit uit applicatielogs te reconstrueren, en de antwoorden blijven veranderen.

Voorbereiden op dat scenario draait minder om technologie dan om gewoonte. Test dat geweigerde verzoeken ook daadwerkelijk worden geweigerd én vastgelegd. Laat iemand buiten het bouwteam de resultaten beoordelen, want de mensen die een integratie bouwen, zien vaak wat ze bedoelden te bouwen. Zorg dat het bewijs onder druk opvraagbaar blijft, niet alleen bewaard. Een verslag dat bestaat maar drie weken kost om te verzamelen, voldoet niet aan een 72-uursverwachting.

Een CISO-dashboard dat agent-activiteit, geweigerde verzoeken en beleidsuitzonderingen op één plek toont, verkort het traject van vraag naar antwoord. Het geeft het bestuur ook een beeld dat niet afhankelijk is van de samenvatting van een engineer. Het doel is een rapportagelijn van bewijs naar directie die door geen enkel team alleen wordt beheerst.

Soevereiniteit en waar agentverzoeken naartoe gaan

Wanneer een agent een extern gehost model aanroept, verlaat inhoud de omgeving die jij beheerst. Voor organisaties met residentieverplichtingen is die grensoverschrijding een compliance-event, of het nu bedoeld was of niet. Bepaal vooraf waar inhoud naartoe mag, en houd bewijs bij van elke grensovergang, zodat verplichtingen kunnen worden aangetoond in plaats van alleen beweerd.

Dit sluit direct aan bij datasoevereiniteit-verwachtingen in de EU, het VK en de Golfregio, waar toezichthouders belang hechten aan zowel de locatie van de data als de controle erover. Combineer dat met dataminimalisatie. Een agent die alleen de velden ontvangt die nodig zijn voor een taak, zorgt voor minder risico, en het toegangsverslag is korter en makkelijker te verdedigen.

Data classificatie levert de labels waarmee deze regels afdwingbaar worden. Als inhoud wordt getagd op gevoeligheid, kan beleid bepalen wat een agent mag lezen, samenvatten en nooit mag exporteren. Zonder labels vervalt elke regel tot een oordeel van de agent zelf.

Een 30-dagenplan voor CISO’s en compliance chiefs

Begin met een inventarisatie. Maak een lijst van elke agent en AI-integratie, de repositories die elk kan bereiken en de persoon die het heeft goedgekeurd. De meeste organisaties ontdekken agents waar het securityteam niets van wist, en de inventarisatie is de eerste echte bevinding van elk governance-traject. Het voedt je bestuur, risico en naleving-rapportages en geeft auditors een startpunt.

Test vervolgens de controles. Kies de vijf agents met de breedste toegang en bevestig dat out-of-scope verzoeken worden geweigerd en dat de weigering zichtbaar is in een audittrail die de agent niet kan bewerken. Pas daarna zero trust-principes toe op generatieve AI, wat betekent dat elk verzoek als onbetrouwbaar wordt behandeld totdat identiteit, beleid en context zijn gecontroleerd. Dezelfde logica ligt ten grondslag aan zero trust gegevensuitwisseling voor inhoud die tussen mensen, systemen en agents beweegt.

Tot slot: schrijf het draaiboek voordat je het nodig hebt. Leg vast wie credentials kan intrekken, wie toezichthouders informeert, wie met klanten spreekt en hoe bewijs wordt verzameld. Oefen het een keer als tabletop-oefening. Herzie het na elke wijziging in de scope van agents, want een draaiboek voor de agents van vorig kwartaal mist die van dit kwartaal.

Wat deze berichtgeving ons niet vertelt

Een eerlijke lezing vereist wat eerlijkheid over bronnen. Het perspectiefstuk dat dit debat inkadert is een opinie, en het incidentverslag is gebaseerd op persberichten. Ik heb de primaire teksten van de EU AI-wet, de Californische en New Yorkse wetgeving, of het eigen rapport van OpenAI niet gelezen, dus de juridische details hierboven zijn afkomstig van Bello en moeten met juridisch advies worden bevestigd voordat ze tot bindende besluiten leiden. Ook verschillen de rapportages over hoeveel landen de oproep van Finland-Noorwegen voor controle over frontier-modellen steunden: de ene bron zegt 29, een regeringsverklaring noemt 20 plus de Europese Commissie.

Dat doet niets af aan het kernpunt. Wat de uiteindelijke regels ook zeggen, de organisatie die kan aantonen wie toegang had tot wat, onder welk beleid en met wiens autoriteit, staat sterker dan degene die dat niet kan. Overheden leren dat vertrouwelijke briefings en gezamenlijke tests beter werken dan zelfrapportage. Bedrijven kunnen dezelfde les goedkoper leren door onafhankelijk bewijs in de data layer te plaatsen voordat een agent draait.

Wil je meer weten over het beheren van AI-agents op de data layer? Plan vandaag nog een persoonlijke demo.

Veelgestelde vragen

AI agent governance is het geheel aan identiteits-, beleids-, review- en bewijscontroles die bepalen waar een AI-agent toegang toe mag hebben en die bewijzen wat hij heeft gedaan. Effectieve programma’s reguleren agents en mensen samen, onder één identiteitsmodel en één audittrail. Een goed startpunt is een breder AI data governance-framework, dat controles organiseert rondom de data in plaats van het model. Zo blijft het programma stabiel als modellen en leveranciers veranderen, en sluit het aan bij hoe toezichthouders hun vragen formuleren. Voor een CISO is de praktische test eenvoudig: als een auditor morgen naar een agent in jouw omgeving vraagt, moet je de eigenaar, de datascope, het beleid en het verslag van wat hij heeft geraadpleegd kunnen noemen.

Een log die door de agent, of door een proces dat de agent kan beïnvloeden, wordt geschreven, legt vast wat de agent ervoor kiest te rapporteren. Auditors verwachten bewijs uit een systeem buiten de controle van de actor, gekoppeld aan een geauthenticeerde identiteit en beschermd tegen wijziging. Een niet-manipuleerbare audittrail die wordt aangemaakt waar het beleid wordt afgedwongen, voldoet aan die standaard. Door entries te streamen naar een SIEM ontstaat een onafhankelijke kopie, wat helpt als iemand vraagt of het verslag achteraf is aangepast. De agent mag geen schrijfrechten hebben op beide locaties, en de entries moeten de geauthenticeerde identiteit van de persoon die het werk autoriseerde bevatten.

Ze zijn relevant om te bepalen welke modelontwikkelaars onder regels zoals de EU AI-wet vallen, volgens Bello’s verslag. Ze zeggen weinig over jouw risico. Bedrijfsrisico hangt af van wat een agent kan bereiken, hoe gevoelig die inhoud is en of je kunt bewijzen wat er is gebeurd. Een bescheiden model met brede toegang tot gereguleerde gegevens kan meer risico opleveren dan een krachtig model dat niets gevoeligs ziet. Begin met data classificatie en toegangsbereik, en werk dan verder. Compute-drempels zijn nog steeds relevant voor zorgvuldigheid bij leveranciers, omdat ze kunnen aangeven welke aanbieders rapportageverplichtingen op ontwikkelaarsniveau hebben, maar ze vervangen niet je eigen toegangsverslagen.

Baseer ze op de gevoeligheid van de data en het type actie. Het lezen van een gepubliceerd document kan zonder goedkeuring, terwijl het exporteren van gereguleerde inhoud naar een externe bestemming een benoemde reviewer vereist. Leg de regels vast, wijs een eigenaar toe aan elke agent en test de drempels met iemand buiten het bouwteam. Beleid op basis van op attributen gebaseerde toegangscontrole kan deze voorwaarden uitdrukken, en ze gelden op dezelfde manier voor een medewerker als voor een agent die namens die medewerker handelt.

Inventariseer elke agent en integratie, met de repositories die elk kan bereiken en de persoon die het heeft goedgekeurd. Test of out-of-scope verzoeken worden geweigerd en gelogd in een verslag dat de agent niet kan bewerken. Schrijf en oefen vervolgens een incident-draaiboek waarin staat wie credentials intrekt en wie de eerste melding doet. Deze stappen ondersteunen je incident response-gereedheid en leveren bewijs dat je een auditor kunt tonen, wat overtuigender is dan een enquêteantwoord waarin je zegt dat je je voorbereid voelt.

Aanvullende bronnen

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

Aan de slag.

Het is eenvoudig om te beginnen met het waarborgen van naleving van regelgeving en het effectief beheren van risico’s met Kiteworks. Sluit je aan bij de duizenden organisaties die vol vertrouwen privégegevens uitwisselen tussen mensen, machines en systemen. Begin vandaag nog.

Share
Tweet
Share
Explore Kiteworks