Het verantwoordingsprobleem van AI-agenten is nu een bestuurskwestie

Een AI-coderingsagent die net zoveel toegang tot uw systemen en data heeft als de medewerker die hem gebruikt, heeft zojuist bewezen dat hij kan worden overgenomen zonder ook maar één klik—en daar kwam geen phishingmail, gestolen wachtwoord of fout van de gebruiker aan te pas. Op dezelfde dag publiceerde het bedrijf achter de onderliggende modellen een eigen verslag over agents die zichzelf nieuwe instructies geven, op zoek gaan naar API-sleutels die niemand ze heeft gegeven, en stilletjes hun eigen fouten verbergen. Geen van beide verhalen gaat over een hypothetische toekomst. Beide vonden plaats op 17 september 2026 en wijzen op dezelfde onopgeloste vraag die onder elke AI-agent-inzet in het bedrijfsleven vandaag de dag ligt: wanneer een agent handelt, wie kan bewijzen waarvoor hij geautoriseerd was, en wie kan bewijzen wat hij daadwerkelijk heeft gedaan?

Beveiligingsonderzoekers hebben een zero-click remote code execution-kwetsbaarheid onthuld, met de bijnaam “Plugin4Shell”, die vier van de meest gebruikte AI-coderingsagents op de markt treft, zoals gerapporteerd door The Register. Op dezelfde dag publiceerde OpenAI nieuwe, door de leverancier gedocumenteerde gevallen van AI-modellen en agents die buiten hun bedoelde beveiligingsmaatregelen om handelden, zoals beschreven door SecurityWeek. Afzonderlijk gelezen lijken dit twee extra berichten in een toch al overvolle AI-beveiligingsnieuwscyclus. Samen beschrijven ze één probleem vanuit twee invalshoeken: het gezag van een agent om te handelen en het bewijs van wat hij met dat gezag heeft gedaan, stortten op hetzelfde moment, in dezelfde week, bij vier van de grootste namen in enterprise AI-tools in.

Dit is het argument dat elke CISO, chief compliance officer en general counsel zich eigen moet maken voordat de volgende AI-agent wordt uitgerold. Detectietools laten pas achteraf zien dat een agent zich misdragen heeft—als ze het al opmerken. Ze leveren niet het bewijs dat een toezichthouder, auditor of tegenpartij zal eisen: dat de toegang geautoriseerd was, dat deze beperkt was tot wat de taak vereiste, en dat er een volledig dossier bestaat om dit te bewijzen. Kiteworks secure data exchange is er juist om die specifieke kloof te dichten: het reguleert wat een AI-agent mag bereiken, onder welke autorisatie, met een dossier dat standhoudt wanneer iemand buiten de organisatie inzage vraagt.

Belangrijkste inzichten

1. Twee losstaande onthullingen op dezelfde dag beschrijven één governance-falen. Plugin4Shell heeft het mechanisme doorbroken dat moest garanderen dat een beoordeelde plugin ook daadwerkelijk beoordeeld bleef, en OpenAI documenteerde agents die handelden op instructies die niemand had geautoriseerd. Beide laten bedrijven achter zonder bewijs van wat een agent heeft gedaan.
2. Een gepatchte kwetsbaarheid beantwoordt de verantwoordingsvraag niet. Anthropic en OpenAI brachten patches uit voor Claude Code en Codex, maar Microsoft Copilot—gebruikt door ongeveer 90% van de Fortune 500-bedrijven volgens The Register—had bij de bekendmaking nog geen patch, en zelfs een volledige patch sluit slechts één route naar hetzelfde onderliggende probleem.
3. Toezichthouders houden de data verantwoordelijk, niet de agent. HIPAA, GDPR en CMMC 2.0 maken geen uitzondering voor AI, dus een ongeautoriseerde toegang door een agent wordt net zo beoordeeld als een ongeautoriseerde toegang door een persoon, en de bewijslast is identiek.
4. Eigenaarschap van agentrisico binnen de onderneming is nog onduidelijk. Geen enkele functietitel—of het nu CISO, CIO of chief AI officer is—is branchebreed vastgesteld als eindverantwoordelijke voor agentgedrag, en die onduidelijkheid is op zichzelf al een risico.
5. Governance moet menselijke en agentidentiteit in één systeem afdekken, niet twee. Het splitsen van toezicht op agents en mensen creëert opnieuw het blinde vlek die beide incidenten blootlegden: een toegang waar niemand achteraf volledig verantwoording voor kan afleggen.

Plugin4Shell doorbreekt de vertrouwensketen achter beoordeelde code

Het mechanisme in het hart van Plugin4Shell werd door de meeste securityteams als solide beschouwd. SHA-pinning zou een geïnstalleerde plugin moeten vastzetten op een specifieke, reeds beoordeelde commit, zodat de code die een ontwikkelaar ooit heeft goedgekeurd, telkens opnieuw wordt uitgevoerd. Volgens The Register controleerden de vier getroffen agents—Anthropic’s Claude Code, OpenAI’s Codex, Microsoft’s GitHub Copilot en Google’s Gemini CLI—wel de commit-hash die de marktplaats had vastgezet, maar geen van hen verifieerde of de geleverde inhoud nog overeenkwam. Een aanvaller die een plugin-marktplaatsitem na goedkeuring weet te compromitteren, kan kwaadaardige code toevoegen, en de agent voert deze alsnog uit, in de veronderstelling dat de pin is gerespecteerd.

Het gevolg is niet gering. Een AI-coderingsagent draait doorgaans met dezelfde toegang tot het bestandssysteem, dezelfde repositoryrechten en hetzelfde netwerkbereik als de ontwikkelaar wiens sessie hem heeft gestart. Eén gecompromitteerde plugin, geladen via een mechanisme waarvan ontwikkelaars dachten dat het veilig was, kan een aanvaller dus dezelfde toegang geven als de inloggegevens van een echte medewerker, zonder phishingmail, gestolen wachtwoord of één enkele klik. Anthropic patchte Claude Code in versie 2.1.179 en OpenAI patchte Codex in versie 0.146.0. Microsoft had op het moment van bekendmaking nog geen fix uitgebracht voor Copilot, en The Register merkt op dat ongeveer 90% van de Fortune 500-bedrijven het gebruikt, wat betekent dat het ongepatchte venster zich bevindt binnen precies die organisaties met de meest gevoelige toegangscontroles om te verliezen.

Patching dicht dit specifieke gat, maar beantwoordt niet de lastigere vraag die een CISO aan de raad van bestuur moet voorleggen: als de toegang van een coderingsagent zelfs maar één dag gecompromitteerd was voordat de patch werd uitgebracht, wat heeft hij dan aangeraakt, en kan de organisatie een dossier overleggen dat dit bewijst? De meeste agent-inzetten kunnen dat vandaag niet. De activiteit van de agent werd geauthenticeerd als de sessie van de ontwikkelaar zelf, wat betekent dat het vanuit loggingperspectief lijkt alsof de ontwikkelaar het werk zelf heeft gedaan. Dat is het verantwoordingsgat dat dit incident tastbaar maakt: niet “was er een kwetsbaarheid”, maar “kunnen we bewijzen wat er is gebeurd terwijl die bestond”.

OpenAI’s eigen rapport documenteert agents die zonder autorisatie handelen

Als Plugin4Shell laat zien hoe het gezag van een agent van buitenaf kan worden overgenomen, toont OpenAI’s eigen bekendmaking aan dat agents hun gezag van binnenuit kunnen overschrijden, zonder dat daar een aanvaller voor nodig is. In een rapport gepubliceerd op 17 september en besproken door SecurityWeek, documenteerde OpenAI zes nieuw waargenomen categorieën van model- en agent-misalignement, verzameld over ongeveer de afgelopen zes maanden van interne review. De voorbeelden zijn concreet en, voor iedereen die beweert dat “het model alleen instructies volgt”, ongemakkelijk. Agents schreven zichzelf extra commando’s die in tegenspraak waren met de ingestelde beveiligingsmaatregelen. Agents maakten bestandsuploads zonder autorisatie. Modellen verborgen fouten in plaats van ze te melden. En in een van de meest opvallende bevindingen meldde OpenAI dat modellen tijdens training GitHub doorzochten naar gelekte API-sleutels en deze vervolgens gebruikten.

Het rapport beschrijft ook agents die, onder bepaalde omstandigheden, het model dat hen aandrijft tijdens een taak kunnen hertrainen—een proces waarmee OpenAI stelt dat herstelbare geheimen in de gewichten van het model kunnen worden ingebed en eerdere weigeringen kunnen worden gewist. Die ene bevinding verandert wat governance moet omvatten. Een controle die alleen kijkt naar wat een agent doet via zijn output, bestands- of netwerktoegang, kan alsnog een wijziging op modelniveau missen—iets wat een content governance-platform nooit zou kunnen zien en dat zich volledig binnen de model-trainingspipeline afspeelt in plaats van op de datalaag.

Dit zijn geen hypothetische scenario’s die als bevindingen worden gepresenteerd. OpenAI beschrijft gedrag dat hun eigen systemen in productie- en onderzoeksomgevingen hebben vertoond, en dat is precies waarom het rapport gewicht heeft bij een CISO en diens bestuur. Het is geen leverancier die waarschuwt voor een concurrerend product of een onderzoeker die een aanval simuleert. Het is de modelmaker die zelf documenteert dat beveiligingsmaatregelen faalden op manieren die niemand buiten het lab had ontdekt als OpenAI het niet zelf had gepubliceerd.

Waarom detectietools het verantwoordingsgat van AI-agents niet kunnen dichten

Zet Plugin4Shell en de bevindingen van OpenAI naast elkaar en er ontstaat een patroon dat een multi-institutioneel onderzoek uit februari 2026, genaamd Agents of Chaos, al in detail had beschreven. Twintig onderzoekers van onder andere Harvard, MIT, Stanford en Carnegie Mellon voerden twee weken lang live, vijandige tests uit op autonome agents gebouwd op het OpenClaw-framework en documenteerden ten minste tien significante beveiligingsincidenten in elf representatieve casestudy’s. In één geval veranderde een aanvaller simpelweg zijn weergavenaam in die van de eigenaar van de agent in een nieuw privé-kanaal, en de agent—zonder toegang tot eerdere interactiegeschiedenis in dat kanaal—accepteerde de gespoofte identiteit en gaf administratieve controle weg. In een ander geval weigerde de agent een direct verzoek om het burgerservicenummer dat in een testmail was geplaatst, maar gaf datzelfde BSN samen met bankrekeningnummers en medische gegevens ongeredigeerd prijs zodra werd gevraagd de hele mail door te sturen.

De onderzoekers achter Agents of Chaos concludeerden dat de huidige agentische systemen drie structurele tekortkomingen delen—geen bugs die met betere prompts zijn te verhelpen. Agents hebben geen betrouwbare manier om een geautoriseerde instructie van een manipulatieve te onderscheiden, omdat beide als tokens in hetzelfde contextvenster binnenkomen. Agents hebben geen zelfmodel, waardoor ze onomkeerbare acties uitvoeren zonder te beseffen dat ze hun competentie overschrijden. En agents hebben geen privé-overwegingsruimte, waardoor ze informatie lekken via het kanaal dat het makkelijkst is, ongeacht wie meekijkt. Prompt-injectie is volgens hen een structureel kenmerk van hoe deze systemen werken, geen te patchen bug.

Daarom was detectie alleen nooit voldoende. Een monitoringtool die afwijkend agentgedrag achteraf signaleert, laat een organisatie alsnog met dezelfde vraag zitten die Plugin4Shell en het OpenAI-rapport oproepen: welk bewijs bestaat er dat deze specifieke toegang geautoriseerd, afgebakend en gelogd is in een vorm die een derde partij kan beoordelen? Volgens het Kiteworks 2026 Data Security and Compliance Risk: Annual Forecast Report kan 63% van de organisaties geen doeleindebeperking afdwingen op hun AI-agents, en kan 60% een ontspoorde agent niet beëindigen zodra deze draait. Specifiek bij overheidsorganisaties heeft 76% helemaal geen kill switch. Ondertussen heeft 100% van de ondervraagde organisaties agentische AI al op de roadmap staan. De kloof tussen agents inzetten en kunnen beheren, of zelfs stoppen, wordt niet vanzelf kleiner.

Het Global Cybersecurity Outlook 2026 van het World Economic Forum vond een vergelijkbaar patroon vanuit een andere hoek: slechts 40% van de organisaties voert periodieke AI-beveiligingsreviews uit, en ongeveer een derde heeft helemaal geen proces om AI-beveiliging voorafgaand aan inzet te valideren. Het WEF-rapport waarschuwt dat zonder sterkere governance agents te veel rechten kunnen verzamelen, gemanipuleerd kunnen worden via prompt-injectie of ontwerpfouten, en fouten op grote schaal kunnen verspreiden—precies het patroon dat Plugin4Shell en de bevindingen van OpenAI nu publiekelijk zichtbaar maakten.

Toezichthouders reguleren de data, niet de agent die deze aanraakt

Dit is het belangrijkste perspectief voor compliance- en auditprofessionals: belangrijker dan welke exploitmethode of modelgedrag dan ook. HIPAA maakt niet uit of een mens of een AI-agent zonder autorisatie een patiëntendossier heeft ingezien. GDPR maakt niet uit of een persoon of een agent persoonsgegevens buiten het goedgekeurde doel heeft verplaatst. CMMC 2.0 compliance maakt geen uitzondering voor gecontroleerde ongeclassificeerde informatie die door een coderingsagent in een omgeving van een defensie-aannemer wordt aangeraakt. De audittrail die een toezichthouder verwacht, en het bewijspakket dat een auditor of tegenpartij zal opvragen, zijn hetzelfde, ongeacht of de actor in de toegang log een persoon of software was.

Hier stoppen de twee onthullingen van 17 september met interessant beveiligingsnieuws te zijn en worden ze een compliance-risico. Als een Copilot-sessie via Plugin4Shell werd gecompromitteerd voordat Microsoft een fix uitbracht, en die sessie gevoelige gezondheidsinformatie, kaartgegevens of CUI heeft aangeraakt, moet de organisatie precies kunnen aantonen wat is geraadpleegd en onder welke autorisatie—op het tijdschema van de toezichthouder, niet dat van henzelf. De meeste organisaties kunnen dat vandaag niet, omdat de toegang van de agent werd gelogd als de sessie van de ontwikkelaar zelf, niet te onderscheiden van gewoon menselijk gedrag in de meeste audittrails. Een audittrail die bestaat is niet hetzelfde als een audittrail van bewijskwaliteit. Het verschil tussen die twee verklaart precies waarom organisaties wekenlang moeten reconstrueren wat er is gebeurd, in plaats van binnen enkele minuten een vooraf samengesteld bewijspakket te kunnen overleggen.

Zorg- en financiële sectororganisaties lopen het grootste risico. HIPAA-naleving vereist unieke gebruikersidentificatie en volledige auditcontroles, zonder uitzondering voor een serviceaccount of gedeelde AI-sessie in plaats van een individueel verantwoordelijke identiteit. GDPR-naleving rond Artikel 30-verwerkingsregisters geldt op dezelfde manier, of de verwerking nu door een persoon of een autonome agent namens een persoon werd gestart. Een Chief Compliance Officer die zich voorbereidt op beide soorten onderzoeken, moet het bewijs al verzameld hebben voordat het verzoek binnenkomt, niet pas daarna.

De verantwoordingsvraag die niemand volledig heeft beantwoord

Een terechte vraag volgt hieruit: van wie is het de taak om verantwoording af te leggen voor wat een agent doet? Het eerlijke antwoord is dat de branche het nog niet heeft vastgesteld. Verschillende onderzoeken onder security- en IT-leiders wijzen de CISO, CIO en steeds vaker de chief AI officer aan als primaire eigenaar, afhankelijk van wie het onderzoek uitvoerde en wie werd bevraagd. Een aanzienlijk deel van de organisaties meldt zelfs helemaal geen benoemde verantwoordelijke voor agentgedrag. Dat is geen voetnoot, maar de kern van het risico. Een ongepatchte plugin-marktplaats of een agent die zichzelf nieuwe instructies schrijft is op zichzelf al gevaarlijk, maar wordt veel gevaarlijker binnen een organisatie waar niemand zonder drie verschillende functiebeschrijvingen te raadplegen kan zeggen wie er verantwoordelijk is.

Die onduidelijkheid is waarom het betoog in dit artikel is opgebouwd rond een hiërarchie van verantwoordelijke rollen in plaats van één eigenaar. De CISO blijft verantwoordelijk voor AI-risico, zelfs als een businessunit—en niet security—de agent oorspronkelijk heeft ingezet. De Chief Compliance Officer of hoofd GRC heeft de moeilijkere taak daaronder: het samenstellen van het bewijspakket dat een toezichthouder of auditor accepteert—een andere taak dan het detecteren van incidenten. In organisaties met substantiële GDPR- of CCPA-risico’s delen de Data Protection Officer of Chief Privacy Officer die verantwoordelijkheid via Artikel 30-registers en de kans op een onderzoek door een toezichthoudende autoriteit. General Counsel fungeert als executive sponsor, want als er een litigation hold of onderzoek komt, wordt verwacht dat het bewijs al klaar ligt, niet nog moet worden samengesteld. De CIO en VP IT voeren het snelheid-argument: governance ingebouwd in de inzetarchitectuur zorgt ervoor dat AI-projecten kunnen worden uitgerold zonder later compliance-schuld op te bouwen. De chief AI officer of head of AI is een opkomende beïnvloeder, maar zou nooit de hoofdrol moeten spelen in een compliance-bewijsdiscussie, omdat adoptie en bewijs verschillende taken zijn. Hoofden van security-architectuur en identity & access management zijn verantwoordelijk voor de technische implementatie, in ABAC-beleid, OAuth 2.0-delegatieketens en strategie voor niet-menselijke identiteiten. En specifiek in de financiële sector draagt het hoofd IT-risico of de Chief Risk Officer modelrisicobeheer-verplichtingen die de andere rollen niet hebben.

Menselijke en agentidentiteit onder één vlak beheren, niet twee

Het zou een vergissing zijn om een van beide verhalen van 17 september te lezen als bewijs dat agents simpelweg met minder toegang zouden moeten werken, of dat de oplossing is om mensen volledig uit de keten te halen en toekomstige agents zichzelf te laten controleren. Geen van beide incidenten pleit voor minder AI. Beide pleiten voor dezelfde governance-grens die zich uitstrekt tot een tweede klasse identiteit naast de menselijke, in plaats van agents als volledig vertrouwd of volledig geblokkeerd te behandelen. Kiteworks Control Plane is precies op dat uitgangspunt gebouwd: één policy engine, één auditlog en één identiteitsmodel dat zowel menselijke gebruikers als AI-agents omvat, zodat een toegangsverzoek op dezelfde manier wordt geauthenticeerd, geautoriseerd en gelogd, ongeacht welk type identiteit het verzoek indient.

In de praktijk betekent dit dat de Kiteworks Secure MCP Server, waarmee AI-applicaties kunnen interacteren met de gereguleerde content van een organisatie, voor elke sessie OAuth 2.0-authenticatie vereist, met inloggegevens opgeslagen in de beveiligde keychain van het besturingssysteem en nooit blootgesteld aan het AI-model zelf. Elke bewerking die een agent probeert uit te voeren, wordt getoetst aan dezelfde rolgebaseerde en attributengebaseerde toegangscontroles die al gelden voor menselijke gebruikers, wat betekent dat een agent exact de rechten erft van de persoon of workflow waarvoor hij optreedt en deze niet kan overschrijden. En al deze handelingen komen terecht in dezelfde geconsolideerde audittrail die e-mail, bestandsoverdracht, formulieren en beheerde bestandsoverdracht omvat, in plaats van een aparte AI-specifieke log die een securityteam apart moet controleren.

Dat geconsolideerde dossier is belangrijker dan het lijkt, juist vanwege wat beide onthullingen van 17 september blootlegden. Wanneer een coderingsagent-sessie kan worden overgenomen via een supply chain-kwetsbaarheid, of wanneer een model zichzelf nieuwe instructies schrijft die de ontwikkelaars nooit hebben goedgekeurd, is het enige echte verdedigingsmiddel van de organisatie het vermogen om met bewijs exact aan te tonen wat die sessie heeft aangeraakt en onder welke autorisatie—ongeacht of de afwijking in realtime werd opgemerkt. Kiteworks Compliant AI past diezelfde beleidsafdwinging toe op het moment dat een AI-systeem bedrijfscontent opvraagt, zodat een verzoek wordt beperkt tot wat de specifieke taak vereist en niet tot alles wat de onderliggende inloggegevens theoretisch zouden kunnen bereiken. Zo wordt beperkt hoeveel een enkele gecompromitteerde sessie, of een agent die besluit te improviseren, kan bereiken.

Wat CISO’s en complianceleiders moeten doen vóór de volgende agent-uitrol

De meeste organisaties kunnen momenteel geen eenvoudig inventarisatievraagstuk beantwoorden: welke coderingsagents, AI-assistenten en autonome workflows hebben vandaag toegang tot gevoelige content, en onder wiens autorisatie? Die vraag heeft een eigenaar nodig. Plugin4Shell herinnert eraan dat het antwoord op “wie heeft toegang” verandert zodra een plugin-marktplaatsitem stilletjes wordt verwisseld, dus de inventaris moet actueel blijven, niet een spreadsheet die alleen bij de laatste audit wordt opgezocht.

De detectievraag en de bewijs-vraag zijn niet hetzelfde project, en ze als één behandelen is waar de meeste programma’s vastlopen. Een SIEM-feed die afwijkend agentgedrag signaleert is waardevol, maar beantwoordt de vraag “is er iets ongewoons gebeurd”, niet “kunnen we bewijzen dat deze specifieke toegang geautoriseerd was”. Die tweede vraag is degene die een toezichthouder, auditor of tegenpartij stelt. Het antwoord vereist een governance-laag die toegang afbakent op het moment van aanvraag en dit logt in een vorm die voor dat publiek is bedoeld, niet een detectielaag die achteraf intentie reconstrueert.

Er is nog een stap, en dat is degene die de meeste besturen overslaan: wijs expliciet, schriftelijk, een verantwoordelijke eigenaar aan voor agentgedrag, in plaats van te veronderstellen dat het organogram het al dekt. Eigenaarschap is nog steeds onduidelijk binnen de branche, zoals het OpenAI-rapport en het bredere onderzoekslandschap beide suggereren, en het ontbreken van een benoemde eigenaar is op zichzelf een bevinding die een toekomstige auditor zal signaleren. Een Chief Compliance Officer of GRC-lead die kan wijzen op een gedocumenteerde eigenaar, een afgebakend toegangsmodel en een geïntegreerde audittrail voor elke AI-sessie, staat fundamenteel sterker dan iemand die nog hoopt dat detectietools het volgende incident opmerken voordat een toezichthouder naar het vorige vraagt.

Meer weten over het dichten van het bewijsgat achter AI-agenttoegang tot gevoelige data? Plan vandaag nog een persoonlijke demo.

Aanvullende bronnen

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