AI-agenten loggen nog steeds in als mensen – en uw audittrail betaalt de prijs
De afgelopen vier jaar hebben ondernemingen AI-agenten toegevoegd aan identiteitsinfrastructuren die daar nooit voor ontworpen waren. Dat verschil is nu zichtbaar in de data, niet alleen in incidentanalyses achteraf. Een nieuw rapport, gebaseerd op geanonimiseerde aanmeldingsactiviteit van meer dan 20.000 organisaties, laat zien dat AI-agenten zich binnen bedrijfsomgevingen grotendeels nog steeds gedragen zoals bij de komst van generatieve AI: ze worden geauthenticeerd als, of via, een mens.
Het rapport is de Okta Enterprise AI Index en is gebaseerd op aanmeldingsdata van juni 2022 tot juni 2026, verspreid over meer dan 100 verschillende AI-producten, samengevoegd tot 74 leverancierssuites voor analyse. De schaal van deze dataset maakt het moeilijk om de bevindingen af te doen als een randgeval. Dit is geen verhaal over een verkeerde configuratie van één leverancier of een overhaaste AI-implementatie bij één bedrijf. Het is een patroon bij tienduizenden organisaties die ervoor kiezen, of simpelweg standaard overstappen op, dezelfde manier van autoriseren van AI-agentworkflows.
De groeicijfers zijn opvallend. AI-native bedrijven zoals Anthropic, OpenAI en Cursor hebben hun zakelijke klantenbestand in de onderzoeksperiode meer dan verviervoudigd. Anthropic haalde OpenAI in maart 2026 in qua totaal aantal zakelijke accounts en overtrof het de maand erna in maandelijks actieve gebruikers. Deze mijlpalen weerspiegelen hoe snel agentische AI is geëvolueerd van experiment naar standaard bedrijfsoplossing. Maar de belangrijkste bevinding ligt onder deze groeicurve: identiteits- en toegangsbeheer voor AI-agenten is niet meegegroeid met de snelheid waarmee deze agenten worden ingezet.
Kiteworks veilige gegevensuitwisseling is gebouwd op een ander uitgangspunt: elke actor die gevoelige content aanraakt, mens of machine, heeft een verifieerbare identiteit nodig, afgebakende rechten en een eigen vermelding in de audittrail. Precies dat uitgangspunt ontbreekt volgens dit rapport bij de meeste zakelijke AI-implementaties van vandaag.
Belangrijkste Bevindingen
1. Adoptie van AI in ondernemingen gaat sneller dan de ontwikkeling van identiteitspraktijken.
Nieuwe aanmeldingsdata over vier jaar en meer dan 20.000 organisaties laten zien dat AI-native leveranciers hun zakelijke accounts meer dan 4x vergroten, terwijl het identiteitsmodel achter deze tools nauwelijks veranderd is sinds de pilotfase.
2. Agenten gebruiken nog steeds menselijke inloggegevens.
Serviceaccounts, statische API-sleutels en gedeelde menselijke logins blijven volgens Okta-onderzoeker Fei Liu de standaardmanier waarop organisaties AI-agentworkflows autoriseren, terwijl elk van deze methoden is ontworpen voor een wereld zonder autonome software-actoren.
3. Een geleende login betekent een gebroken audittrail.
Wanneer een AI-agent zich als een persoon authenticeert, tonen logs de naam van die persoon bij acties die deze nooit heeft uitgevoerd, waardoor het vrijwel onmogelijk wordt om te reconstrueren wat een agent daadwerkelijk heeft gedaan tijdens een incidentonderzoek.
4. De Anthropic-OpenAI race is een symptoom, niet het verhaal.
Dat Anthropic OpenAI inhaalt qua zakelijke accounts en maandelijks actieve gebruikers begin 2026 bevestigt hoe snel agentische AI doordringt tot kernprocessen, sneller dan de meeste identiteits- en toegangsprogramma’s zich hebben aangepast om dit te beheersen.
5. Agent-gebaseerde toegangscontrole dicht het gat.
Elke AI-agent een eigen beheerde identiteit, rechten en auditrecord geven, in plaats van deze via een menselijke sessie te laten lopen, is het verschil tussen een beheersbare AI-inzet en een onbeheersbare.
Je vertrouwt erop dat je organisatie veilig is. Maar kun je het bewijzen?
Lees nu
Serviceaccounts, statische API-sleutels en gedeelde logins: drie manieren waarop agentidentiteit faalt
Volgens Fei Liu, de Okta-onderzoeker uit het rapport, vertrouwen organisaties sterk op drie mechanismen om AI-agentworkflows te autoriseren: serviceaccounts, statische API-sleutels en in sommige gevallen gedeelde menselijke logins. Elk lost een kortetermijn-integratieprobleem op. Elk creëert ook een langetermijn-governanceprobleem waar de meeste organisaties nog niet mee hebben afgerekend.
Serviceaccounts zijn de meest voorkomende van de drie. Ze laten een AI-agent optreden als een aangewezen niet-menselijke identiteit binnen een applicatie, wat logisch klinkt tot je kijkt naar hoe deze accounts meestal worden ingericht en gemonitord. Veel serviceaccounts worden eenmalig aangemaakt, krijgen brede toegangsrechten om te voldoen aan alles wat de agent mogelijk ooit moet doen, en worden daarna met rust gelaten. Niemand heroverweegt de rechten als de rol van de agent groeit. Niemand koppelt individuele acties aan een specifieke taak, aanvraag of zakelijke rechtvaardiging. Het account bestaat, de agent gebruikt het, en de resulterende logs beschrijven het account in plaats van het werk. Het toepassen van dataclassificatie op de content waartoe serviceaccounts toegang hebben, is de voorwaarde die toegangsafbakening precies maakt — zonder dit kan een governanceprogramma geen gevoeligheidsgebaseerde beperkingen afdwingen op wat een agent via dat account bereikt.
Statische API-sleutels brengen vergelijkbare problemen met zich mee, versterkt door de operationele omgang ermee. Een sleutel die een agent machtigt om bestanden te lezen, een database te raadplegen of een intern systeem aan te roepen, verloopt meestal niet, roteert niet automatisch en wordt vaak gekopieerd naar configuratiebestanden, omgevingsvariabelen of, erger nog, direct in een prompt of agentcontextvenster waar deze kan worden blootgesteld, gelogd of geëxfiltreerd zonder dat iemand het merkt. Zodra die sleutel op meer dan één plek bestaat, is “wie heeft toegang” een vraag die niemand meer met zekerheid kan beantwoorden.
Het derde patroon, gedeelde menselijke logins, is het meest zorgwekkend omdat het het onderscheid tussen persoon en proces volledig opheft. De inloggegevens van een medewerker worden overgedragen aan een automatiseringsscript, bot of AI-agent, zodat deze kan handelen “als” die persoon in een systeem dat geen aparte voorziening heeft voor machine-identiteiten. Vanaf dat moment verschijnt elke actie van de agent in de logs alsof de mens deze heeft uitgevoerd. Een bevestigd datalek via een gedeelde menselijke login die een agent gebruikte, zorgt ervoor dat organisaties het datalek niet nauwkeurig kunnen afbakenen — meldingsplichten onder HIPAA, GDPR of vergelijkbare kaders gelden voor de maximaal mogelijke blootstelling, tenzij er bewijs is dat dit beperkt, bewijs dat een gemengde mens-agent audittrail niet kan leveren.
Waarom “Als een AI-agent een menselijke login erft, verlies je de audittrail” elke CISO zorgen zou moeten baren
Liu’s waarschuwing in het rapport is helder: “als een AI-agent een menselijke login erft, verlies je volledig je audittrail.” Die zin beschrijft een specifiek, technisch falen, geen vaag risico. Een audittrail is alleen nuttig als deze achteraf kan vertellen wie wat, wanneer en waarom heeft gedaan. Zodra een agent onder een menselijke sessie handelt, registreert die trail bij elk event de verkeerde actor. De naam in de log klopt. Het verhaal dat het vertelt niet.
Dit is vooral van belang op de momenten dat een audittrail daadwerkelijk nodig is: een onderzoek naar een datalek, een compliance-audit, een regulatoire vraag of een interne beoordeling van hoe gevoelige content door de organisatie is gegaan. In elk van deze scenario’s stelt iemand uiteindelijk dezelfde vraag: heeft een persoon dit gedaan, of een geautomatiseerd proces, en onder welk gezag? Als het antwoord is “we weten het niet, want de agent was ingelogd als Sarah”, loopt het onderzoek vast, verzwakt de compliance-respons en kan de organisatie niet aantonen dat ze de toegangsrechten heeft die kaders als NIST CSF, ISO 27001 en SOC 2 als basis verwachten. Een schone, op agenten toegeschreven auditlog in real time voeden aan een SIEM-platform is het operationele mechanisme dat agentattributie verandert van een forensisch hulpmiddel achteraf in een detectielaag die afwijkende agentactiviteit signaleert vóórdat een datalek plaatsvindt.
Er is ook een sluipend verlies dat zich lang voor een incident aandient: verantwoordelijkheid brokkelt geleidelijk af in de dagelijkse praktijk. Als niemand met zekerheid kan zeggen welke acties door een persoon en welke door een agent zijn uitgevoerd, worden uitzonderingsgoedkeuringen, data-access reviews en least-privilege handhaving allemaal moeilijker correct uit te voeren. Reviewers gaan brede toegang goedkeuren omdat het beperken ervan riskant voelt als ze niet kunnen isoleren wat de agent specifiek nodig heeft. Zo stapelen beveiligingslekken zich op, niet door één slechte beslissing maar door veel op het oog redelijke beslissingen bovenop een identiteitsmodel dat nooit is ontworpen om mensen te scheiden van software die namens hen handelt.
Shadow AI is eerst een identiteitsprobleem, daarna een dataprobleem
De meeste gesprekken over shadow AI gaan over waar gevoelige data terechtkomt: een niet-goedgekeurd model, een ongeautoriseerde plugin, een browserextensie die niemand heeft beoordeeld. Dat is een reële zorg, maar de Okta-data wijst op iets dat daarvoor ligt. Voordat een agent data kan verplaatsen of blootstellen, moet deze zich ergens authenticeren. Als die stap via een gedeeld account, een onbeheerde API-sleutel of een geleende login loopt, heeft de organisatie al het zicht verloren voordat de data governance vraag überhaupt opkomt.
Daarom verdient identiteit de hoofdrol in elk AI-governancegesprek, niet slechts een voetnoot onder preventie van gegevensverlies. Een agent met een afgebakende, goed beheerde identiteit is van nature beperkt: deze kan alleen bereiken wat de rol toestaat en elke actie is herleidbaar tot die specifieke agent en taak. Een agent die onder een menselijke sessie of breed geprovisioneerde serviceaccount werkt, is feitelijk niet beperkt; de daadwerkelijke reikwijdte hangt af van wat die mens of dat account kan, vaak veel meer dan de taak van de agent vereist. AI data governance programma’s die starten met beleidsdocumenten maar de identiteitsarchitectuur overslaan, lossen slechts de makkelijke helft van het probleem op. Shadow AI — agenten en AI-tools buiten elk goedgekeurd identiteitsprogramma — is het directe gevolg van dat gat: onbeheerde agenten die de organisatie niet kan zien, niet kan afbakenen en niet kan toeschrijven als er een incident plaatsvindt.
Het Kiteworks 2026 Data Security and Compliance Risk: Annual Forecast Report benoemt AI-governance als een van de belangrijkste databeveiligingsprioriteiten voor organisaties dit jaar. De Okta-bevindingen onderstrepen die conclusie vanuit een andere hoek: agentische tools zijn sneller geadopteerd dan de zero trust identiteits- en toegangsrechten die nodig zijn om ze te beheren. Supply chain risk management programma’s die identiteitsgovernance vereisten uitbreiden naar derde AI-leveranciers — dus ook voor agenten die deze leveranciers inzetten binnen klantomgevingen, niet alleen de tools die klanten zelf implementeren — dichten het supply chain identiteitsgat dat de Okta-data suggereert dat de meeste organisaties nog niet hebben afgebakend.
Hoe Kiteworks elke AI-agent een eigen verifieerbare identiteit geeft
Kiteworks benadert dit probleem vanuit hetzelfde vertrekpunt als de Okta-bevindingen: mensen en AI-agenten zijn beide volwaardige identiteiten die individueel moeten worden geauthenticeerd, geautoriseerd en gelogd, onder één governance-laag in plaats van twee gescheiden systemen. Het Kiteworks Control Plane beheert elk verzoek om gevoelige content, of dat nu van een persoon, applicatie of agent komt, via dat ene model, zodat de toegang van een agent nooit via een omweg als een geleende menselijke login of een onbeheerde serviceaccount verloopt.
De Secure MCP Server is het onderdeel dat speciaal voor dit moment is ontwikkeld. Authenticatie verloopt via OAuth 2.0, met het toegangstoken opgeslagen in de beveiligde credential store van het besturingssysteem, in plaats van ergens waar het AI-model het zelf kan lezen, kopiëren of lekken. Dat is wezenlijk anders dan een agent een statische API-sleutel of gedeeld menselijk wachtwoord geven: de agent heeft nooit een credential in handen die via een prompt, logbestand of gecompromitteerde sessie kan uitlekken. Elke handeling van de agent, of het nu gaat om het lezen van een bestand, navigeren door een map of ophalen van content voor een taak, wordt in real time getoetst aan RBAC- en ABAC-beleid en op eigen naam gelogd, niet samengevoegd tot één generieke vermelding dat een persoon het deed. Dat is het structurele antwoord op de waarschuwing van Fei Liu: als de credential nooit de beveiligde opslag verlaat en elke actie individueel wordt geautoriseerd en gelogd, is er geen gedeelde identiteit die de audittrail uit het oog kan verliezen. Het CISO-dashboard toont deze agent-level audittelemetrie in real time, zodat securityleiders het integrale zicht krijgen op alle door AI gemedieerde contenttoegang die het Okta-rapport als ontbrekend signaleert bij de meeste huidige implementaties.
Kiteworks Compliant AI past diezelfde discipline toe op wat agenten mogen zien en gebruiken, niet alleen hoe ze authenticeren. Contentniveau-beleidsafdwinging bepaalt waar een agent toegang toe krijgt of wat wordt achtergehouden, nog voordat de content het contextvenster van het model bereikt. Zo versterken de identiteitsgrens en de datagrens elkaar in plaats van dat de ene volledig afhankelijk is van de andere. Dataminimalisatie op deze laag — ervoor zorgen dat elke agent alleen het minimum aan content ontvangt dat nodig is voor de huidige taak — verkleint de impact als een agentcredential uitlekt, omdat de toegankelijke scope van de agent al beperkt is door het ontwerp.
Een agent-gebaseerd toegangscontrolemodel bouwen met RBAC en ABAC
Het oplossen van het identiteitsgat betekent verder gaan dan “heeft deze agent een credential” naar “heeft deze specifieke agent, voor deze specifieke taak, de specifieke rechten die nu nodig zijn.” Dat is een rol- en attribuutgebaseerde vraag, geen statisch provisioningvraagstuk.
Rolgebaseerde toegangscontrole (RBAC) geeft elke agent een gedefinieerde rol, afgestemd op de daadwerkelijke functie. Denk aan een samenvattingsagent die alleen leesrechten nodig heeft op de documenten die hij samenvat, of een workflow-agent die dossiers archiveert en schrijfrechten nodig heeft op één specifieke map, en verder niets. Op attributen gebaseerde toegangscontrole (ABAC: Attribute Based Access Control) voegt context toe aan die rol: de gevoeligheidsclassificatie van de content, het tijdstip van het verzoek, de inzetomgeving van de agent en de taak die deze uitvoert, bepalen allemaal of een verzoek wordt toegestaan. Samen stellen RBAC en ABAC een organisatie in staat een agent precies de toegang te geven die de huidige taak vereist, en niets wat deze misschien ooit nodig heeft — het tegenovergestelde van hoe de meeste serviceaccounts nu worden ingericht.
Dit model levert ook iets op dat het Okta-rapport als ontbrekend benoemt: een schone auditlog waarin elke vermelding de daadwerkelijke agent noemt, gekoppeld aan een echte taak, getoetst aan een actueel beleid, niet de naam van een persoon als plaatsvervanger voor werk dat hij nooit heeft gedaan. Wanneer een incidentonderzoek of compliance-audit vraagt wat er is gebeurd, staat het antwoord al correct toegeschreven in de log. Een gedocumenteerd incident response plan dat AI-agent-misfires dekt — specifiek de stappen voor het isoleren van een gecompromitteerde agentidentiteit, intrekken van credentials en afbakenen van de contenttoegang — maakt van de schone auditlog een operationeel responsmiddel in plaats van alleen een forensisch hulpmiddel.
Wat ondernemingen nu moeten doen om het AI-agentidentiteitsgat te dichten
De schaal van de Okta-dataset (vier jaar, meer dan 20.000 organisaties, meer dan 100 AI-producten) maakt duidelijk dat dit geen probleem is van alleen voorlopers of achterblijvers. Het is vrijwel universeel, wat betekent dat de meeste security- en identity-teams werk te doen hebben, ongeacht hoe volwassen hun AI-governanceprogramma al is.
Enkele startpunten volgen direct uit de bevindingen van het rapport. Inventariseer eerst elke AI-agent die momenteel actief is in de omgeving en identificeer precies welke credential elke agent gebruikt: serviceaccount, API-sleutel of menselijke login. Je kunt niet oplossen wat je niet in kaart hebt gebracht. Behandel vervolgens elke agent die via een gedeelde menselijke login authenticatie uitvoert als een onmiddellijke prioriteit voor herstel, aangezien dat patroon het ernstigste audittrailverlies veroorzaakt zoals beschreven in het rapport. Evalueer daarna of je huidige IAM-infrastructuur daadwerkelijk gescheiden, afgebakende identiteiten kan voorzien voor niet-menselijke actoren, of dat deze alleen voor mensen is ontworpen. Bouw ten slotte agenttoegangsbeslissingen rond zero trust gegevensuitwisseling principes: verifieer elk verzoek, geef minimaal noodzakelijke toegang en log het resultaat, in plaats van een agent te vertrouwen op basis van het account waar deze onder draait. Een formele risicobeoordeling die het huidige credentialtype en de rechten van elke agent in kaart brengt tegenover de daadwerkelijke taakvereisten — en identificeert waar gedeelde credentials of overgeprovisioneerde serviceaccounts onaanvaardbare blootstelling creëren — vormt de bewijsgrondslag voor een herstelstappenplan met prioriteiten.
Voor geen van deze stappen hoef je te wachten op een datalek als rechtvaardiging. De Okta-data beschrijft een structureel gat in hoe ondernemingen AI-agenten nu autoriseren, geen hypothetisch toekomstig risico. Het nu dichten, terwijl de adoptie van agentische AI nog steeds versnelt, is aanzienlijk goedkoper dan achteraf een audittrail reconstrueren en ontdekken dat deze nooit heeft bestaan.
Wil je meer weten over het geven van AI-agenten van een eigen beheerde identiteit in plaats van geleende menselijke credentials? Plan vandaag nog een persoonlijke demo.
Veelgestelde vragen
De Okta Enterprise AI Index is een rapport op basis van geanonimiseerde aanmeldingsdata van meer dan 20.000 organisaties van juni 2022 tot juni 2026, met meer dan 100 verschillende AI-producten samengevoegd tot 74 leverancierssuites. Het volgt hoe ondernemingen AI-tools adopteren en vooral hoe deze tools worden geauthenticeerd en geautoriseerd binnen bedrijfsomgevingen. Het rapport toont aan dat AI-agenten nog steeds vaak worden geautoriseerd via serviceaccounts, statische API-sleutels of gedeelde menselijke logins, in plaats van via identiteiten die specifiek aan de agent zijn toegewezen. Organisaties die hun eigen blootstelling aan dit patroon willen beoordelen, kunnen beginnen met het bekijken van hoe hun IAM-infrastructuur momenteel niet-menselijke actoren voorziet. Organisaties die onderworpen zijn aan nalevingsverplichtingen — HIPAA, GDPR, CMMC — moeten het authenticatiegat dat het Okta-rapport documenteert behandelen als een compliance-bevinding, aangezien deze kaders aantoonbare toegangsrechten en auditrecords vereisen, ongeacht of de gebruiker een mens of een agent is.
Een serviceaccount wordt meestal eenmalig ingericht met brede rechten om alles te dekken wat de agent mogelijk ooit nodig heeft, en wordt daarna zelden herzien. Dit betekent dat de agent vaak veel meer toegang heeft dan de huidige taak vereist en elke actie wordt toegeschreven aan het account in plaats van aan een specifieke, traceerbare taak. Dit doorbreekt het principe van least privilege en verzwakt de toegangsrechten die compliance-kaders van organisaties verwachten. Agent-gebaseerde identiteiten kunnen daarentegen worden beperkt tot precies wat een taak vereist. Dataminimalisatie toegepast op de scope van een serviceaccount — elke agent alleen toegang geven tot de specifieke databronnen die nodig zijn voor de toegewezen taak — is de operationele praktijk die least privilege omzet van beleidsintentie naar runtime realiteit.
Wanneer een AI-agent zich authenticeert met de inloggegevens van een persoon, wordt elke actie die de agent uitvoert gelogd onder de identiteit van die persoon, ook al heeft de persoon die acties nooit uitgevoerd. Hierdoor is het in de praktijk onmogelijk om menselijke activiteiten van agentactiviteiten te onderscheiden tijdens een beveiligingsonderzoek, compliance-audit of incident response-proces. Fei Liu van Okta beschrijft dit precies: zodra een agent een menselijke login erft, gaat de audittrail verloren omdat het record niet langer weerspiegelt wie of wat het werk daadwerkelijk heeft gedaan. Agent-gebaseerde credentials voorkomen dit door ervoor te zorgen dat elke logvermelding de daadwerkelijke actor noemt. Organisaties moeten ook verifiëren dat hun SIEM-alertconfiguraties afwijkende patronen in agent-attribuutlogvermeldingen — onverwachte toegangstijden, ongebruikelijke hoeveelheden data of verzoeken buiten de scope — behandelen als signalen met hoge prioriteit in plaats van achtergrondruis.
De Secure MCP Server is het door Kiteworks beheerde verbindingspunt voor AI-agenten die het Model Context Protocol gebruiken om toegang te krijgen tot bedrijfscontent. In plaats van een agent een statische credential te geven die deze kan vasthouden of lekken, verloopt authenticatie via OAuth 2.0 met het token opgeslagen in de beveiligde credential store van het besturingssysteem, en wordt elk verzoek in real time getoetst aan RBAC- en ABAC-beleid. Dit houdt credentials volledig buiten bereik van de agent, wat precies het faalmechanisme is dat het Okta-rapport beschrijft wanneer agenten menselijke logins overnemen. Dataclassificatie toegepast op de content die de Secure MCP Server beheert, maakt ABAC-handhaving nauwkeurig — toegangsbeslissingen kunnen op het moment van elk agentverzoek onderscheid maken tussen publieke en vertrouwelijke content, in plaats van één algemene permissie toe te passen op de volledige scope van de agent.
Niet per se. De meest urgente stap is AI-agenten te voorzien van een eigen klasse van beheerde identiteit, naast menselijke gebruikers en onder dezelfde beleidsregels, in plaats van agenten via menselijke sessies of generieke serviceaccounts te laten lopen als workaround. Kiteworks doet dit via het Kiteworks Control Plane, dat toegang, gebruik en uitwisseling van gevoelige content voor zowel mensen als agenten onder één set beleidsregels beheert, gecombineerd met RBAC– en ABAC-controles afgestemd op de daadwerkelijke taak van elke agent. Een risicobeoordeling die in kaart brengt welke agenten momenteel via gedeelde credentials werken — en herstel prioriteert op basis van de gevoeligheid van de content waartoe deze credentials toegang geven — biedt identity- en securityteams het gerichte startpunt dat herstel van agentidentiteit beheersbaar maakt in plaats van overweldigend.
Aanvullende bronnen
- Blog Post
Zero‑Trust strategieën voor betaalbare AI-privacybescherming - Blog Post
Hoe 77% van de organisaties faalt in AI-databeveiliging - eBook
AI Governance Gap: Waarom 91% van de kleine bedrijven Russisch roulette speelt met databeveiliging in 2025 - Blog Post
Er bestaat geen “–dangerously-skip-permissions” voor jouw data - Blog Post
Toezichthouders zijn klaar met vragen of je een AI-beleid hebt. Ze willen bewijs dat het werkt.