Least privilege voor AI-agents als runtime-controle

U moet aantonen dat elke AI-agent alleen de tools, servers en resources kan aanroepen die voor zijn specifieke taak zijn goedgekeurd, en dat elk gebruik daarvan wordt gelogd en kan worden herzien. Dit is niet langer een instelling bij het aanmaken van de agent, maar een controle die tijdens uitvoering geldt.

De aanleiding is een concrete productwijziging. Een analyse van 23 september 2026 van runtime-controle op verkeer tussen AI-agents en externe servers stelt dat beheerders centraal inzicht moeten krijgen in wat agents daadwerkelijk aanroepen, en Zero Trust-beleid en bescherming moeten toepassen op dat moment van uitvoering. De beschreven tooling biedt een controlepunt voor het Model Context Protocol-verkeer waarmee servers, tools en resources kunnen worden toegestaan of geblokkeerd. In onze inschatting is dit nieuws niet het blokkeren zelf, maar het feit dat de allowlist een eigenschap van runtime wordt in plaats van een eenmalige configuratie bij provisioning. Dit vraagt om onderhoud: de toegestane servers en tools moeten meebewegen met de taken die agents daadwerkelijk uitvoeren.

Waarom statische rollen onvoldoende zijn

Zolang rechten alleen bij het aanmaken van een agent worden vastgelegd, blijft onzichtbaar wat die agent op het moment van handelen daadwerkelijk aanroept. Een agent die met een gedeelde gebruikersidentiteit werkt, is achteraf niet te herleiden naar specifieke acties. Een eigen identiteit per agent maakt het mogelijk om precies vast te stellen namens wie een handeling plaatsvond en welke scope daarbij gold. Dit sluit aan bij het bredere principe om AI-agents een eigen identiteit met gelogde autorisatie te geven, zodat acties traceerbaar blijven.

Bij het Model Context Protocol wordt dit verschil zichtbaar. Een agent kan tijdens een taak externe servers aanroepen voor tools en dataresources. Zonder inzicht in dat verkeer weet u niet welke bronnen worden benaderd. Een controlepunt op dat verkeer maakt het zichtbaar, stelt u in staat beleid af te dwingen, en kan niet-goedgekeurde servers blokkeren.

Welke risico's ontstaan zonder runtime-controle?

• Onzichtbare tool-aanroepen — agents roepen externe servers aan die niet zijn geverifieerd of niet voor die taak zijn bedoeld.
• Scope creep zonder detectie — een agent krijgt bij provisioning beperkte rechten, maar roept tijdens uitvoering tools aan die buiten die scope vallen.
• Onherleidbare acties — zonder eigen agent-identiteit kan niet worden vastgesteld welke agent welke handeling heeft verricht.
• Gedeelde identiteiten — agents die met gebruikersidentiteiten werken, maken audit en accountability onmogelijk.
• Ontbrekende logs — het verkeer tussen agents en externe resources wordt niet geregistreerd en kan niet worden herzien.

Welke controles moet u kunnen aantonen?

1. Eigen identiteit per agent — elke agent heeft een unieke identiteit waarmee zijn acties kunnen worden herleid en gelogd.
2. Allowlist van goedgekeurde servers en tools — voor elke agent is vastgelegd welke externe servers, tools en resources hij mag aanroepen.
3. Runtime-autorisatie op het moment van aanroep — het systeem controleert bij elke tool-aanroep of deze binnen de allowlist valt.
4. Centraal zicht op agent-verkeer — het verkeer tussen agents en externe resources is zichtbaar en kan worden gemonitord.
5. Audit trail van alle acties — elke tool-aanroep, elke goedkeuring en elke weigering wordt gelogd en kan worden herzien.
6. Just-in-time goedkeuring voor gevoelige acties — acties buiten de standaard allowlist vereisen expliciete goedkeuring voordat ze worden uitgevoerd.

Hoe verschuift least privilege van provisioning naar runtime?

Least privilege voor agents geldt niet alleen voor de agent zelf, maar ook voor de mensen die agents configureren en uitrollen. U kunt agenttoegang beperken tot specifieke gebruikers of groepen, en gevoelige beheerdersrollen laten lopen via Privileged Identity Management, met just-in-time activatie, goedkeuring en meervoudige authenticatie. Dit sluit aan bij het bredere principe om menselijke controle bij AI-besluiten aantoonbaar te loggen.

De waarde van runtime-controle zit niet in het blokkeren op zichzelf, maar in het feit dat de allowlist een eigenschap wordt die zich per taak en per actie laat controleren. Een agent kan dan worden beperkt tot servers, tools en prompts die voor zijn taak zijn toegestaan, terwijl het verkeer zichtbaar wordt voor controle. Dit vraagt wel om onderhoud: de allowlist moet meebewegen met de taken die agents daadwerkelijk uitvoeren, anders ontstaat er ofwel te veel toegang, ofwel verkeer dat buiten de bekende paden om loopt.

Wat zegt onderzoek over de praktijk?

Onderzoek uit september 2026 toont aan dat 94% van IT- en securityleiders vertrouwen heeft dat agents niet te veel toegang hebben, terwijl slechts ongeveer een derde daarvan daadwerkelijk runtime-autorisatie controleert. Dit gat tussen vertrouwen en werkelijke toepassing is het eigenlijke probleem. Het verschil wordt pas kleiner wanneer allowlists, goedkeuringen en logs onderdeel worden van de dagelijkse werkstroom in plaats van eenmalige configuratie.

De gereedschappen voor runtime-controle zijn beschikbaar, maar dichten het gat niet vanzelf. Wat tooling kan dragen — zichtbaarheid, beleidshandhaving, logging — is duidelijk. Wat uw eigen professionele oordeel blijft, is hoe u de allowlist onderhoudt, welke acties u als gevoelig markeert voor just-in-time goedkeuring, en hoe u de logs integreert in uw governance-werkstroom. Runtime-controle is een eigenschap die u actief moet beheren.