Zero-trust voor AI-systemen: waarom dezelfde principes gelden — en waar ze tekortschieten

Zero-trust is een van de meest volwassen raamwerken in enterprise security. De principes — nooit vertrouwen, altijd verifiëren, uitgaan van een datalek, het minste privilege afdwingen — zijn goed begrepen, goed geïmplementeerd en diep verankerd in hoe securityteams denken over toegangscontrole.

Het probleem is dat zero-trust is ontwikkeld met een specifiek actormodel in gedachten: menselijke gebruikers met stabiele identiteiten, voorspelbare gedragspatronen en duidelijk afgebakende sessiegrenzen. AI-systemen zijn geen van deze dingen. Ze handelen namens gebruikers zonder zelf gebruiker te zijn. Hun gedrag is semantisch complex en operationeel ondoorzichtig. Ze kunnen duizenden data-operaties uitvoeren in de tijd dat een mens er één voltooit.

Deze post is bedoeld voor CISO’s en securityarchitecten die zero-trust architectuur willen uitbreiden naar AI-acteurs — en die moeten begrijpen waar hun bestaande raamwerken standhouden en waar niet.

Samenvatting voor het management

Belangrijkste idee: De zero-trust principes die menselijke toegang tot bedrijfsdata reguleren, gelden evenzeer voor AI-systemen — maar de mechanismen waarmee deze principes voor menselijke actoren worden geïmplementeerd, zijn niet direct toepasbaar. AI-acteurs vereisen speciaal ontwikkelde controles die inspelen op hun unieke identiteit, gedragskenmerken en operationele eigenschappen.

Waarom dit belangrijk is: Securityteams die zero-trust raamwerken voor menselijke actoren zonder aanpassing toepassen op AI-systemen, creëren een governancekloof die ze niet zien. De controles lijken op papier correct — authenticatie bestaat, toegangsbeleid is gedefinieerd, logging is geconfigureerd — maar ze worden niet afgedwongen op de manier die AI’s operationele kenmerken vereisen. Het resultaat is een zero-trust beveiligingsstatus die technisch aanwezig is, maar in de praktijk onvoldoende.

5 Belangrijkste inzichten

1. Zero-trust principes zijn zonder aanpassing van toepassing op AI-systemen — nooit vertrouwen, altijd verifiëren, uitgaan van een datalek, het minste privilege afdwingen. Wat aangepast moet worden, is de implementatie: de controles die voor menselijke actoren zijn ontworpen, houden geen rekening met AI’s identiteitsmodel, gedragskenmerken of operationele schaal.
2. AI-identiteit verschilt fundamenteel van menselijke identiteit. Een AI-systeem heeft geen stabiel identiteitsanker — het handelt namens gebruikers, is kwetsbaar voor prompt-injectie die de schijnbare intentie kan wijzigen, en draait meestal onder serviceaccounts die verbergen wie daadwerkelijk de acties aanstuurt.
3. Sessie-authenticatie — de standaardaanpak bij de meeste AI-integraties — schendt de zero-trust eis van continue verificatie. Autorisatie per verzoek, afgedwongen via RBAC en ABAC op het dataniveau, is het enige implementatiepatroon dat daadwerkelijk voldoet aan never-trust voor AI-acteurs.
4. De impact van een gecompromitteerd AI-systeem is categorisch groter dan die van een gecompromitteerd gebruikersaccount. Een AI-systeem met brede data-toegang en zonder rate limiting kan op een schaal en snelheid data exfiltreren waardoor incidentrespons reactief wordt in plaats van preventief. Assume-breach architectuur voor AI vereist rate limiting en scope-controles die geen equivalent kennen in zero-trust voor menselijke actoren.
5. Audit logs voor AI-operaties vereisen dubbele attributie — de AI-systeemidentiteit én de menselijke gebruiker namens wie het handelde — om te voldoen aan compliance-raamwerken. Logs die alleen de acties van het AI-systeem registreren, zijn forensisch en regulatorisch onvolledig.

Waarom Zero-Trust het juiste raamwerk is — en waarom het moet worden uitgebreid

Zero-trust ontstond als reactie op het falen van perimeterbeveiliging: het besef dat zodra een actor binnen het netwerk is, traditionele controles te veel impliciet vertrouwen geven. Het antwoord was om elk toegangsverzoek als potentieel vijandig te behandelen, ongeacht de netwerkpositie, en identiteit te verifiëren, het minste privilege af te dwingen en elke operatie continu te auditen. Deze principes zijn juist voor AI-acteurs. Een AI-systeem dat geauthenticeerd is bij een datarepository mag geen impliciet vertrouwen krijgen voor de duur van die sessie. Elk verzoek moet worden geëvalueerd aan de hand van beleid. Elke operatie moet worden gelogd. De toegang moet worden begrensd door de rechten van de mens die het aanstuurt.

De uitbreiding die nodig is, zit niet in de principes maar in de implementatieveronderstellingen. Zero-trust raamwerken gaan ervan uit dat de actor een stabiele, verifieerbare identiteit heeft — een gebruikersaccount, een certificaat, een hardwaretoken. Ze gaan ervan uit dat sessiegrenzen redelijk overeenkomen met autorisatiegrenzen. Ze gaan ervan uit dat ‘normaal gedrag’ herkenbaar is en afwijkingen detecteerbaar zijn. AI-systemen doorbreken al deze drie aannames, en de controles die hierop zijn gebouwd, moeten worden herontworpen voor een actormodel dat fundamenteel anders is.

Het identiteitsprobleem: AI-systemen hebben geen stabiele identiteiten

Zero-trust voor menselijke actoren is gebaseerd op identiteitsverificatie: authenticeer de gebruiker, stel hun identiteit vast en gebruik die identiteit als basis voor autorisatiebeslissingen. Dit werkt omdat menselijke identiteiten stabiel zijn — een gebruikersaccount hoort bij een specifiek persoon met specifieke rollen en toegangsrechten, geverifieerd via multi-factor authentication en Identity & Access Management (IAM) systemen. AI-systemen hebben geen vergelijkbaar identiteitsanker.

De ‘identiteit’ van een AI-systeem bij de meeste enterprise-inzet is een serviceaccount — een gedeelde inlog die het AI-platform vertegenwoordigt, niet de specifieke gebruiker die de AI aanstuurt. Dit levert twee governanceproblemen op. Ten eerste verbergt de serviceaccount wie daadwerkelijk verantwoordelijk is voor data-toegang: als een AI een document ophaalt, toont de audit log de serviceaccount, niet de medewerker die de vraag stelde. Ten tweede heeft de serviceaccount meestal meer rechten dan een individuele gebruiker zou krijgen — omdat deze is geconfigureerd om de AI elke gebruiker te laten bedienen, moet het overal toegang toe hebben wat een gebruiker mogelijk nodig heeft.

Het diepere identiteitsprobleem is prompt-injectie. Het gedrag van een AI-systeem wordt bepaald door zijn input — en die input kan worden gemanipuleerd. Een prompt-injectieaanval verwerkt instructies in de data die de AI verwerkt, waardoor het gedrag wordt omgeleid op manieren die governancecontroles kunnen omzeilen, inloggegevens kunnen extraheren of toegang krijgen tot data buiten de bedoelde scope. In tegenstelling tot een menselijke gebruiker wiens identiteit stabiel blijft ongeacht wat hij leest, kan de effectieve ‘identiteit’ van een AI-systeem — wat het hierna zal doen — worden gewijzigd door content in zijn context window. Traditionele identiteitsverificatie heeft hier geen oplossing voor. Zero-trust databeveiliging voor AI vereist dat inloggegevens volledig buiten de context van de AI worden opgeslagen, in de OS keychain, zodat ze niet bereikbaar zijn via promptmanipulatie.

Het sessiegrenzenprobleem: Wanneer betekent ‘continu’ per verzoek?

Zero-trust’s eis van continue verificatie wordt meestal geïmplementeerd via sessiebeheer: opnieuw authenticeren na inactiviteit, risicogebaseerde step-up authenticatie en anomaliedetectie op gebruikersgedrag binnen een sessie. Voor menselijke actoren is dit logisch — een sessie staat voor een afgebakende periode van doelgerichte activiteit, en opnieuw authenticeren bij sessiegrenzen biedt zinvolle verificatie.

AI-sessies werken niet op deze manier. Een AI-agent die namens een gebruiker opereert, kan urenlang een permanente verbinding met bedrijfsdatasystemen onderhouden en duizenden individuele operaties uitvoeren binnen één sessie. Sessie-authenticatie betekent dat de AI slechts één keer is geverifieerd, aan het begin — maar elke daaropvolgende operatie binnen die sessie erft die initiële autorisatie zonder onafhankelijke verificatie. Voor een menselijke gebruiker die door een bestandssysteem navigeert, is dit acceptabel. Voor een AI-systeem dat duizend retrieval-operaties per minuut kan uitvoeren, is sessie-autorisatie geen continue verificatie — het is één checkpoint gevolgd door ongemonitorde toegang op machinesnelheid.

Echte continue verificatie voor AI vereist autorisatie per verzoek: elke individuele operatie — elk bestandsverzoek, elke retrieval-query, elke mapnavigatie — geëvalueerd tegen RBAC- en ABAC-beleid op het moment dat deze wordt aangevraagd. Dit is niet alleen een beste practice — het is de enige implementatie van ‘nooit vertrouwen, altijd verifiëren’ die standhoudt bij het operationele tempo van AI-systemen. Sessie-autorisatie is één keer verifiëren gevolgd door langdurig vertrouwen. Dat is geen zero-trust; dat is een perimeter-model met een kortere perimeter.

Zero-Trust Principes: Menselijke actoren vs. AI-acteurs

Het blast radius-probleem: Waarom uitgaan van een datalek iets anders betekent voor AI

Assume-breach architectuur voor menselijke actoren richt zich op het beperken van laterale beweging: netwerksegmentatie, het minste privilege en anomaliedetectie om een gecompromitteerde gebruiker te stoppen voordat deze naar andere systemen kan bewegen. De impact van een gecompromitteerd menselijk account, hoewel ernstig, wordt beperkt door het operationele tempo van mensen — een persoon kan maar zoveel data zo snel benaderen.

Een gecompromitteerd AI-systeem werkt op een totaal andere schaal. Een AI-agent met brede repository-toegang en zonder rate limiting kan honderdduizenden documenten ophalen in de tijd dat een securityanalist een SIEM-melding bekijkt. De assume-breach controles die werken voor menselijke actoren — anomaliedetectie, sessie beëindigen, netwerksegmentatie — zijn grotendeels reactief bij het operationele tempo van AI. Tegen de tijd dat een anomalie wordt gedetecteerd en een sessie wordt beëindigd, is de data al verplaatst.

Assume-breach voor AI vereist proactieve beperking van de impact die niet bestaat in zero-trust raamwerken voor menselijke actoren. Rate limiting op AI-data-aanvragen — afgedwongen op het dataniveau, niet op applicatieniveau — begrenst de hoeveelheid data die een AI-systeem kan ophalen, ongeacht de instructies. Pad- en scopecontroles voorkomen dat de AI buiten het bedoelde datadomein navigeert. Deze controles detecteren geen compromittering achteraf; ze beperken de schade die een compromis kan veroorzaken vóór detectie. Dat is een fundamenteel andere controlfilosofie dan assume-breach voor menselijke actoren, en vereist een speciaal ontworpen architectuur in plaats van aanpassing van bestaande risicobeheer cyberbeveiliging controles.

Het auditprobleem: Wie is verantwoordelijk als een AI data benadert?

Zero-trust auditvereisten voor menselijke actoren zijn goed ingeburgerd: log de gebruikersidentiteit, de benaderde bron, het tijdstip en de uitgevoerde actie. Dit levert een audittrail op die voldoet aan HIPAA-naleving, GDPR-naleving, SOX en FedRAMP-naleving omdat de log het verantwoordingsvraagstuk beantwoordt: een specifieke persoon heeft een specifieke bron benaderd en is daarvoor verantwoordelijk.

AI-toegangslogs bij de meeste enterprise-implementaties registreren de AI-systeemidentiteit — de serviceaccount — en verder niets. Wanneer een AI een gevoelig document ophaalt, toont de log dat de serviceaccount van het AI-platform het bestand heeft benaderd. Het toont niet welke medewerker de retrieval heeft getriggerd, wat er is gevraagd of wat er met het resultaat is gedaan. Dit is geen klein toeschrijvingsprobleem. Voor HIPAA, dat vereist dat logs de persoon identificeren die toegang heeft tot beschermde gezondheidsinformatie, voldoet een serviceaccountvermelding niet aan het minimumnodige. Voor GDPR, dat vereist dat de wettelijke basis voor elke data-toegang kan worden aangetoond, kan een log die de menselijke aanvrager niet identificeert, die basis niet vaststellen.

AI-auditlogs vereisen dubbele attributie: de AI-systeemidentiteit en de geauthenticeerde menselijke gebruiker namens wie de AI handelde, gecombineerd in één logvermelding voor elke operatie. Dit is technisch niet complex — het vereist dat het AI-systeem de gebruikersidentiteit doorgeeft aan het dataniveau bij elk verzoek, en dat het dataniveau beide identiteiten samen registreert. Maar het vereist wel een bewuste architecturale keuze. De meeste AI-integraties implementeren dit niet, en de meeste zero-trust auditraamwerken zijn hier niet op geschreven.

Kiteworks Zero-Trust controles voor AI: Implementatie en impact

Hoe Kiteworks Zero-Trust uitbreidt naar elk AI-verzoek

De securityteams die AI-adoptie het succesvolst zullen begeleiden, zijn niet degenen die AI verbieden — maar degenen die hun bestaande securityarchitectuur uitbreiden om AI-acteurs met dezelfde grondigheid te dekken als menselijke actoren. Die uitbreiding vereist speciaal ontwikkelde controles, omdat de aannames voor menselijke actoren in bestaande zero-trust security raamwerken niet gelden voor AI-systemen. Het identiteitsmodel is anders. Het sessiemodel is anders. De impact is anders. De auditvereisten zijn anders.

Een securityteam dat deze verschillen begrijpt en controles implementeert die hiervoor zijn ontworpen, kan AI-adoptie met vertrouwen mogelijk maken. Een team dat menselijke controles toepast op AI-acteurs en het daarbij laat, heeft een zero-trust beveiligingsstatus die technisch aanwezig is, maar in de praktijk onvoldoende.

Kiteworks implementeert zero-trust voor AI-acteurs op elk niveau waar het model voor menselijke actoren tekortschiet. Credential isolatie: OAuth 2.0 tokens worden opgeslagen in de OS keychain, buiten het context window van het AI-model, onder geen enkele omstandigheid toegankelijk via prompt-injectie. Autorisatie per verzoek: de Kiteworks Data Policy Engine evalueert RBAC- en ABAC-beleid voor elke individuele AI-operatie — niet bij het opzetten van de sessie, maar op het moment dat elk verzoek wordt gedaan. De AI erft de rechten van de aanvragende gebruiker en kan deze voor geen enkele actie overschrijden, ongeacht de sessiestatus.

Dubbele attributie audit logging registreert zowel de AI-systeemidentiteit als de geauthenticeerde menselijke gebruiker voor elke operatie, voedt de Kiteworks audit log en integreert realtime met SIEM — geen batching, geen vertraging, geen detectiegat. Rate limiting en padcontroles handhaven assume-breach architectuur op het dataniveau: een AI-systeem dat gecompromitteerd of verkeerd geconfigureerd is, kan geen data op schaal exfiltreren omdat de controles zijn ingebed in de Private Data Network architectuur, niet afhankelijk van het AI-systeem zelf.

En omdat deze controles het bestaande zero-trust data exchange raamwerk uitbreiden dat beveiligde bestandsoverdracht, beveiligde MFT en beveiligde e-mail in de hele organisatie reguleert, hoeft er geen apart AI-beveiligingsprogramma te worden gebouwd en onderhouden. De bestaande zero-trust architectuur wordt simpelweg uitgebreid naar AI — niet opnieuw opgebouwd.

Voor CISO’s en securityarchitecten die zero-trust met dezelfde grondigheid willen uitbreiden naar AI-acteurs als naar menselijke actoren, biedt Kiteworks de speciaal ontwikkelde controles die dit mogelijk maken. Bekijk de implementatie in detail en plan vandaag nog een aangepaste demo.

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 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.