Eerste datalek via een AI-agent in Spanje: lessen voor uw agents

Een datalekmelding bij de Spaanse privacytoezichthouder beschrijft een aanval waarbij een AI-agent zelf naar zwakke plekken zocht en ze misbruikte. De feiten zijn nog niet geverifieerd, maar de les voor iedereen die agents met bedrijfsbestanden laat werken, hangt daar niet van af: bepaal wat elke agent kan bereiken, en laat elke actie die iets verandert eerst langs een mens gaan.

Wat de AEPD meldde

Op 14 september 2026 publiceerde de Agencia Española de Protección de Datos (AEPD) een blogbericht over de eerste melding die zij ontving van een datalek met persoonsgegevens dat “zou zijn uitgevoerd met een AI-agent die een bekend taalmodel gebruikte”. Volgens de melding doorzocht de agent algemene bestanden op kwetsbaarheden en wist hij met succes in te loggen. Eenmaal binnen zocht hij zelfstandig naar zwakke plekken in de applicatie, waardoor hij persoonsgegevens kon wijzigen en bij facturen kon komen. (Citaten uit Spaanstalige bronnen in dit stuk zijn onze vertaling.)

Drie details zijn net zo belangrijk als het verhaal zelf:

• De AEPD schrijft dat de informatie “afkomstig is uit de melding die de getroffen organisatie heeft ingediend” en nog moet worden geanalyseerd. De organisatie, de sector en het model worden niet genoemd.
• Een derde partij zou de agent als aanvalsmiddel hebben gebruikt. Het gaat dus niet om de eigen assistent van een bedrijf die op hol sloeg.
• De AEPD benadrukt dat het gebruik van een bepaald model niet betekent dat het model of de aanbieder ervan is gecompromitteerd, en dat één melding nog geen statistische trend aantoont.

Wat dit betekent voor de agents die u zelf inzet

De meeste organisaties zullen agents met toestemming op hun eigen bestanden inzetten, en er niet als aanvaller een tegenkomen. Het advies van de AEPD geldt voor beide situaties. Dezelfde basisprincipes blijven doorslaggevend, schrijft de toezichthouder: “de verwerkingen kennen, gegevens minimaliseren, toegang beperken, kwetsbaarheden verhelpen, leveranciers controleren en voorbereid zijn om te reageren”. Ook waarschuwt de AEPD dat “een agent die een account, een API-sleutel of een token met te ruime rechten bemachtigt, op machinesnelheid kan werken”, en dat menselijk toezicht essentieel blijft, maar alleen werkt met detectie en respons die dat tempo kunnen bijhouden.

Dat is een argument over toegang, niet over modellen. Een agent die alleen bij de map kan die hij nodig heeft, en niets kan wijzigen totdat een mens akkoord geeft, beperkt wat er mis kan gaan als zijn invoer kwaadwillig is of zijn inloggegevens uitlekken.

Een toets uit de eigen richtlijnen van de AEPD

In februari 2026 publiceerde de AEPD richtlijnen over agentische AI vanuit het perspectief van gegevensbescherming. Daarin staat de ‘Rule of 2’, een cybersecurityregel die in 2021 voor het eerst werd opgesteld voor de Chromium-browser en sindsdien door anderen, onder wie Meta, is aangepast voor AI-agents. De drie eigenschappen zijn: onbetrouwbare invoer verwerken, bij gevoelige informatie kunnen en automatisch handelen. Het voorbeeld in de richtlijnen is een e-mailagent die alle drie heeft, en het oordeel is duidelijk: “Dat zou een configuratie van de agent zijn die niet zou mogen worden toegestaan.” Als een agent onbetrouwbare invoer verwerkt en bij gevoelige gegevens kan, moet volgens de richtlijnen elke automatische actie met gevolgen binnen of buiten de organisatie worden voorkomen zolang er geen menselijk toezicht is. De AEPD noemt de regel zelf een minimum en een startpunt voor analyse, geen volledige beoordeling van de gegevensbescherming.

Pas de regel toe op een documentagent. Bestanden die van buiten de organisatie binnenkomen, zijn onbetrouwbare invoer: een document kan instructies bevatten die op het model zijn gericht. De map die de agent leest, kan persoonsgegevens bevatten. De eigenschap die weg moet, is dus de derde: zelfstandig handelen.

Hoe agents uit de Marketplace zich tot deze toets verhouden

Agents uit de Marketplace werken in Claude via de Kiteworks-connector, op een map die u kiest, met de connectorrechten van de persoon die ze gebruikt. De meeste lezen alleen en rapporteren. Waar een agent schrijft, schrijven zijn instructies voor dat hij eerst om bevestiging vraagt. Sharing Auditor slaat een rapport pas op nadat u hebt bevestigd waar, en heeft geen tool om het delen te wijzigen. Invoice Organizer hernoemt bestanden pas nadat u de voorgestelde namen hebt goedgekeurd. Lees vóór een pilot bij elke vermelding na wat de agent leest, wat hij kan schrijven en wat hij niet kan zien.

Twee agents helpen ook bij de basisprincipes die de AEPD als eerste noemt. Sharing Auditor laat zien welke mappenstructuren binnen een bereik gedeeld zijn en waar het delen begint, zodat u weet wat een agent, of wie dan ook, via die mappen kan bereiken. Sensitive Content Scanner vindt gevoelige termen en veelvoorkomende persoonsgegevens in een map. Zo weet u welke bereiken u moet weghouden bij agents die documenten van buiten verwerken. Beide rapporteren; geen van beide wijzigt een deling of een bestand.

Vragen voordat u een agent koppelt

• Welke mappen gaat de agent lezen, en staan daar persoonsgegevens in die hij niet nodig heeft?
• Waar komt zijn invoer vandaan, en kan een buitenstaander een deel daarvan hebben geschreven?
• Wat kan hij wijzigen, en wacht elke wijziging op goedkeuring van een met naam genoemde persoon?
• Met wiens inloggegevens werkt hij, en hoe snel kunt u die intrekken?
• Neemt uw risicoanalyse inmiddels ook aanvallen met hulp van AI mee, zoals de AEPD verwerkingsverantwoordelijken vraagt te overwegen?
• Wie beoordeelt het rapport van de agent, en waar wordt de beslissing vastgelegd?

Wilt u een agent vóór een pilot aan deze vragen toetsen? Mail naar sales@kiteworks.com of start een gesprek. U hoeft Claude of MCP niet te hebben ingesteld om een vraag te stellen. In de agentcatalogus staan de vermelde beperkingen van elke agent.