Een medewerker vraagt een AI-agent om een leverancierscontract samen te vatten. De agent leest het document, zoekt ontbrekende gegevens op in SharePoint, vergelijkt clausules met eerdere contracten en zet alvast een conceptmail klaar voor Inkoop. Op papier heeft de medewerker daar toestemming voor. In de praktijk heeft de agent intussen meerdere systemen, databronnen en handelingen met elkaar verbonden.
Daar zit de nieuwe ongemakkelijke werkelijkheid. We beveiligen niet langer alleen de gebruiker die toegang vraagt. We moeten ook beoordelen welke afzonderlijke actie een agent uitvoert, met welke gegevens, namens wie, met welk doel en met welk mogelijk gevolg. Zero Trust voor AI-agents verschuift de grens van toegang naar iedere actie.
Dat is geen kleine uitbreiding van bestaand identity- en accessmanagement. Een agent is geen medewerker met een wachtwoord en ook geen traditioneel script dat exact doet wat de programmeur ooit heeft bedacht. Het is een systeem dat op basis van context stappen kiest. Wie alleen controleert of de agent “binnen mag”, heeft het moeilijkste deel van de beveiliging nog niet ingericht.
Een identiteit is niet hetzelfde als een rechtvaardiging
Zero Trust heeft terecht afgerekend met het idee dat iets binnen het netwerk automatisch vertrouwd is. Identiteit, apparaat, context en minimale rechten werden belangrijker dan de locatie van een gebruiker. Maar bij agents ontstaat een extra probleem: een geldige identiteit zegt nog steeds weinig over de legitimiteit van de volgende handeling.
Een agent kan namens een medewerker toegang hebben tot een klantdossier. Dat betekent niet automatisch dat hij een dossier mag kopiëren naar een extern systeem, een wijziging mag opslaan of een bericht naar een klant mag versturen. De identiteit beantwoordt de vraag wie de actie uitvoert. Zij beantwoordt niet de vraag of die actie nu, op deze manier en met deze gegevens gerechtvaardigd is.
Daarom is een centrale vraag in agentbeveiliging niet langer alleen: mag deze entiteit dit systeem gebruiken? De betere vraag is: mag deze entiteit deze specifieke handeling uitvoeren, onder deze omstandigheden, met dit risico? Dat verschil klinkt theoretisch totdat een agent met één brede serviceaccount toegang krijgt tot alle informatie die voor een deel van zijn taken handig lijkt.
Van sessiecontrole naar actieregie
Bij klassieke toegang ligt het beslismoment vaak aan het begin van een sessie. De gebruiker logt in, krijgt rechten en werkt vervolgens binnen een bepaald kader. Bij een agent is dat kader veel minder stabiel. Een ogenschijnlijk eenvoudige opdracht kan leiden tot tientallen tool-aanroepen, zoekacties, bestandstransfers en mutaties.
Elke stap kan de risicoklasse veranderen. Een zoekopdracht in een interne kennisbank is iets anders dan het ophalen van persoonsgegevens. Een conceptdocument maken is iets anders dan een contract definitief opslaan. Een conceptmail klaarzetten is iets anders dan die mail verzenden. Toch worden die handelingen in veel ontwerpen behandeld alsof ze allemaal onder dezelfde toestemming vallen.
Dat is precies waar het misgaat. Een agent die een doel mag bereiken, krijgt te gemakkelijk vrijheid over de route ernaartoe. Maar het doel “help mij met deze klantvraag” is geen blanco cheque voor het lezen van alle klantdata, het aanpassen van stamgegevens of het versturen van een antwoord zonder controle.
Actieregie betekent dat organisaties rechten opdelen naar handeling en impact. Niet alleen lezen of schrijven, maar ook exporteren, delen, publiceren, verwijderen, financieel verplichten en een proces in beweging zetten. Hoe groter en minder omkeerbaar het effect, hoe zwaarder de controle moet zijn.
De agent is niet de enige die je moet wantrouwen
Het is verleidelijk om vooral naar het model te wijzen. Kan het hallucineren? Kan het een verkeerde instructie volgen? Kan een document een manipulatieve opdracht bevatten? Dat zijn terechte vragen, maar ze leiden soms af van een fundamenteler ontwerpprobleem: de agent krijgt vaak te veel mogelijkheden omdat de organisatie haar eigen systemen te grof heeft ontsloten.
Een promptinjectie is pas echt gevaarlijk als een agent daarna een waardevolle actie kan uitvoeren. Een foutieve interpretatie wordt pas een incident als er geen begrenzing zit tussen advies en uitvoering. De technische zwakte van het model en de organisatorische zwakte van de autorisatie versterken elkaar.
Daarom hoort iedere tool-aanroep een eigen veiligheidscontext te hebben. Welke bron wordt geraadpleegd? Welke gegevens gaan de grens over? Is de actie alleen informatief of verandert zij de werkelijkheid? Is de opdracht afkomstig van de gebruiker, uit een document of uit een eerdere stap van de agent? En kan de handeling worden teruggedraaid?
Wie dat niet vastlegt, heeft geen autonome assistent gebouwd maar een geautomatiseerde bevoegdheidsketen. Dat klinkt indrukwekkend in een demonstratie en buitengewoon onverstandig tijdens een incident.
Menselijke goedkeuring is geen magische knop
Een veelgehoorde reactie is dat een mens de risicovolle acties wel goedkeurt. Dat is verstandig, maar alleen als die goedkeuring betekenis heeft. Een scherm met “Agent wil actie uitvoeren, akkoord?” is geen controle als de medewerker niet ziet welke gegevens worden gebruikt, welk resultaat wordt opgeslagen en wat de gevolgen zijn.
Menselijke controle werkt alleen wanneer de agent het besluit begrijpelijk maakt. Niet door een lang technisch logboek te tonen, maar door de relevante context te geven: dit is het doel, dit zijn de bronnen, dit verandert er, dit is onzeker en dit is niet terug te draaien. Anders wordt de mens de laatste klik in een proces dat hij niet meer kan overzien.
Bovendien is goedkeuring niet voor iedere stap nodig. Wie elke onschuldige leesactie laat bevestigen, creëert vooral goedkeuringsmoeheid. De grens moet liggen bij impact, gevoeligheid en onomkeerbaarheid. Een agent mag best zelfstandig een samenvatting maken. Een agent die een betaling initieert, een personeelsdossier wijzigt of externe communicatie publiceert, hoort aan strengere voorwaarden te voldoen.
Dat vraagt om duidelijke verantwoordelijkheden. De proceseigenaar bepaalt wat de handeling betekent. IT en security bepalen hoe de grens technisch wordt afgedwongen. De gebruiker is niet automatisch eigenaar van de gevolgen alleen omdat hij de opdracht gaf.
Logging moet het verhaal van de actie vertellen
Veel organisaties loggen al wie toegang had tot een systeem. Voor agents is dat te weinig. Een bruikbaar log moet reconstrueren hoe een actie tot stand kwam: welke gebruiker gaf de opdracht, welke agent nam het werk over, welke instructies en bronnen waren relevant, welke tools zijn aangeroepen en welk resultaat is geproduceerd.
Dat is geen administratieve luxe. Zonder die keten kun je achteraf nauwelijks bepalen of een incident ontstond door een verkeerde autorisatie, misleidende broninformatie, een fout in de agentlogica of menselijk handelen. Dan resteert het bekende onderzoekspatroon: iedereen ziet iets, niemand weet precies wat er gebeurde.
Logging moet bovendien gekoppeld zijn aan actiebeleid. Een log waarin staat dat een agent een bestand heeft gelezen, helpt weinig als niet duidelijk is of die lezing volgens beleid was toegestaan. Observability zonder besluitregels is vooral een uitgebreid archief van achteraf ontdekte verrassingen.
Architectuur wordt belangrijker dan de chatbot
De verleiding blijft groot om te beginnen met de agent zelf. Welke modelkeuze, welke prompt, welke leverancier? De belangrijkere ontwerpkeuzes zitten eromheen. Welke tools zijn beschikbaar? Hoe klein kunnen bevoegdheden worden gemaakt? Welke gegevens mogen samenkomen? Waar wordt een actie onderbroken? Wie kan een agent onmiddellijk stilzetten? En hoe voorkom je dat één serviceaccount meerdere processen tegelijk vertegenwoordigt?
Daarmee wordt agentbeveiliging een architectuurvraagstuk. Niet omdat ieder bedrijf een nieuw platform nodig heeft, maar omdat bestaande grenzen vaak niet zijn ontworpen voor systemen die zelfstandig meerdere stappen zetten. API’s, workflow-engines, datarechten en logging moeten samen een controleerbare keten vormen.
Dat maakt ook leverancierskeuzes minder vrijblijvend. Een leverancier kan prima aantonen dat een agent snel antwoord geeft. Dat zegt nog niets over fijnmazige autorisatie, uitlegbaarheid, scheiding van verantwoordelijkheden of herstel na een verkeerde actie. Een demo laat meestal het succespad zien. Beveiliging begint juist bij de paden die niemand in de demo wilde tonen.
Wat is dan de echte IT-realiteit?
Zero Trust voor agents betekent niet dat iedere actie door drie commissies moet worden goedgekeurd. Het betekent dat toegang niet langer het eindpunt van vertrouwen is. Toegang is slechts de voorwaarde om een volgende beslissing te mogen nemen. De beslissing zelf moet opnieuw worden beoordeeld aan de hand van doel, context, gegevens en impact.
Dat vraagt om een ongemakkelijke verschuiving in denken. Security moet niet alleen identiteiten beheren, maar ook bevoegdheden per handeling ontwerpen. IT moet niet alleen integraties mogelijk maken, maar ook begrenzen wat een integratie kan veroorzaken. Bestuur en proceseigenaren moeten accepteren dat “autonoom” nooit hetzelfde mag betekenen als “onbegrensd”.
De organisaties die dit goed aanpakken, verbieden agents niet. Zij maken onderscheid tussen informatie ophalen, adviseren en handelen. Zij geven agents ruimte waar fouten herstelbaar zijn en eisen aantoonbare controle waar fouten geld, privacy, vertrouwen of continuïteit raken.
De echte grens van Zero Trust ligt daarom niet bij de voordeur van het systeem, maar bij elke deur die daarna nog opengaat. Een agent hoeft niet overal buiten te blijven. Hij moet alleen nergens naar binnen kunnen zonder opnieuw te bewijzen dat de volgende stap verantwoord is.