De meeste datalekken via AI-agents komen niet doordat het model stiekem je bedrijf onthoudt. Ze komen voort uit configuratie- en architectuurfouten die je kunt benoemen en oplossen. De grote: draaien op een account op consumentenniveau waarvan de standaardinstellingen op je invoer trainen, een agent de brede rechten van één persoon laten erven, een publiek toegankelijke agent aan interne systemen hangen, en de "dodelijke drie-eenheid" intact laten (privégegevens, niet-vertrouwde inhoud en een externe verzendroute) zodat één prompt injection je gegevens kan lezen en naar buiten mailen. Dat laatste patroon is precies hoe EchoLeak (CVE-2025-32711) gevoelige gegevens blootstelde via Microsoft 365 Copilot, vanuit een geprepareerde e-mail, zonder dat de gebruiker klikte. De oplossingen zijn niet exotisch, en bijna allemaal zijn het beslissingen die je vóór de lancering van de agent neemt, geen checklist die je krijgt nadat er iets is gelekt.
Dit is de lijst die we doorlopen voordat we een door ons gebouwde agent in de stack van een ander bedrijf plaatsen, geschreven zodat een niet-technische eigenaar dezelfde fouten kan herkennen in zijn eigen opzet of die van een leverancier. Als je liever hebt dat wij deze grens voor je bewaken waar die hoort, bekijk dan hoe we verantwoorde AI-governance en -risico aanpakken. Alles hieronder is hoe dan ook van jou om te gebruiken.
Eerst een onderscheid dat bijna elk artikel over dit onderwerp vervaagt, want dat verkeerd hebben is fout nul. Er zijn twee compleet verschillende manieren waarop gegevens via een agent weglekken, en ze hebben compleet verschillende oplossingen:
- Gegevensverwerking door de aanbieder. Slaat de modelaanbieder je invoer op of traint hij erop? Dit is een contract dat je tekent en een accountniveau dat je kiest. Het wordt opgelost met voorwaarden en configuratie.
- Exfiltratie tijdens runtime. Kan de agent op het moment dat hij draait worden misleid om je gegevens ergens heen te sturen waar ze niet horen? Dit wordt opgelost met architectuur, niet met een contract.
De cijfers uit enquêtes laten zien dat kopers dit voelen, zelfs als ze het niet kunnen benoemen. In het onderzoek van Cloudera onder bijna 1.500 senior IT-leiders in 14 landen is 96% van plan het gebruik van AI-agents het komende jaar uit te breiden, terwijl 53% (meer dan de helft) gegevensprivacy noemt als de belangrijkste belemmering voor adoptie. De zeven fouten hieronder zijn waar die angst een echt lek wordt, en waar de oplossing zit.
Fout 1: productie-agents draaien op accounts op consumentenniveau
Dit is de goedkoopste fout om te maken en de makkelijkste om op te lossen. Iemand koppelt een workflow aan een persoonlijk ChatGPT- of consumenten-Gemini-account omdat het er toch al is, en nu worden je bedrijfsgegevens beheerst door consumentenvoorwaarden die er nooit voor bedoeld waren.
Het verschil tussen consumenten- en enterprise-niveaus is scherp. Aan de enterprise-kant is het patroon consistent bij alle aanbieders: standaard geen training op je gegevens, een korte bewaartermijn voor misbruikmonitoring, en sterkere opties op verzoek. De OpenAI-API bewaart gegevens 30 dagen voor misbruikmonitoring en verwijdert ze daarna, en traint er standaard niet op. Per 14 september 2025 verkortte Anthropic de bewaartermijn van API-logs van 30 dagen naar 7 dagen, en API-invoer en -uitvoer worden nooit gebruikt voor training. Google's Vertex AI (het enterprise-niveau) is configureerbaar zonder trainingsgebruik. Aan de consumentenkant draaien de standaardinstellingen om: consumenten-ChatGPT bewaart gesprekken voor onbepaalde tijd tenzij je ze verwijdert, en de bewaartermijn van consumenten-Gemini loopt op tot 36 maanden en kan worden gebruikt om producten te verbeteren.
De oplossing: zet elke productie-agent op een enterprise-API of zakelijk account, nooit op een persoonlijke login. De technologie is identiek. De voorwaarden niet, en de voorwaarden zijn het hele verschil tussen gegevens die onder beheer blijven en gegevens die stilletjes trainingsmateriaal worden.
Fout 2: te ruime rechten die de agent erft
Het meest voorkomende runtime-lek is niet slim. Een agent krijgt de toegang van één medewerker, of erger, een admin-sleutel, zodat hij technisch gezien alles kan zien wat die persoon kan zien. Vervolgens krijgt hij een vraag, of wordt hij naar een vraag misleid, die veel verder reikt dan zijn taak.
Microsofts Cloud Adoption Framework stelt de regel onomwonden: "Geef agents alleen toegang tot de specifieke gegevensbronnen die nodig zijn voor hun functie. Geef geen brede toegang tot alle organisatiegegevens." Een supportagent heeft je salarissysteem niet nodig. Een planningsagent heeft de klantendatabase niet nodig. Wanneer een agent namens een persoon handelt, moet hij de rechten van die persoon erven door diens identiteit veilig door te geven, zodat een helpdesk-agent een medewerker alleen zijn eigen HR-dossier toont, niet dat van iedereen.
De oplossing: geef elke agent zijn eigen identiteit, gescoped op minimale rechten, en laat hem de rechten van de handelende gebruiker erven in plaats van een vaste superset te dragen. De test is eenvoudig. Als de agent morgen wordt misleid, is de schade begrensd tot de smalle set die hem is toegekend, niet tot alles wat één account met te veel rechten kon bereiken.
Fout 3: publiek toegankelijke agents die aan interne gegevens hangen
Een chatbot op je website en een agent die interne rapporten opstelt zijn twee verschillende beveiligingswerelden, en het lek ontstaat op het moment dat iemand ze een backend laat delen. Een publieke agent neemt invoer aan van iedereen op het internet. Als diezelfde agent ook interne bedrijfsgegevens kan opvragen, heb je een deur gebouwd van het publieke web rechtstreeks naar je private systemen.
Microsofts framework trekt hier de hardste grens: "Publiek toegankelijke agents mogen geen toegang hebben tot interne bedrijfsgegevens." Houd vertrouwelijk en publiek gescheiden door een fysieke of logische grens (hun voorbeeld gebruikt aparte beheergroepen "corp" en "online"). Het punt is dat de grens structureel is, niet een hoop dat de prompt het wel houdt.
De oplossing: plaats een echte grens tussen agents die niet-vertrouwde publieke invoer aannemen en agents die vertrouwelijke gegevens raken. Als één agent echt beide moet doen, is dat het ontwerp met het hoogste risico dat je kunt kiezen, en heeft het de drie-eenheid-brekende controles uit de volgende fouten nodig, niet alleen een zorgvuldige systeemprompt.
Fout 4: de dodelijke drie-eenheid negeren
Dit is de fout die de eerste drie omzet in een echte exfiltratie. Simon Willison, de onafhankelijke expert die de term "prompt injection" bedacht, benoemde de "dodelijke drie-eenheid" voor AI-agents: drie voorwaarden die, gecombineerd, één geïnjecteerde instructie je gegevens laten stelen.
| De drie poten | Wat het betekent | Voorbeeld |
|---|---|---|
| Toegang tot privégegevens | De agent kan gevoelige informatie lezen | Inbox, CRM, interne documenten |
| Blootstelling aan niet-vertrouwde inhoud | Hij verwerkt tekst die hij niet zelf schreef | Een binnenkomende e-mail, een webpagina, een bestand |
| Externe communicatie | Hij kan gegevens naar buiten sturen | Een antwoord, een API-aanroep, een opgehaalde URL |
Als alle drie aanwezig zijn, verbergt een aanvaller een instructie in de niet-vertrouwde inhoud. Het model, in Willisons woorden, "zal vrolijk elke instructie volgen die bij het model terechtkomt, of die nu van hun operator komt of van een andere bron." Het leest je privégegevens en stuurt ze naar buiten, en niets in de prompt zei dat het de e-mail niet moest vertrouwen.
Het botte deel, en de reden dat dit architectuur is en geen prompt-engineering-probleem: "we weten nog steeds niet hoe we dit voor 100% betrouwbaar kunnen voorkomen." Gedocumenteerde exploits hebben Microsoft 365 Copilot, GitHubs MCP-server en GitLab Duo getroffen. In één week in januari 2026 werden indirecte prompt-injection-kwetsbaarheden bekendgemaakt in vier AI-productiviteitstools, allemaal hetzelfde drie-eenheid-patroon.
De oplossing: breek één poot. Blokkeer de externe verzendroute zodat gestolen gegevens nergens heen kunnen, of laat een agent die niet-vertrouwde inhoud leest nooit tegelijk toegang tot privégegevens houden in dezelfde context. Je hoeft het onwinbare gevecht om elke injectie te onderscheppen niet te winnen. Je moet ervoor zorgen dat zelfs een geslaagde injectie geen weg naar buiten heeft.
Fout 5: EchoLeak behandelen als andermans probleem
Het is de moeite waard om één echt incident te benoemen, want "de dodelijke drie-eenheid" klinkt abstract totdat je het in de praktijk ziet. EchoLeak (CVE-2025-32711) was een zero-click-aanval op Microsoft 365 Copilot. Een aanvaller stuurde een geprepareerde e-mail. Copilot, gewoon zijn werk doend, verwerkte die e-mail (niet-vertrouwde inhoud), had toegang tot de interne gegevens van de gebruiker (privégegevens), en had een manier om informatie naar buiten te sturen (externe communicatie). De verborgen instructie voltooide blootstelling van gevoelige gegevens zonder enige interactie van de gebruiker. Niemand klikte op iets.
De fout hier is aannemen dat een lek een onzorgvuldige medewerker vereist. EchoLeak vereiste er geen. De verdediging die ertoe deed was niet "train personeel om phishing te herkennen," want er was niets voor een mens om te herkennen. De verdediging was architectonisch: een agent die niet tegelijk door een aanvaller gecontroleerde inhoud kan lezen en kan exfiltreren, kan op deze manier niet tegen je worden gekeerd.
De oplossing: ga ervan uit dat zero-click het dreigingsmodel is, niet de uitzondering. Als je agent iets leest waar een buitenstaander invloed op kan hebben (e-mail, webinhoud, geüploade bestanden, tickets) en hij kan ook gegevens naar buiten sturen, dan heb je een EchoLeak-vormig gat totdat je een van die twee mogelijkheden afsluit of de verzendroute hard afschermt.
Fout 6: geen grens voor dataresidentie of bewaring
Sommige lekken zijn geen dramatische exfiltraties, het is langzame drift. Gegevens belanden opgeslagen in een regio waarmee je nooit hebt ingestemd, of liggen langer in logs dan je beleid toestaat, simpelweg omdat niemand de grens heeft gesteld. Microsofts framework noemt dit als kerngovernance: identificeer de locatie van elke gegevensbron, agent-runtime en uitvoeropslag, houd gegevens in regio's of on-prem die passen bij je residentiebeleid, en houd ze versleuteld in rust.
Het geruststellende nieuws, dat bijna geen enkel artikel onomwonden zegt, is hoeveel je kunt vastleggen. Het enterprise-patroon bij alle aanbieders is standaard-geen-training plus een korte bewaartermijn plus sterkere garanties op verzoek. Anthropic biedt kwalificerende ondernemingen een Zero Data Retention (ZDR)-overeenkomst, waaronder invoer en uitvoer niet langer worden opgeslagen dan nodig is om op misbruik te screenen. OpenAI biedt ZDR via een onderhandelde overeenkomst en dataresidentie. Beide laten je kiezen waar gegevens worden bewaard. Een open model zelf hosten (bijvoorbeeld met Ollama) houdt gegevens volledig lokaal zonder bewaring door derden.
De oplossing: bepaal en documenteer de grens vóór de lancering. Welke regio bevat de gegevens, hoe lang leven logs, of je ZDR nodig hebt, en of gevoelig ophalen in je eigen VPC of on-prem moet draaien. ZDR is meestal alleen voor API en onderhandeld, en dekt niet automatisch elk product tenzij je het toevoegt, dus het detail doet ertoe.
Fout 7: privacy behandelen als een checklist die je overdraagt
De laatste fout is structureel. De meeste richtlijnen, inclusief het uitstekende Microsoft-framework, gaan ervan uit dat je de agent zelf bouwt en beheert, dus geven ze je een stapel van 3.000 woorden over Entra-identiteiten, Purview-labels en beheergroepen. Dat is het juiste antwoord voor een groot IT-team. Voor de meeste bedrijven is het een checklist die niemand de tijd of specialistische kennis heeft om volledig uit te voeren, dus wordt hij half opgeleverd, en de gaten zijn precies waar gegevens lekken.
De fout is de controles behandelen als documentatie in plaats van als een architectuur die iemand van begin tot eind bezit. Een checklist die "isoleer vertrouwelijke gegevens" en "beperk externe integraties tot vertrouwde MCP-servers" opsomt is alleen zo goed als de persoon die het inbouwt, elke externe communicatie valideert, en het incidentplan opzet om een agent snel uit te schakelen wanneer er iets misgaat.
De oplossing: zorg dat één partij de grens daadwerkelijk bezit, niet alleen het document. Of je bouwt de interne capaciteit om de volledige stack te implementeren en te onderhouden, of je laat een operator deze faalwijzen uit de architectuur ontwerpen en draaien, met een gepubliceerde grens waar je naar kunt wijzen. De verkeerde tussenweg is een lijst met controles en niemand die verantwoordelijk is dat ze standhouden.
Hoe de zeven fouten en oplossingen op één rij staan
Hier zijn alle zeven op één plek, gesorteerd op de vraag of de oplossing een contract is dat je tekent of een architectuur die je bouwt. Die splitsing is de snelste manier om te weten welk team welke bezit.
| # | Fout | Oplossing | Type |
|---|---|---|---|
| 1 | Accounts op consumentenniveau in productie | Enterprise-API of zakelijk account, geen training | Contract |
| 2 | Te ruime geërfde rechten | Identiteit met minimale rechten, erf de toegang van de gebruiker | Architectuur |
| 3 | Publieke agents die interne gegevens raken | Harde grens tussen publiek en vertrouwelijk | Architectuur |
| 4 | De dodelijke drie-eenheid negeren | Breek één poot: geen niet-vertrouwde inhoud plus privégegevens plus verzendroute | Architectuur |
| 5 | Aannemen dat een lek een onzorgvuldige klik vereist | Ontwerp voor zero-click; scherm de exfiltratieroute af | Architectuur |
| 6 | Geen grens voor residentie of bewaring | Leg regio vast, stel bewaring in, teken ZDR, maskeer bij de grens | Contract |
| 7 | Privacy als een overgedragen checklist | Eén eigenaar verantwoordelijk dat de grens standhoudt | Eigenaarschap |
Merk op dat slechts twee van de zeven worden opgelost door een contract. De andere vijf zijn architectuur en eigenaarschap, en dat is het deel dat een PDF met best practices niet voor je kan doen. Het is ook de eerlijke reden waarom de gezaghebbende bronnen een gat laten: ze vertellen je wat je moet bouwen, niet wie het correct gaat bouwen binnen jouw specifieke systemen.
Wat er echt nooit weggaat, als de grens goed is gebouwd
Het is makkelijk om zeven fouten te lezen en te concluderen dat AI-agents een privacymijnenveld zijn. Dat zijn ze niet, als de grens bewust wordt getrokken. Op enterprise-voorwaarden zijn je invoergegevens geen trainingsdata, en is de bewaring dagen, niet voor altijd (7 voor de Anthropic-API, 30 voor OpenAI, daarna verwijderd). Met ZDR worden ze niet langer bewaard dan voor misbruikscreening. Met dataresidentie vastgelegd blijven ze in je regio. Met VPC- of on-prem-ophalen verlaten gevoelige gegevens je perimeter helemaal niet. Met maskering bij de grens worden de velden die nooit zouden mogen reizen verwijderd voordat er iets wordt verstuurd. Met scoping op minimale rechten die de rechten van de gebruiker erft, kan de agent alleen ooit bereiken wat de handelende persoon al kon bereiken.
Dat is een specifieke, verdedigbare grens, en die helder kunnen benoemen is het hele punt. Het gevaar was nooit het model dat stilletjes je bedrijf opslorpt. Het zijn de zeven configuratie- en architectuurfouten hierboven, die allemaal te voorkomen zijn voordat de eerste agent live gaat.
Dit is het werk dat we doen binnen de stacks van andere bedrijven: de voorwaarden kiezen, de identiteiten scopen, het publieke isoleren van het vertrouwelijke, de drie-eenheid breken, en de grens bezitten zodat die standhoudt. Als je wilt dat deze fouten uit de architectuur van je agents worden ontworpen voordat ze iets echts raken, boek dan hieronder een gratis consult en brengen we samen je grens in kaart.