Je hebt opgeschreven wat je AI-agent mag. Alleen weet niemand wie hij is.

Vraag wie er vannacht in je systemen heeft gewerkt en je krijgt een lijst met namen van medewerkers. Draait er een AI-agent in je Slack, je CRM of je boekhouding, dan staat hij niet op die lijst. Hij handelde onder de naam van de medewerker wiens inlog hij leende, of onder een naamloos service-account dat niemand op zijn eigen naam heeft staan.

Dat is het echte gat, en het is een ander gat dan waar de meeste ondernemers wakker van liggen. De zorg gaat bijna altijd over wat een agent doet: dat hij hallucineert, een verkeerde offerte verstuurt, een betaling vrijgeeft die niet mocht. Belangrijk, maar te ondervangen. De stillere vraag is: onder wiens naam deed hij het? Mijn stelling is dat die vraag nu de belangrijkste is geworden. Niet wat je AI-agent mag, maar wie hij is. Zolang hij op jouw identiteit leunt, heb je geen grip op wie er namens je handelt, ook al staat haarfijn op papier wat hij mag.

Een agent-identiteit is het eigen, verifieerbare account waaronder een AI-agent handelt: los van de medewerker die hem inschakelt, afgebakend tot precies de rechten die zijn taak vraagt, met een eigen logspoor en een eigen uit-knop. Ontbreekt die, dan leunt de agent op geleende sleutels. Dan kun je achteraf niet zien wie iets deed, en niet ingrijpen zonder een mens te raken.

Dit is geen theorie meer. In een paar weken tijd is er een hele identiteitslaag voor agenten uit de grond gestampt, en dat is precies het signaal dat de rest van de markt nu volgt.

Een mandaat zonder eigen naam heeft geen anker

De afgelopen maanden ging het gesprek over agent-governance vooral over grenzen: wat mag de agent zelfstandig, waar moet hij stoppen en escaleren. Terecht. Je kunt haarfijn afbakenen wat een agent zelfstandig mag en vanaf welke drempel hij een mens om akkoord vraagt. Maar een mandaat werkt alleen als het ergens aan vastzit. En dat anker is een identiteit.

Denk aan hoe je het bij een mens doet. Een nieuwe medewerker krijgt een eigen account, eigen rechten, een eigen inlog. Niet omdat je hem wantrouwt, maar omdat je anders niet kunt zien wie wat deed, en niet iemand de deur kunt wijzen zonder de rest te raken. Bij een AI-agent wordt die stap massaal overgeslagen, omdat het "software" heet. De agent krijgt de token van een medewerker, of een gedeeld service-account waar het halve team de sleutel van heeft. Het gevolg: in je logboek staat een mens waar een agent handelde, en de toegang van die agent intrekken betekent de medewerker eruit gooien.

Dat is geen randgeval meer, het wordt de norm. In organisaties staan er inmiddels 82 machine-identiteiten tegenover elke menselijke, en heeft 42 procent daarvan gevoelige of geprivilegieerde toegang. Die machine-identiteiten zijn precies de service-accounts, tokens en agenten waar niemand een gezicht bij heeft. Een agent is er daar één van, en de meeste bedrijven kunnen ze nu al niet zien. Dit los je niet op met een beter model of een strakker mandaat. Je lost het op met een identiteit.

Identiteit voor agenten ging in weken van idee naar infrastructuur

Wat dit meer dan een principekwestie maakt: de infrastructuur om een agent een eigen identiteit te geven is er nu, en ze komt hard. In een paar weken tijd zag ik vier bewegingen die dezelfde kant op wijzen.

Anthropic en Okta maakten hun Enterprise-Managed Authorization voor het Model Context Protocol stabiel: een beheerder zet een AI-connector één keer aan, medewerkers erven de toegang bij het inloggen, afgebakend tot hun rol, en die toegang vervalt weer zodra iemand vertrekt. Aaron Parecki, hoofd identiteitsstandaarden bij Okta, vat het doel droog samen: door dit protocol in te bouwen verandert identiteit in de centrale plek waar je alle toegang bestuurt.

De Linux Foundation ging een laag dieper en kondigde de Agent Name Service aan, die de identiteit van een agent verankert in het DNS dat wereldwijd al ruim honderd miljoen verzoeken per seconde verwerkt, met Cloudflare, GoDaddy, Cisco en Salesforce eromheen. Google en Microsoft schaarden zich achter een open standaard waarmee agenten elkaars tools en skills kunnen vinden en verifiëren. En Estland werd het eerste land dat autonome agenten een eigen digitale identiteit toekent, zodat er juridisch iets vastligt over wie verantwoordelijk is.

Vier partijen, van een identiteitsleverancier tot een natiestaat, die in dezelfde weken tot dezelfde conclusie komen: een agent heeft een eigen identiteit nodig. Zelfs de identiteitssector herprijst zichzelf eromheen. Beheerder SailPoint kocht het Israëlische Entro om elke niet-menselijke identiteit en AI-agent in een bedrijf zichtbaar te maken. Als het probleem denkbeeldig was, kocht niemand er een bedrijf voor.

Een eigen identiteit is een keuze van vijf minuten, geen compliance-programma

Nu klinkt "identiteitsinfrastructuur voor agenten" als iets voor een securityafdeling met een eigen budget. Dat is het niet, of het hoeft het niet te zijn. De kern is een gewoonte, geen platform.

Concreet: geef de agent zijn eigen account, niet dat van een medewerker. Ken hem precies de rechten toe die zijn taak vraagt, niet meer. Mag hij in je CRM meekijken, geef hem leesrechten, geen schrijfrechten. Zorg dat zijn acties onder zijn eigen naam in het logboek komen. En zorg dat je zijn toegang kunt intrekken zonder dat een mens erdoor stilvalt. Dat is dezelfde discipline als een uitzendkracht inwerken: je geeft hem een eigen pasje, geen kopie van dat van jou.

Doe je dat, dan wordt de rest ineens uitvoerbaar. Dezelfde AI die als vast teamlid meedraait in de Slack of Teams die je toch al gebruikt is dan geen anonieme kracht meer die jouw sleutels leent, maar een herkenbare met een eigen dossier. Het mandaat dat je opschreef krijgt een anker: je kunt het afdwingen, want je weet precies wie je begrenst. De praktische kant, hoe je een agent stap voor stap invoert en het toegangsbeheer inricht, is niet het moeilijke deel. Het moeilijke deel is de gewoonte om het te doen vóórdat de agent live gaat, niet erna.

Om eerlijk te zijn: is dit geen enterprise-theater?

Het sterkste tegenargument, en ik betrap mezelf er ook op: voor mijn ene agent die alleen mijn agenda leest, is een DNS-verankerde identiteit met juridische entiteits-identifiers volstrekte overkill. Dat klopt. Je hoeft geen Agent Name Service te draaien voor een leesactie in je agenda, en wie doet alsof elk bedrijf morgen zo'n standaard nodig heeft, verkoopt vooral angst.

Maar daar gaat het niet om. De valkuil zit niet in het ontbreken van zware infrastructuur, hij zit in de default. En de gevaarlijke default is niet "geen Agent Name Service", het is "de agent gebruikt mijn inlog". Dat laatste kost je niets om te vermijden en levert je meteen het zicht en de uit-knop op. Een eigen, afgebakend account aanmaken is een handeling van vijf minuten, geen programma. De zware standaarden van Okta, de Linux Foundation en Google maken op wereldschaal afdwingbaar wat jij lokaal met één account al kunt doen. Ze overslaan is niet "klein en pragmatisch beginnen", het is het fundament weglaten waar je mandaat op hoort te rusten.

Slot: wie geen naam geeft, houdt een vreemde over

De vraag "wat mag mijn agent" is de makkelijke. Het antwoord staat op papier, in een mandaat dat je in een middag opstelt. De vraag "onder wiens naam handelt hij" is de moeilijke, en het eerlijke antwoord is nu nog te vaak: onder de mijne.

Identiteit is niet de bureaucratie die ná de agent komt. Het is de voorwaarde eronder. Geef je een agent geen eigen naam, dan heb je geen kracht die werk van je overneemt, maar een die zich voordoet als iemand anders, wiens acties je niet kunt terugvinden en niet kunt stoppen zonder een collega te raken. Dat is precies het profiel van de medewerker die je nooit zou aannemen. Het verschil tussen delegeren en de controle weggeven is één ding: of je hebt vastgelegd wie er namens je handelt.