Een op het oog kleine fout in een preview-functie kan grote gevolgen hebben. Volgens The Hacker News bevatte het AI-platform van Writer een kritieke kwetsbaarheid in de agent-previewfunctie: die kon de sessiecookie van een slachtoffer doorsturen naar een sandbox die door een aanvaller werd beheerd. Daarmee werd cross-tenant accountovername mogelijk, inclusief toegang tot privéchats, documenten, agents, connectors en LLM-inloggegevens. Writer heeft het probleem verholpen door previews te isoleren en het doorsturen van cookies te stoppen.
Het opvallende aan dit incident is dat er geen model-jailbreak aan te pas kwam. De AI zelf gedroeg zich niet verkeerd; de grens tussen gebruikers, projecten en sessies was verkeerd getrokken. Dat maakt het een leerzaam voorbeeld: gevoelige inhoud kan bij de verkeerde partij belanden puur doordat geheugen, caches, previews of werkruimtes gedeeld zijn.
Waarom deze lekken structureel zijn
Dat sessie- en cross-user-lekkage geen toevallige bug is maar een eigenschap van het systeemontwerp, wordt onderbouwd door recent academisch werk. Een overzichtsstudie in Frontiers in Computer Science beschrijft hoe agentische AI-systemen gevoelige informatie kunnen bewaren, doorgeven en opnieuw blootstellen over taken, gebruikers en sessies heen. Dat gebeurt via persistent geheugen, vectordatabases, logs, tool-gebruik en feedbackloops. De auteurs concluderen dat geheugenscheiding en levenscyclusbewuste controles nodig zijn om dit te voorkomen.
Met andere woorden: zodra een AI-systeem toestand deelt tussen sessies of gebruikers, ontstaat er een pad waarlangs informatie kan lekken. Het gaat niet om de vraag of het model iets "verkeerd" zegt, maar om de vraag welke gegevens überhaupt in de context, het geheugen of de cache terechtkomen die ook voor anderen toegankelijk zijn.
Hetzelfde patroon in AI-werkruimtes
Dat dit patroon niet beperkt is tot chat- en agentfuncties, laat onderzoek van Tenable Research zien. In Google Cloud Vertex AI Workbench bestond een cross-tenant kwetsbaarheid die volledige accountovername mogelijk maakte. Die draaide om beheerde end-user-credentials, metadata en een startup-script dat na minimale interactie inloggegevens kon exfiltreren. Ook hier lag het probleem in gebrekkige isolatie tussen tenants, en werd het opgelost door de kwetsbare onderdelen te verwijderen.
De rode draad tussen Writer en Vertex AI Workbench is duidelijk: of het nu gaat om een agent-preview of een beheerde notebook-omgeving, projectgebonden AI-werkruimtes kunnen inloggegevens en toegang laten weglekken zodra de scheidslijnen tussen gebruikers en projecten niet strak genoeg zijn.
Wat de juiste verdediging is
De AI Agent Security Cheat Sheet van OWASP vertaalt dit naar concrete maatregelen. De richtlijn beschrijft dat AI-systemen geheugenscheiding tussen gebruikers en sessies moeten toepassen, data moeten valideren en opschonen voordat die in het geheugen van een agent belandt, en gedeelde toestand moeten vermijden die over grenzen heen kan lekken. Isolatie is daarmee een vereiste controle, geen optionele hardening.
Praktische achtergrond bij het testen hiervan levert Giskard, dat strikte sessie- en gebruikersisolatie, output-redactie, toegangscontrole en het uitschakelen van gedeelde caching benoemt als de juiste verdediging tegen cross-session-lekkage in AI-systemen met meerdere gebruikers.
De les voor teams is dat je isolatie expliciet moet ontwerpen en niet mag afleiden uit het gedrag van het model. De vragen die telkens terugkomen: welke gegevens komen in het geheugen? Wie kan diezelfde cache of preview bereiken? Wat gebeurt er met tokens en credentials als een sandbox wordt gestart? En hoe wordt toestand opgeruimd aan het einde van een sessie?
De verbinding met werken bij Vera
Voor professionals die met vertrouwelijke dossiers werken, is deze reeks incidenten relevant omdat het niet om exotische aanvallen gaat, maar om alledaagse ontwerpkeuzes rond grenzen en gedeelde toestand. Bij I am Vera is het uitgangspunt daarom dat gevoelige inhoud zo min mogelijk in gedeelde AI-context terechtkomt.
De Semantic Privacy Shield is erop ontworpen dat voorbewerking en anonimisering op EU-infrastructuur plaatsvinden, en dat de workflow alleen geanonimiseerde inhoud naar de geselecteerde AI-modellen stuurt. Bij een mislukte privacycontrole wordt niets doorgestuurd. Dat verandert waar het risico ligt: als de inhoud die een model bereikt al geanonimiseerd is, is er minder herleidbare informatie die via geheugen, cache of preview bij de verkeerde partij kan opduiken.
Daarnaast maakt Vera als verificatielaag de controlestappen zichtbaar, zodat een gebruiker meer zicht krijgt op wat er met inhoud gebeurt. En met Vera Office kunnen documenten binnen dezelfde beveiligde omgeving worden bekeken en bewerkt, zonder ze naar losse, minder gecontroleerde werkruimtes te verplaatsen. Vera garandeert geen correctheid en geen perfecte anonimisering; het doel is om controle mogelijk te maken en het aantal plekken waar vertrouwelijke inhoud gedeeld raakt, te beperken.
De boodschap van de recente incidenten en richtlijnen is nuchter: isolatie tussen gebruikers, projecten en sessies is een ontwerpeis. Wie AI inzet voor gevoelig werk, doet er goed aan te controleren waar toestand gedeeld wordt, en het professionele eindoordeel over de uitkomst blijft altijd bij de gebruiker zelf.