Geheugen van AI-agents als beveiligingsoppervlak
De Cloud Security Alliance beschrijft met MemGhost hoe één e-mail een blijvende valse herinnering in een AI-agent plant.
U moet het geheugen van een AI-agent als een afzonderlijk beveiligingsoppervlak behandelen: label de herkomst van elke herinnering, scheid gebruikersinstructies van externe documenten, eis expliciete bevestiging voor gevoelige geheugenschrijfacties en log alle wijzigingen.
Een analyse van 26 september 2026 van geheugenvergiftiging in AI-agents via externe berichten stelt dat één speciaal vervaardigde e-mail een blijvend vals geheugen in een agent kan planten. Het onderzoek documenteert hoe besmette herinneringen persistent blijven en latere sessies kunnen beïnvloeden, ook wanneer de oorspronkelijke bron niet meer zichtbaar is. In onze inschatting ligt het kritieke moment niet in het antwoord op één bericht, maar in de overgang van onbetrouwbare externe inhoud naar vertrouwde, persistente staat — een risico dat alleen door herkomstcontrole en expliciete goedkeuring kan worden beheerst.
Wat onderscheidt geheugenvergiftiging van gewone prompt injection?
Bij gewone prompt injection zit het risico in het antwoord van dat ene gesprek. De aanval eindigt wanneer de sessie eindigt. Bij geheugenvergiftiging verandert de aanval de blijvende staat van de agent. Twee academische studies onderbouwen dit onderscheid. De ene introduceert een taxonomie van vier geheugen-schrijfkanalen en negen structurele kwetsbaarheden, met een gemiddelde aanvalsucces van ruim 50 procent. De andere 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.
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.
Welke risico's moet u adresseren?
- Herkomstverwarring — externe inhoud wordt zonder label als vertrouwde herinnering opgeslagen.
- Stille vergiftiging — een vals geheugen blijft bestaan en stuurt gedrag in latere sessies zonder zichtbare bron.
- Ongeautoriseerde schrijfacties — geheugen wordt gewijzigd zonder expliciete gebruikersgoedkeuring of audit trail.
- Encryptie zonder inhoudelijke controle — versleutelde opslag beschermt niet tegen vals geheugen; encryptie en betrouwbaarheid zijn afzonderlijke problemen.
- Onvoldoende logging — schrijf-, lees- en verwijderacties zijn niet traceerbaar.
Welke concrete controles moet u kunnen aantonen?
- Label de herkomst van elke herinnering — documenteer welke externe bron (e-mail, document, webpagina, repository) tot elke geheugenopslag heeft geleid.
- Scheid gebruikersinstructies van externe inhoud — behandel deze als verschillende kanalen met verschillende vertrouwensniveaus.
- Eis expliciete bevestiging voor gevoelige geheugenschrijfacties — laat de gebruiker goedkeuren voordat informatie persistent wordt opgeslagen.
- Log alle geheugenwijzigingen — registreer wie wat wanneer heeft geschreven, gelezen of verwijderd.
- Integreer geheugenlogboeken in incidentrespons — zorg dat een foutieve herinnering aantoonbaar kan worden gecorrigeerd of verwijderd.
Hoe past encryptie in dit plaatje?
Aanbieders proberen persistent geheugen privacyvriendelijk te maken met versleutelde opslag in hardware-geïsoleerde cloud-enclaves, waarbij cryptografische sleutels uitsluitend op persoonlijke apparaten blijven. Dat adresseert de vraag wie de opgeslagen geheugendata kan ontsleutelen. Het adresseert niet de vraag of wat wordt onthouden inhoudelijk klopt en of het opslaan geautoriseerd was. Encryptie en enclaves beschermen de opslag; ze beoordelen de betrouwbaarheid van de inhoud niet. Een versleuteld vals geheugen blijft een vals geheugen.
Geheugenfuncties vereisen daarom twee afzonderlijke controles: één op de beveiliging van de opslag zelf, en één op de herkomst en autorisatie van wat wordt opgeslagen.
Hoe begint u praktisch?
Geheugenschrijfacties verdienen dezelfde behandeling als andere gevoelige agenthandelingen. Wie AI-agents al een eigen identiteit met gelogde autorisatie geeft, breidt dat logboek uit naar geheugen. 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.
De gerapporteerde slaagpercentages van aanvallen zijn naar onze inschatting geen reden om 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 controleerbaar; de effectiviteit van verdedigingen niet zonder eigen validatie. Tooling kan logging en herkomstlabeling automatiseren. De beoordeling van wat in het geheugen thuishoort en wanneer een schrijfactie geautoriseerd is, blijft uw eigen professionele oordeel.
Bronnen: Dit artikel is gebaseerd op berichtgeving en richtlijnen van Cloud Security Alliance AI Safety Initiative, arXiv en Google DeepMind.
Geschreven door
Marit Halversen
Schrijft over AI-governance en regelgeving, met de nadruk op hoe verplichtingen neerslaan in architectuur in plaats van in papierwerk.