AI-geheugen is de nieuwe datalekvector

Je moet geheugen in AI-assistenten behandelen als een afzonderlijke beveiligde gegevenslaag, niet als een onschuldige gebruikersfunctie. Zonder expliciete controle op wat daar wordt opgeslagen, welke tools eraan kunnen, en hoe het wordt gewist, creëer je een nieuw datalekrisico.

An analysis of 18 August 2026 of how AI memory functions create a distinct data leakage vector argues that persistent memory in AI assistants, when combined with tool access and web retrieval, enables attackers to extract personal data through indirect prompt injection. A security researcher demonstrated that standard memory features could be exploited to exfiltrate a user's name, employer and inferred location by embedding malicious instructions in external content. In our assessment, this means you can no longer treat memory as a transparent feature layer — it is now a distinct data processing component that requires the same architectural controls you would apply to any other system that stores and retrieves personal information.

Hoe ontstaat het lekrisico in geheugenfuncties?

Het kernprobleem is indirecte prompt injection. Wanneer een AI-assistent geheugen combineert met tools die externe content ophalen — webpagina's, e-mails, documenten — kunnen verborgen instructies in die content de assistent aansturen om gevoelige gegevens uit het geheugen op te zoeken en naar een aanvaller te sturen. De aanval verloopt via HTTP-verzoeken die voor de gebruiker onzichtbaar blijven. Dit patroon is niet uniek aan één provider; het volgt uit de architectuur van agentische AI zelf: geheugen plus tools plus externe content vormt een aanvalsketen.

De risico's strekken zich verder uit dan alleen het onthouden van trainingsdata. Academisch onderzoek onderscheidt direct leakage (via breuk in provider-systemen of misleidende beleid) van indirect leakage (via autonome agents en prompt injection). Beide vormen kunnen persoonlijke gegevens uit conversatiegeschiedenis, chatlogs en agentgeheugen vrijgeven.

Welke gegevensrisico's moet je expliciet adresseren?

• Indirecte prompt injection via externe content — verborgen instructies in webpagina's, e-mails of documenten kunnen de assistent aansturen om geheugengegevens te exfiltreren.
• Hyper-gepersonaliseerde profielen in geheugen — langdurige opslag van interactiegeschiedenis creëert profielen met expliciete en afgeleide gegevens over gezondheid, relaties en financiën.
• Verborgen opslag na gebruikersverwijdering — verwijdering in de interface garandeert niet dat gegevens uit vectorstores, caches en conversatielogs zijn gewist.
• Dwangvorderingen en juridische blootstelling — geheugen vergroot het oppervlak voor rechtbanken die providers dwingen conversatielogs te bewaren en over te handigen.
• Ongecontroleerde toolkombinaties — geheugen en tools die zonder scheiding samen werken, vergroten het risico op onbedoelde datavrijgave.

Hoe kwalificeren regelgevers geheugen nu?

De Franse gegevensbeschermingsautoriteit CNIL en CIANum hebben persistent geheugen in juli 2026 expliciet als eerste GDPR-risico voor agentische AI aangemerkt. Dat betekent dat langdurige opslag van interactiegeschiedenis nu als profiling onder de GDPR wordt gekwalificeerd. Organisaties moeten auditen wat geheugen precies opslaat, hoe wissing wordt afgehandeld (inclusief vectorstores en caches), alle diensten die agents raken inventariseren, en contractueel borgen dat providers hun verplichtingen nakomen. Daarnaast moet je een audittrail van agentacties met persoonsgegevens bijhouden.

Deze kwalificatie heeft directe gevolgen. Providers hebben in sommige rechtsgebieden geheugenfeatures beperkt na GDPR-handhaving. Rechtbanken hebben providers gedwongen conversatielogs te bewaren en over te handigen, ook wanneer gebruikers die expliciet hadden verwijderd. Dit toont aan dat geheugen niet alleen een technisch vraagstuk is, maar een juridisch risico dat je actief moet beheren.

Welke concrete controles moet je kunnen aantonen?

1. Definieer welke gegevens in geheugen mogen komen — documenteer per workflow welke gegevenscategorieën mogen worden opgeslagen en onder welke voorwaarden.
2. Scheidt geheugen, conversatiegeschiedenis, vectorstores en caches — zorg dat deze lagen fysiek of logisch gescheiden zijn en afzonderlijke retentie- en wissingregels volgen.
3. Implementeer expliciete opt-in en opt-out voor geheugen — maak geheugeninstellingen zichtbaar en controleerbaar voor gebruikers, niet standaard ingeschakeld.
4. Beperk welke tools en externe content het geheugen mogen beïnvloeden — voorkomen dat web-retrieval of ongecontroleerde toolkombinaties geheugen kunnen triggeren.
5. Onderhoud audittrails van agentacties met persoonsgegevens — leg vast welke gegevens uit geheugen zijn opgehaald, door welke agent, op welk moment en met welk resultaat.

Wat kunnen tools voor je doen, en wat niet?

Verificatielagen kunnen helpen zichtbaar te maken hoe een taak door geselecteerde modellen loopt, inclusief verificatiestappen, correcties en bronnen ter inspectie. Dat garandeert geen correctheid, maar het maakt controle mogelijk. Voor gevoelige documenten kunnen privacyschermen vertrouwelijke waarden vervangen door synthetische, sessiegebonden equivalenten voordat de AI-keten aan het werk gaat. Zulke architecturen werken best op basis van fail-closed: mislukt de privacycontrole, dan wordt het document niet doorgestuurd.

Maar tools kunnen je eindoordeel niet vervangen. Ze kunnen transparantie bieden en risico's verkleinen, maar de beslissing welke gegevens in geheugen mogen, hoe lang ze daar blijven, en welke tools eraan mogen, blijft altijd bij jou.