Behandel een AI-agent met systeemtoegang als privileged identity, niet als software

Een AI-agent die bedrijfssystemen benadert, API's aanroept of configuraties wijzigt, moet u besturen als een geprivilegieerde identiteit, niet als gewone software. Dat betekent een eigen identiteit, minimale rechten, kortlevende toegang, continue monitoring, menselijke goedkeuring bij ingrijpende acties en een vooraf vastgelegde eigenaar voor security en aansprakelijkheid.

Wat stelt de IAPP vast over AI-agents met toegang tot bedrijfssystemen?

De International Association of Privacy Professionals (IAPP) wijst er in een redactionele bijdrage van 5 oktober 2026 op dat AI-agents die toegang krijgen tot systemen als Microsoft 365, GitHub, financiële applicaties, interne databases en API's nieuwe vragen oproepen over cybersecurity, identiteit en aansprakelijkheid. De kern: zodra een agent zelfstandig handelingen uitvoert, gedraagt hij zich niet als een tool maar als een actor met bevoegdheden. Het is een opiniebijdrage, geen officiële bevinding, maar de analyse sluit aan bij recente overheidsrichtlijnen.

De IAPP-bijdrage maakt daarmee een governance-verschuiving expliciet die veel organisaties nog niet in hun beleid hebben verwerkt. Naar onze inschatting is dit het belangrijkste punt: de bestaande scheiding tussen "mens met rechten" en "software zonder eigen verantwoordelijkheid" houdt onvoldoende rekening met software die zelfstandig beslissingen neemt binnen uw systemen.

Waarom volstaat gewone softwarebeveiliging niet voor een handelende AI-agent?

Voor een handelende agent moet u authenticatie, autorisatie en verantwoording afzonderlijk kunnen beoordelen: authenticatie stelt vast welke agent handelt; autorisatie bepaalt wat hij mag; verantwoording koppelt elke handeling aan de agent, zijn menselijke of organisatorische opdrachtgever, het gedelegeerde doel en de partij die moet monitoren en ingrijpen.

De gezamenlijke richtlijn van zes nationale cybersecuritydiensten — de Australische ACSC, de Amerikaanse CISA en NSA, het Canadese Centre for Cyber Security en de NCSC's van Nieuw-Zeeland en het Verenigd Koninkrijk — benoemt concrete risico's: misbruik van rechten, scope creep (rechten die ongemerkt uitdijen), identity spoofing, confused-deputy-aanvallen (waarbij een agent zijn bevoegdheid onbedoeld voor een ander uitvoert) en verantwoordingsgaten. De aanbevolen maatregelen staan in Careful adoption of agentic AI services: een eigen, cryptografisch verankerde identiteit per agent, minimale rechten, runtime-authenticatie, kortlevende (just-in-time) credentials, continue monitoring en menselijke goedkeuring voor acties met grote impact.

Het NIST National Cybersecurity Center of Excellence beschrijft in een conceptpaper van februari 2026 waarom gedeelde serviceaccounts hier tekortschieten: u moet een agent kunnen onderscheiden van een menselijke gebruiker, gedelegeerde rechten kunnen afbakenen en elke handeling kunnen herleiden tot een benoemde opdrachtgever. Een academische studie op arXiv voegt toe dat identiteit alleen niet genoeg is: zodra agents sub-agents aanroepen of meerdere systemen doorkruisen, ontstaat een verantwoordingsgat als de delegatieketen geen cryptografische herkomst en afdwingbare scope kent. Dit onderstreept het belang om een eigen identiteit met gedelegeerde en gelogde autorisatie te geven en om least privilege af te dwingen tijdens uitvoering, niet bij provisioning.

Wie is aansprakelijk als een AI-agent schade veroorzaakt?

Dat ligt juridisch nog niet vast. Paul Ohm, hoogleraar aan Georgetown University Law Center, legde op 30 september 2026 in een getuigenis voor een subcommissie van de Amerikaanse Senaat uit dat benadeelden claims kunnen richten op ontwikkelaars, deployers, monitors en controllers, langs bestaande leerstukken als onzorgvuldigheid (negligence) en productaansprakelijkheid. Daarnaast besprak hij mogelijke nieuwe wetgeving met aansprakelijkheid voor ontwikkelaars en deployers bij ernstige schade.

Belangrijk voor de nuchtere lezer: dit zijn voorstellen en juridische argumenten, geen aangenomen regels of rechterlijke uitspraken. De hoorzitting heeft het recht niet veranderd. Wat de getuigenis wel duidelijk maakt, is dat de keten van aansprakelijkheid in de developer-deployer-keten straks kan worden uitgevraagd op basis van wie wat wist, bepaalde en kon stoppen. De bronnen laten één vraag open: hoe die aansprakelijkheid in de praktijk wordt verdeeld tussen de partijen die de agent ontwerpen, inzetten, bedienen en beheersen. Naar onze analyse is contractuele risicoverdeling daarom belangrijk, maar bij gebrek aan afspraken kan de aansprakelijkheidsvraag mede worden beoordeeld aan de hand van factoren zoals voorzienbaarheid van de schade, nalatigheid, de feitelijke zeggenschap en toepasselijke contractuele bepalingen; de uitkomst staat niet vooraf vast.

Wat betekent dit voor bestuurders, juristen en CISO's die een agent moeten goedkeuren?

Onze analyse: omdat een agent met systeemtoegang zelfstandig handelingen kan uitvoeren, verschuift het risico van "verkeerde output" naar "verkeerde actie met gevolgen"; daarom zouden organisaties een agent pas moeten goedkeuren wanneer een benoemde eigenaar verantwoordelijk is voor zijn rechten, gedrag en incidentafhandeling. Omdat rechten ongemerkt uitdijen wanneer een agent steeds meer taken krijgt, ontstaat scope creep die uw aanvalsoppervlak vergroot; daarom legt u per agent een vervaldatum op verhoogde toegang vast en laat u die runtime afdwingen in plaats van bij uitgifte. Omdat een verantwoordingsgat kan ontstaan wanneer een agent sub-agents aanroept en de delegatieketen geen cryptografische herkomst en afdwingbare scope heeft, eist u sluitende logging van de delegatieketen voordat de agent live gaat, met herleidbaarheid naar een menselijke opdrachtgever. Onze analyse: omdat de aansprakelijkheidsuitkomst mede afhangt van contracten, voorzienbaarheid, nalatigheid en feitelijke zeggenschap, moet de jurist vooraf een expliciete verdeling opnemen van security-eigenaarschap, meldplicht en aansprakelijkheid bij ernstige schade.

Als samenvatting keurt u een agent pas goed wanneer u de volgende punten kunt beantwoorden:

• Wie is de benoemde eigenaar van deze agent binnen uw organisatie?
• Welke data en welke tools kan hij bereiken, en met welke minimale rechten?
• Welk doel autoriseert elke handeling, en wanneer vervalt verhoogde toegang?
• Welke onafhankelijke controle kan hem stoppen bij ingrijpende of onomkeerbare acties?
• Welke logs bewaren de delegatieketen tot een menselijke opdrachtgever?
• Welke organisatie onderzoekt en meldt na schade, en is dat contractueel vastgelegd?

Deze vragen horen thuis in uw bredere beleid rond governance voor agentic AI en AI-agents. Wie ze niet vooraf beantwoordt, ontdekt de antwoorden pas na een incident — op het verkeerde moment, met de verkeerde partij als risicodrager.

Bronnen: Het artikel steunt op de IAPP-bijdrage, de gezamenlijke richtlijn van zes nationale cybersecuritydiensten, het NIST-conceptpaper over agentidentiteit, de Senaatsgetuigenis van Paul Ohm en een arXiv-studie over AI-identiteit.