Het account van een medewerker
De agent logt in als Merel en erft alles wat Merel mag.
Wat er gebeurt: In het logboek staat Merel. Gaat Merel weg, dan valt de agent stil of blijft haar toegang openstaan.
Kennisbank / AI-agent met een eigen identiteit
Waarom een AI-agent een eigen identiteit nodig heeft.
AI-governance · gids 8 min lezen augustus 2026 Door Geoffrey
De meeste AI-agents draaien vandaag onder het account van een medewerker. Dat werkt prima tot het moment dat je wilt weten wie iets gedaan heeft, of tot die medewerker uit dienst gaat.
01 · het principe
Een agent is geen medewerker en geen script.
Als je een collega aanneemt, krijgt die een eigen account. Als je een koppeling bouwt tussen twee systemen, krijgt die een technische sleutel. Een AI-agent zit daar tussenin: hij handelt zelfstandig zoals een mens, maar hij is er geen, en hij draait continu zoals een script, alleen met eigen oordeel over wat hij doet.
In de praktijk kiest bijna iedereen de snelste route. De agent krijgt het account van degene die hem heeft ingericht, of een sleutel die toch al ergens rondslingerde. Dat werkt, en het houdt op te werken op precies de drie momenten waarop je erop moet kunnen bouwen: als er iets misgaat, als iemand vertrekt, en als je moet uitleggen wat er gebeurd is.
Kern
Een agent-identiteit betekent dat deze specifieke agent een eigen naam heeft in je systemen, met eigen rechten. Je kunt daardoor per agent bepalen wat is toegestaan, hem los intrekken, en achteraf nagaan wat hij gedaan heeft.
Dat klinkt als iets voor grote organisaties. De onderliggende vraag is dat niet. Zodra je een tweede agent hebt die andere dingen mag dan de eerste, heb je een manier nodig om dat verschil vast te leggen.
02 · vier manieren
Vier manieren waarop een agent toegang krijgt.
Ze worden vaak door elkaar gehaald, en het verschil bepaalt wat er gebeurt als er iets misgaat.
Een gedeelde API-key
Eén sleutel die in alle scripts en agents zit.
Wat er gebeurt: Iedereen die de sleutel heeft, is dezelfde. Intrekken raakt meteen alles wat er ook op draait.
Een service account
Een technisch account voor een systeem, niet voor een mens.
Wat er gebeurt: Beter, en meestal veel te ruim ingesteld. Vaak is er één service account voor alles wat automatisch draait.
Een agent identity
Deze specifieke agent krijgt een eigen identiteit met eigen rechten.
Wat er gebeurt: Je kunt per agent bepalen wat mag, hem apart intrekken, en achteraf zien wie wat deed.
03 · het risico
Wat er misgaat als je het overslaat.
Je weet achteraf niet wie wat deed
Een agent die onder Merels account werkt, laat in elk logboek Merels naam achter. Wordt een offerte met het verkeerde bedrag verstuurd, dan kun je niet vaststellen of Merel zich vergiste of dat de agent iets verkeerd las. Dat verschil bepaalt wat je erna repareert: een proces of een instructie.
De agent mag te veel, en niemand koos dat
Rechten worden geërfd, niet toegekend. Een agent die alleen facturen hoeft te lezen, kan bij alles waar de medewerker bij kan. Niemand heeft besloten dat de offerte-agent in de personeelsmap mag kijken, het is er gewoon bij gekomen. Dat wordt pas zichtbaar als er iets gebeurt wat niemand verwachtte.
Iemand vertrekt en er valt van alles om
Bij offboarding zet je een account uit. Draaide daar een agent onder, dan stopt die stil, vaak zonder melding. Het omgekeerde komt ook voor: het account blijft open omdat er nog iets op draait, en dan houdt een vertrokken medewerker formeel toegang. Beide zijn te voorkomen door de agent een eigen identiteit te geven.
Eén fout raakt meteen alles
Bij één gedeelde sleutel is intrekken een grove ingreep. Je zet niet de agent stil die zich misdroeg, je zet alles stil wat op die sleutel draait. Per agent een eigen identiteit maakt van een noodstop een gerichte handeling.
De vuistregel: kun je van één handeling in je systemen niet vaststellen of een mens of een agent hem deed, dan is de identiteitslaag nog niet op orde.
04 · wat er nu verandert
Drie leveranciers, één week, dezelfde beweging.
Dit onderwerp was tot voor kort iets voor architectuurdocumenten. In de week van 20 tot 27 augustus 2026 bewogen drie grote partijen binnen vijf dagen dezelfde kant op.
Google gaf de agent een eigen identiteit
Op 22 augustus 2026 werden de Agent Identity auth manager en de bijbehorende API's algemeen beschikbaar. Daarmee krijgt een agent een eigen security principal en haalt hij per systeem een apart, beperkt token op, in plaats van mee te liften op de rechten van een gebruiker. Bron: de IAM release notes van Google Cloud.
Anthropic haalde de autorisatie weg bij de medewerker
Op 24 augustus 2026 werd enterprise-managed authorization voor MCP-connectors algemeen beschikbaar. Beheerders regelen de toegang tot gekoppelde tools centraal via de identity provider van de organisatie, en de gebruiker doorloopt niet langer per koppeling een eigen akkoordscherm. Bron: Anthropic over enterprise-managed auth.
Microsoft schreef op hoe je de grenzen zet
In bijgewerkte documentatie bij het Agent Framework adviseert Microsoft om te beginnen met het krapste permissiemodel en expliciete goedkeuring te eisen voor alles wat schrijft, verstuurt of het netwerk op gaat. Over credentials staat er letterlijk:
"Don't expose credentials through environment variables or readable files in the agent working directory."
Microsoft Learn, Anthropic Claude in Agent Framework, sectie Permission considerations.
Twee routes dus, en de eerste wordt het vaakst gemist. Een omgevingsvariabele voelt niet als een bestand, terwijl een agent met shell-toegang hem net zo makkelijk uitleest. Waar de sleutel dan wel hoort, laat Microsoft op deze pagina open. In de praktijk komt het neer op een secret store die de sleutel pas op het moment van gebruik aanreikt, buiten het bereik van de agent zelf.
Eerlijk over de reikwijdte
Deze drie zijn gebouwd voor organisaties met een centrale identity provider zoals Okta. Voor een bedrijf van tien man is dat vandaag geen realistische stap. Wat er wel toe doet, is de richting: de vraag verschuift van of een agent bij iets kan naar onder welke naam en met welke rechten. Die vraag kun je nu al beantwoorden, ook zonder dat gereedschap.
05 · aan de slag
Vijf stappen die vandaag al kunnen.
Zonder identity provider, zonder enterprise-abonnement. Dit is het deel waar de meeste winst zit.
Schrijf op welke agents er zijn
Klinkt flauw en is het niet. Bij de meeste bedrijven weet niemand precies welke automatische processen er draaien en onder wiens naam.
Geef elke agent een eigen inlog
Geen gedeelde sleutel en niet het account van een collega. Eén agent, één identiteit, ook als dat voorlopig gewoon een apart account is.
Zet de rechten zo krap als het werk toelaat
Begin bij lezen. Schrijven en versturen voeg je pas toe als blijkt dat het nodig is, en dan alleen voor die ene plek.
Leg een menselijke poort op wat onomkeerbaar is
Versturen, verwijderen, betalen en publiceren gaan langs een mens. De agent bereidt voor, jij keurt goed.
Zorg dat je achteraf kunt kijken
Als je niet kunt nagaan welke agent wat deed, kun je een fout ook niet begrenzen. Bewaar wie, wat en wanneer.
Stap 1 levert bijna altijd een verrassing op. Wie de lijst maakt, vindt processen die niemand meer wist, onder de naam van iemand die er soms niet meer werkt.
Veelgestelde vragen · 06
Goed om te weten.
Waarom is het account van een medewerker geen goede oplossing?
Omdat de agent dan alles mag wat die medewerker mag, en het logboek de verkeerde naam laat zien. Een agent die facturen mag inzien erft ook toegang tot de personeelsmap, simpelweg omdat de medewerker die heeft. Gaat iemand uit dienst, dan valt de agent stil of blijft de toegang openstaan. Beide zijn vervelend, en het tweede is een risico. Er is nog een praktisch gevolg. Zodra iemand het wachtwoord van die medewerker wijzigt of tweefactor aanzet, valt de agent om, meestal op het slechtst denkbare moment. Een eigen account met een eigen sleutel heeft dat probleem niet, en je kunt hem intrekken zonder dat een mens zijn werk kwijtraakt. Begin daarom bij de eerste agent al met een apart account, ook wanneer het er voorlopig maar één is. Het kost bij de eerste inrichting een half uur en bespaart je later een zoektocht.
Heb ik dit nodig als ik één agent draai?
Waarschijnlijk niet meteen. Bij één agent die concepten voorbereidt en niets definitief maakt, is het risico beperkt. Het gaat wringen zodra een agent zelfstandig iets verstuurt of wijzigt, of zodra er een tweede en derde bijkomen die van elkaar verschillen in wat ze mogen. Dan wil je per agent kunnen zeggen wat is toegestaan. Eén uitzondering zou ik meteen regelen: zodra een agent bij persoonsgegevens komt. Dan wil je bij een vraag van een klant of bij een controle kunnen laten zien wie wat heeft ingezien, en dat kan alleen wanneer de agent van de mens te onderscheiden is. Voor de rest geldt een simpele vuistregel: richt een eigen account in zodra het tweede proces erbij komt, want daarna wordt terugbouwen duurder dan vooruit bouwen. Achteraf rechten uit elkaar trekken vraagt namelijk dat je van elke bestaande handeling uitzoekt wie hem deed.
Kan een MKB-bedrijf dit al inrichten?
Deels. De volwaardige vorm met een centrale identity provider is op dit moment enterprise-gereedschap en vraagt Okta of iets vergelijkbaars. Wat elk bedrijf wel kan: per agent een eigen account of sleutel gebruiken in plaats van een gedeelde, de rechten daarvan minimaal houden, en vastleggen welke agent wat mag. Dat is negentig procent van de winst voor een fractie van het werk. Praktisch begin je met drie dingen. Geef elke agent een eigen inlog of API-sleutel in plaats van een gedeelde. Zet de rechten op het minimum dat de taak nodig heeft en niet op wat handig is. En houd één lijst bij met welke agent bestaat, wat hij doet en wie hem beheert. Op die lijst sluit een identity provider later aan, en zonder die lijst is elk gereedschap zinloos. Een spreadsheet volstaat om te beginnen.
Wat is het verschil met gewoon een wachtwoord goed bewaren?
Bewaren gaat over of iemand erbij kan. Identiteit gaat over wie iets deed en wat diegene mocht. Ook met een perfect bewaard wachtwoord weet je achteraf niet of die factuur door een mens of door een agent is aangepast, zolang ze dezelfde inlog delen. Dat onderscheid heb je nodig zodra er iets misgaat. Dat merk je pas op het moment dat er iets misgaat, en dan is het te laat om het alsnog in te richten. Stel dat een factuur verkeerd is aangepast: met gedeelde inloggegevens weet je alleen dát het gebeurde, niet door wie of wat. Met een eigen identiteit lees je in het logboek of de agent het deed en of hij dat mocht. Dat is het verschil tussen een incident dat je oplost en een incident dat je moet reconstrueren. Bewaren en identiteit zijn dus twee losse vragen.
Moet elke agent dan een eigen abonnement hebben?
Nee. Het gaat om een eigen identiteit binnen de systemen waar de agent bij mag, niet om aparte licenties overal. Je richt één plek in waar staat welke agent bestaat en wat die mag. Concreet ziet dat er zo uit: je AI-abonnement blijft één abonnement, en de agent krijgt zijn eigen gebruiker in je CRM, je boekhouding en je bestandsopslag. Wat die lijst je oplevert is overzicht en geen automatische intrekking. Een gedeeld document weet niets van je CRM, dus schrappen uit de lijst haalt daar geen toegang weg. Intrekken doe je in elk systeem apart, en de lijst vertelt je wélke systemen dat zijn. Wie het wél in één handeling wil, heeft een identity provider met koppelingen naar die systemen nodig, en dat is voorlopig enterprise-gereedschap. Voor een MKB-bedrijf is de lijst dus een checklist bij het afscheid nemen van een agent. Onze gids over agentic workflows beschrijft hoe die poorten in een proces passen.
Verder in de kennisbank
Lees ook deze gidsen.
Weet jij onder wiens naam je agents draaien?
We lopen je automatiseringen langs, brengen in kaart wie waar bij kan en zetten de rechten terug naar wat het werk vraagt.
Draait er nog niets automatisch? Begin dan bij AI-agents voor het MKB en kom hier terug zodra de eerste agent er staat.