Datalekken tussen gebruikers en sessies zijn een ontwerpprobleem

Je moet nu controleren waar toestand en geheugenbuffers in je AI-systemen gedeeld worden tussen gebruikers, projecten en sessies. Dit is geen configuratiekwestie — het is een architectuurkeuze die je expliciet moet maken en documenteren.

De aanleiding is een analyse van 1 augustus 2026 van sessie-isolatiefouten in AI-platforms, die aantoont dat lekkage tussen gebruikers niet voortkomt uit model-jailbreaks maar uit gebrekkige grenzen in het systeemontwerp. Het concrete geval is een kwetsbaarheid in een agent-previewfunctie die sessiecookies doorstuurde naar door aanvallers beheerde sandboxen, waardoor cross-tenant accountovername mogelijk werd. In onze beoordeling betekent dit dat je niet kunt vertrouwen op het gedrag van het model zelf om gevoelige informatie te beschermen — je moet de architectuur zo inrichten dat gevoelige gegevens niet in gedeelde contexten terechtkomen.

Waar ontstaat het risico in een multi-user AI-systeem?

Het kernprobleem is dat AI-systemen toestand bijhouden: geheugen, caches, logs, vectordatabases, previews en feedbackloops. Zodra deze toestand gedeeld wordt tussen sessies of gebruikers, ontstaat er een pad waarlangs informatie kan lekken. Dit is geen bug in het model, maar een eigenschap van het systeemontwerp. Academisch onderzoek toont aan dat agentische AI-systemen gevoelige informatie kunnen bewaren en opnieuw blootstellen via persistent geheugen, tool-gebruik en gedeelde werkruimtes. Het patroon is niet beperkt tot chat- of agentfuncties: kwetsbaarheden in beheerde notebook-omgevingen en cloud-workspaces volgen dezelfde logica — gebrekkige isolatie tussen tenants maakt accountovername mogelijk.

De rode draad tussen verschillende incidenten is duidelijk: of het nu gaat om een agent-preview of een beheerde werkruimte, projectgebonden AI-systemen kunnen inloggegevens en toegang laten weglekken zodra de scheidslijnen niet strak genoeg zijn.

Welke foutmodi moet je voorkomen?

• Gedeelde geheugen en caches tussen sessies — informatie uit een vorige sessie blijft beschikbaar voor volgende gebruikers of taken.
• Toestand in previews en sandboxen — sessiecookies, tokens of credentials worden onbedoeld doorgestuurd naar geïsoleerde omgevingen die door anderen bereikt kunnen worden.
• Logs en feedbackloops zonder gebruikersgrenzen — systeemfeedback of debug-informatie bevat details van andere gebruikers of projecten.
• Vectordatabases en persistent geheugen zonder strikte isolatie — embeddings of opgeslagen context worden gedeeld tussen werkstromen of tenants.
• Credentials in gedeelde werkruimtes — inloggegevens voor externe tools of modellen worden opgeslagen op plekken die meerdere gebruikers kunnen bereiken.

Welke controles moet je kunnen aantonen?

1. Definieer isolatiegrenzen per sessie, gebruiker en project — document welke gegevens in welke context terechtkomen en wie die context kan bereiken.
2. Valideer en schoon gegevens voordat ze in het geheugen van een agent belanden — zorg dat alleen geanonimiseerde of gereduceerde inhoud in gedeelde buffers terechtkomt.
3. Zet gedeelde caching uit of beperk het tot niet-gevoelige data — als caching nodig is, zorg dan dat gevoelige inhoud nooit in de cache belandt.
4. Verwijder toestand aan het einde van elke sessie — implementeer expliciete cleanup-routines die geheugen, logs en tijdelijke bestanden wissen.
5. Test isolatie onder aanval — simuleer wat gebeurt als een aanvaller toegang tot een sandbox of preview probeert te krijgen, en controleer of credentials of gegevens van andere gebruikers zichtbaar worden.

Hoe zorg je ervoor dat gevoelige inhoud niet in gedeelde AI-context terechtkomt?

De praktische benadering is om voorbewerking en anonimisering dicht bij de bron te doen, voordat inhoud naar AI-modellen gaat. Dit beperkt het aantal plekken waar vertrouwelijke gegevens gedeeld raken. Zorg dat de workflow alleen geanonimiseerde inhoud naar modellen stuurt, en maak de controlestappen zichtbaar zodat gebruikers inzicht krijgen in wat er met hun gegevens gebeurt. Vermijd het verplaatsen van gevoelige documenten naar losse, minder gecontroleerde werkruimtes — houd ze in dezelfde beveiligde omgeving waar ze kunnen worden bekeken en bewerkt.

De verificatielaag moet duidelijk maken welke stappen zijn doorlopen en waar isolatie is toegepast. Dit geeft je team en je gebruikers grip op het risico.

Wat kan tooling doen en wat blijft jouw verantwoordelijkheid?

Tooling kan isolatie afdwingen, caching beheren, credentials beveiligen en logs schoonmaken. Maar het professionele eindoordeel over wat gevoelig is en waar het veilig kan worden verwerkt, blijft altijd bij jou. Geen tool garandeert perfecte anonimisering of correctheid. Het doel is controle mogelijk te maken en het aantal plekken waar vertrouwelijke inhoud gedeeld raakt, te beperken. Je moet zelf bepalen welke gegevens in welke context horen, en je moet die keuze documenteren en testen.