Blog

Behandel het geheugen van AI-agents als apart beveiligingsoppervlak met herkomst en goedkeuring

De Cloud Security Alliance beschrijft met MemGhost hoe één e-mail een blijvende valse herinnering in een AI-agent plant.

· Door

Van bovenaf gefotografeerde bureau met een geopende envelop waaruit een dunne, vertakkende draad naar een rij gesloten archiefkasten loopt.
Eén e-mail kan een blijvend vals geheugen in een AI-agent planten dat latere sessies beïnvloedt.Beeld: IamVera.ai — originele redactionele illustratie

Behandel het geheugen van een AI-agent als een apart beveiligingsoppervlak: label de herkomst van elke herinnering, scheid gebruikersinstructies van externe documenten en e-mails, eis expliciete bevestiging voor gevoelige geheugenschrijfacties en log schrijven, lezen en verwijderen. Volgens de Cloud Security Alliance kan één e-mail al een persistent vals geheugen planten.

Op 23 juli 2026 publiceerde het AI Safety Initiative van de Cloud Security Alliance een onderzoeksnotitie over MemGhost, een aanval die via één speciaal vervaardigde e-mail een blijvend vals geheugen in een AI-agent kan planten. De besmette herinnering blijft daarna bestaan en kan in een latere sessie het gedrag van de agent beïnvloeden, ook wanneer de oorspronkelijke e-mail niet meer zichtbaar is. De Cloud Security Alliance meldt hoge end-to-end-succes- en stealthpercentages in de aangehaalde evaluaties, maar benadrukt zelf dat de steekproeven per conditie bescheiden zijn en de cijfers indicatief moeten worden gelezen.

Naar onze inschatting is dat de kern: het kritieke moment ligt niet bij het antwoord dat de assistent op dat ene bericht geeft, maar bij de overgang van onbetrouwbare externe inhoud naar vertrouwde, persistente staat. Wie geheugen alleen beoordeelt op opslagprivacy, mist die overgang volledig.

Waarom is memory poisoning een ander probleem dan gewone prompt injection?

Bij gewone prompt injection zit het risico in het antwoord van dat ene gesprek. Bij geheugenvergiftiging verandert de aanval de blijvende staat van de agent. Twee academische studies onderbouwen dat onderscheid.

De studie From Untrusted Input to Trusted Memory introduceert een taxonomie van vier geheugen-schrijfkanalen en negen structurele kwetsbaarheden. De auteurs rapporteren over de onderzochte agents een gemiddelde attack-success-rate van 50,46 procent en een retrieval-success-rate van 41,05 procent. Volgens hun analyse dekken bestaande prompt-injectionverdedigingen memory poisoning niet volledig af. De studie Hidden in Memory onderzoekt sleeper memory poisoning, waarbij een aanvaller externe documenten, webpagina's, e-mails of repositories manipuleert zodat een gefabriceerde herinnering wordt opgeslagen. Volgens die studie beïnvloedden succesvolle geïnjecteerde herinneringen in latere agentische evaluaties in 60 tot 89 procent van de gevallen het door de aanvaller gewenste gedrag; de auteurs melden zelf beperkingen, waaronder gedeeltelijk gereconstrueerde providerconfiguraties en het gebruik van een LLM-judge voor sommige metingen.

Het praktische verschil in één regel:

  • Prompt injection probeert de huidige context of het huidige gedrag van de agent te beïnvloeden; memory poisoning schrijft bovendien naar persistente staat, waardoor de invloed naar latere sessies kan doorwerken.
  • Memory poisoning schrijft naar persistente staat en werkt door in latere sessies.
  • Volgens de auteurs laten de studies zien dat bestaande prompt-injectionverdedigingen memory poisoning niet volledig afdekken; Hidden in Memory waarschuwt bovendien dat promptmatige verdedigingen modelafhankelijk en kwetsbaar voor adaptieve aanvallen blijven.

Dat maakt het geheugen tot een eigen aanvalsoppervlak, niet tot een detail van invoerfiltering. Het hoort thuis bij de bredere vraag naar AI-security en beveiligingsoppervlakken, en sluit aan bij het idee om least privilege als runtime-controle voor AI-agents te behandelen.

Lost server-side geheugen met encryptie en enclaves dit op?

Aanbieders proberen persistent geheugen juist privacyvriendelijk te maken. Google DeepMind beschreef op 23 september 2026 een architectuur voor persistent geheugen op meerdere apparaten, waarbij persoonlijke gegevens in versleutelde opslag binnen hardware-geïsoleerde cloud-enclaves worden verwerkt. Volgens die aankondiging blijven cryptografische sleutels uitsluitend op persoonlijke apparaten, worden gegevens na verwerking opnieuw versleuteld en worden tamper-proof software-attestatie, een technisch whitepaper en een onafhankelijke audit als verificatiemechanismen genoemd.

Dat adresseert de vraag wie de opgeslagen geheugendata kan ontsleutelen. Naar onze inschatting adresseert het niet de vraag of wat wordt onthouden inhoudelijk klopt en of het opslaan überhaupt geautoriseerd was. Encryptie en enclaves beschermen de opslag; ze beoordelen de betrouwbaarheid van de inhoud niet. Een versleuteld vals geheugen blijft een vals geheugen.

Daaruit volgt onze centrale redactionele stelling: geheugenfuncties vereisen twee afzonderlijke controles.

  1. Infrastructuurprivacy van opgeslagen geheugen: encryptie, sleutelbeheer, isolatie en aantoonbare verwijdering.
  2. Integriteitscontrole op wat mag worden onthouden: herkomst, autorisatie en scheiding van externe inhoud.

Welke controles horen bij het geheugen van een AI-agent?

De aanbevelingen van de Cloud Security Alliance en de twee studies wijzen dezelfde richting op: geheugenprovenance, expliciete gebruikersbevestiging, logging van elke wijziging en scheiding tussen het lezen van externe inhoud en het schrijven naar geheugen. Vertaald naar een werkbare checklist voor professionals met gevoelige informatie:

  • Label de herkomst van iedere geheugenregel, zodat extern afgeleide herinneringen herkenbaar blijven.
  • Scheid gebruikersinstructies strikt van externe documenten en e-mails; behandel binnenkomende inhoud niet automatisch als betrouwbare context.
  • Eis expliciete bevestiging voordat gevoelige of actiegerichte herinneringen worden opgeslagen.
  • Log schrijven, lezen, wijzigen en verwijderen van geheugen als aparte gebeurtenissen.
  • Quarantineer extern afgeleide herinneringen tot ze zijn gecontroleerd.
  • Test of het ophalen van een herinnering geen ongeautoriseerde acties activeert.

De genoemde bronnen leveren de cijfers, maar melden ook hun beperkingen: bescheiden steekproeven, gedeeltelijk gereconstrueerde configuraties en modelafhankelijke verdedigingen. Dat is naar onze inschatting geen reden om de maatregelen uit te stellen, maar wel om ze te behandelen als beheersmaatregelen die getest en gelogd moeten worden, niet als sluitend bewijs. Herkomstcontrole en goedkeuring bij het schrijven zijn te controleren; de gerapporteerde slaagpercentages van aanvallen niet zonder eigen validatie.

Praktisch betekent dit dat geheugenschrijfacties dezelfde behandeling verdienen als andere gevoelige agenthandelingen. Wie AI-agents al een eigen identiteit met gelogde autorisatie geeft, breidt dat logboek uit naar geheugen. En wanneer een besmette herinnering later toch gedrag stuurt, helpt het om vooraf incidentrespons over de hele AI-keten vast te leggen, zodat de schrijf- en leesroute traceerbaar blijft en een foutieve herinnering aantoonbaar kan worden gecorrigeerd of verwijderd.

Bronnen en referenties

  1. MemGhost: Persistent Memory Poisoning via a Single EmailCloud Security Alliance AI Safety Initiative · 2026-07-23
  2. From Untrusted Input to Trusted Memory: A Systematic Study of Memory Poisoning Attacks in LLM AgentsarXiv · 2026-06-03
  3. Hidden in Memory: Sleeper Memory Poisoning in LLM AgentsarXiv · 2026-05-18
  4. Advancing Private AI Compute with secure, server-side memoryGoogle DeepMind · 2026-09-23

Bronnen: Het artikel steunt op de MemGhost-notitie van de Cloud Security Alliance, de arXiv-studies From Untrusted Input to Trusted Memory en Hidden in Memory, en de architectuuraankondiging van Google DeepMind.

← Alle artikelen in dit thema ← Alle artikelen