AI-agent als privileged identity, niet als software

U moet elke AI-agent die bedrijfssystemen benadert, API's aanroept of configuraties wijzigt, als een geprivilegieerde identiteit besturen — met eigen authenticatie, minimale rechten, kortlevende toegang, continue monitoring, menselijke goedkeuring voor ingrijpende acties en een vooraf benoemde eigenaar voor security en aansprakelijkheid.

Een analyse van 6 oktober 2026 van AI-agents met systeemtoegang als geprivilegieerde identiteiten stelt dat agents die zelfstandig handelingen uitvoeren zich niet als tools gedragen maar als actors met bevoegdheden, en dat dit nieuwe vragen oproept over cybersecurity, identiteit en aansprakelijkheid. Het onderzoek gebruikt de integratie van agents in Microsoft 365, GitHub, financiële applicaties en interne databases als kernvoorbeeld. In 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 een agent niet als gewone software kan worden behandeld

Zodra een agent zelfstandig handelingen uitvoert, 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. Dit verschilt fundamenteel van de manier waarop u gewone software inzet, die doorgaans als onderdeel van uw infrastructuur wordt beschouwd zonder eigen identiteit of verantwoordingsketen.

Welke risico's ontstaan wanneer agents rechten krijgen

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 — een agent voert acties uit die buiten zijn beoogde doel vallen.
• Scope creep — rechten die ongemerkt uitdijen naarmate een agent steeds meer taken krijgt.
• Identity spoofing — een agent wordt nagebootst of zijn identiteit wordt overgenomen.
• Confused-deputy-aanvallen — een agent voert zijn bevoegdheid onbedoeld voor een ander uit.
• Verantwoordingsgaten — geen duidelijke herleidbaarheid van acties naar een menselijke opdrachtgever.
• Sub-agent-delegatie zonder grenzen — een agent roept andere agents aan zonder cryptografische herkomst of afdwingbare scope.

Welke concrete controles moet u kunnen aantonen

1. Benoemde eigenaar per agent — documenteer wie verantwoordelijk is voor de rechten, het gedrag en de incidentafhandeling van elke agent.
2. Eigen, cryptografisch verankerde identiteit — geef elke agent een unieke identiteit die niet kan worden gedeeld met menselijke gebruikers of andere agents.
3. Minimale rechten met runtime-afdwinging — leg per agent vast welke acties toegestaan zijn en dwing deze af tijdens uitvoering, niet alleen bij provisioning.
4. Kortlevende credentials met vervaldatum — stel een vervaldatum in voor verhoogde toegang en laat deze runtime afdwingen in plaats van bij uitgifte.
5. Sluitende logging van de delegatieketen — eis herleidbaarheid van elke actie naar een menselijke opdrachtgever, met cryptografische verankering wanneer agents sub-agents aanroepen.
6. Menselijke goedkeuring voor acties met grote impact — definieer welke acties goedkeuring vereisen en implementeer dit als technische controle.

Hoe aansprakelijkheid wordt verdeeld

De juridische kader staat nog niet vast. Een getuigenis voor een subcommissie van de Amerikaanse Senaat op 30 september 2026 legde uit dat benadeelden claims kunnen richten op ontwikkelaars, deployers, monitors en controllers, langs bestaande leerstukken als onzorgvuldigheid en productaansprakelijkheid. Mogelijke nieuwe wetgeving zou aansprakelijkheid voor ontwikkelaars en deployers bij ernstige schade kunnen invoeren. Dit zijn voorstellen en juridische argumenten, geen aangenomen regels of rechterlijke uitspraken.

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. Naar onze analyse is contractuele risicoverdeling daarom belangrijk; 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.

Wat tooling kan doen en wat uw oordeel blijft

Tooling kan authenticatie, autorisatie en logging technisch afdwingen — maar de keuze welke rechten een agent krijgt, wie eigenaar is en hoe aansprakelijkheid wordt verdeeld, blijft uw professioneel oordeel. Tooling kan u helpen scope creep op te sporen, maar het bepalen van wat "scope creep" voor uw organisatie betekent, hoort bij governance. Tooling kan logging leveren, maar de interpretatie van die logs en de vraag wie aansprakelijk is voor een incident, vereist juridische en operationele kennis die geen systeem kan vervangen.