Geef je AI-stafchef een eigen service-identiteit, niet de OAuth-rechten van je oprichter

Een oprichter zet zijn nieuwe AI-stafchef op. Hij koppelt 'm aan zijn eigen Gmail, zijn eigen agenda, zijn HubSpot, zijn Stripe. Hij klikt door alle OAuth-schermen heen, geeft overal toestemming, en binnen tien minuten draait het. Het werkt. Het voelt productief.

En precies daar begint het probleem.

Wat er feitelijk gebeurt: de agent erft alle rechten van die mens. Niet de rechten die hij voor zijn taak nodig heeft — álle rechten. De volledige inbox, de complete dealpipeline, het betaaldashboard. Een menselijk account heeft brede, blijvende toegang opgebouwd over jaren. Die geef je in één klik door aan een autonoom systeem dat op machinesnelheid handelt.

Ik zie dit niet als een randgeval. Dit is de standaardmanier waarop mensen nu beginnen. En het is precies de manier die de hele beveiligingswereld in 2026 als onaanvaardbaar bestempelt.

Stel je voor: er gaat iets mis. Een gevoelig document is gedeeld dat niet gedeeld had mogen worden. Een betaling is geïnitieerd. Een mail is verstuurd naar de verkeerde contactpersoon in je CRM.

Je duikt in de logs. En daar staat: de oprichter heeft het gedaan. Want de agent draaide op zijn account. Er is geen technisch onderscheid tussen wat de mens deed en wat de AI deed. De acties zijn niet uit elkaar te trekken.

Dat is geen ongemak. Dat is het einde van je accountability. In gereguleerde omgevingen leidt dit rechtstreeks tot audit-mislukkingen en compliance-overtredingen. Toezichthouders eisen steeds nadrukkelijker functiescheiding, traceerbaarheid van handelingen en least-privilege-toegang. Een vervaagde grens tussen mens en AI ondermijnt alle drie tegelijk.

Een eigen service-identiteit draait dit om. Elke handeling van de agent is herleidbaar tot díe identiteit. Je krijgt een granulaire audittrail, je kunt forensisch onderzoek doen, je kunt compliance aantonen. Je weet wie wat deed — ook als 'wie' een machine is.

Even de cijfers die de urgentie scherp maken, want die zijn niet zacht.

Niet-menselijke identiteiten — service-accounts, agents, bots — zijn menselijke identiteiten in de gemiddelde onderneming al 50 tot 144 keer in aantal voorbij. En die verhouding stijgt snel. 80% van de IT-leiders meldt dat agents zich buiten het verwachte gedrag begeven. 88% van de organisaties rapporteerde het afgelopen jaar bevestigde of vermoede beveiligingsincidenten met AI-agents. 97% van de security-leiders verwacht dit jaar een serieus incident dat door een AI-agent wordt veroorzaakt.

En dan dit: slechts 6% van de securitybudgetten gaat momenteel naar AI-agent-risico. Er wordt voorspeld dat meer dan 40% van de agentic-AI-projecten vóór 2027 wordt geannuleerd door onvoldoende risicocontroles.

Dat laatste raakt operators direct. Het is niet de hack die je project stillegt — het is het ontbreken van governance waardoor je het niet meer durft uit te rollen. Je AI-stafchef stagneert niet omdat hij slecht is, maar omdat niemand kan uitleggen wie waarvoor verantwoordelijk is.

Een service-identiteit voor een AI-agent is een unieke, cryptografisch verifieerbare digitale identiteit. Los van menselijke accounts. Los van die oude statische service-accounts waar een wachtwoord in een config-bestand stond.

Het kenmerk dat ertoe doet: hij wordt dynamisch toegekend en is afgebakend tot de taak en context van dat moment. Je AI-stafchef die je agenda beheert heeft een identiteit met scopes voor Calendly en je agenda — en verder niets. Je agent die dealopvolging in Pipedrive doet, krijgt leesrechten op die pipeline, geen schrijftoegang tot Stripe.

Dit is het principe van least privilege, concreet gemaakt. Tijdgebonden toegang, just-in-time toegekend. Geen permanente brede rechten die maandenlang blijven hangen.

En het lost een probleem op dat bijna niemand ziet aankomen: de levenscyclus. Mensen hebben joiner-, mover- en leaver-processen. Agents hebben een heel andere, vaak veel kortere levensduur. Als je een agent aan een menselijk account koppelt, blijven zijn rechten bestaan nadat de agent allang is uitgefaseerd of hergebruikt. Verweesde credentials, sluimerende toegang. Met een eigen identiteit kun je geautomatiseerd provisioneren bij aanmaak, secrets roteren, en intrekken bij beëindiging.

Laat ik het concreet maken, want hier draait het bij operators om.

Neem een oprichter met de typische stack: Gmail of Outlook voor mail, Slack voor interne communicatie, HubSpot voor het CRM, Linear voor de productroadmap, Notion voor documenten, Stripe voor betalingen. Eén AI-stafchef die hier dwars doorheen werkt klinkt aantrekkelijk — maar dat is precies de blast radius waar je niet aan wilt.

Deel het op. Geef de agent die je inbox triageert een eigen identiteit met scopes die beperkt zijn tot mail lezen en concepten opstellen — niet versturen zonder bevestiging. Geef de agent die je Linear-issues en Notion-notities bijhoudt een aparte identiteit zonder enige toegang tot je CRM of je betalingen. Registreer elke agent in je identity provider of een agent-register, met duidelijke eigenaar, doel en scope.

Het voordeel dat je dan krijgt: runtime-autorisatie. Je kunt het gedrag van een agent in realtime monitoren en een sessie beëindigen of escaleren naar menselijke goedkeuring zodra er iets afwijkends gebeurt. Wanneer de mailagent ineens probeert een betaling te initiëren, blokkeer je dat op intentieniveau — niet pas achteraf in de logs.

Bij Moments denken we hier expliciet over na: een AI-stafchef die ingebed zit in mail, agenda, contacten, documenten en browser is precies het type agent dat je niet op een geleende menselijke login wilt laten draaien. Hoe nuttiger de agent, hoe groter de reden om zijn identiteit netjes af te bakenen.

Het verleidelijke aan de menselijke-account-route is de snelheid. Tien minuten en het draait. Het verleidelijke aan service-identiteiten lijkt traagheid: opzetten, scopes bepalen, registreren.

Maar de technologie en best practices hiervoor zijn volwassen en goed gedocumenteerd. Dit is geen onderzoeksproject. De kosten van niets doen — incidenten, boetes, verloren wendbaarheid — wegen ruim zwaarder dan de investering om het goed te doen.

Mijn standpunt is hier niet genuanceerd, en dat hoeft ook niet. Een directie-agent koppelen aan een menselijk account is in 2026 een kritiek, onaanvaardbaar risico. Het ondermijnt accountability, maakt privilege-escalatie mogelijk, breekt je levenscyclusbeheer en faalt op zowel regelgeving als operationele eisen.

De goede manier is per agent een eigen, beheerde service-identiteit, met minimale scopes, eigen secrets en intrekbare toegang. Niet omdat het netjes is, maar omdat je anders geen echte governance, geen incidentrespons en geen audittrail hebt. En zonder die drie heb je geen AI-stafchef waar je je bedrijf op durft te leunen.