Memory is een attack surface — ASI06 en de MemoryTrap-aanvalsketen
Security & InfrastructuurDe gevaarlijkste aanval op een AI coding agent is niet de prompt injection die je ziet aankomen. Het is degene die je agent zelf voorstelt, en die je goedkeurt omdat het "gewoon helpen" is.
Dat is de kern van Idan Habler's analyse op de OWASP Gen AI Security blog. Habler is co-lead van ASI06 (Memory & Context Poisoning) in de OWASP Top 10 for Agentic Applications, en senior AI security researcher bij Cisco. Zijn artikel is geen technische disclosure, die deed Cisco al eerder met MemoryTrap. Het is een position paper over waarom memory fundamenteel anders behandeld moet worden in agentic security.
Kernanalyse
De OWASP-publicatie stelt terecht dat memory in agentic AI geen gewone gebruikersfeature meer is, maar een security-relevante state layer. Het centrale punt is scherp: een agent verwerkt niet alleen input, maar kan context, memory, hooks en lokale configuratie meenemen naar toekomstige sessies. Daardoor verandert prompt injection van een vluchtige, sessiegebonden aanval in een persistente compromisroute. OWASP koppelt dit expliciet aan ASI06, "Memory & Context Poisoning", binnen de OWASP Top 10 for Agentic Applications.
De casus achter het artikel is Cisco's "MemoryTrap" onderzoek naar Claude Code. Daarin kon een normale developerflow, repository klonen, agent laten helpen, dependency-installatie goedkeuren, leiden tot manipulatie van memory, globale hooks en configuratie. Cisco beschrijft dat het effect persistent kon blijven over projecten, sessies en reboots heen.
De strategische boodschap: memory is niet alleen context, het is onderdeel van de agent-control-plane. Een memory file beïnvloedt toekomstige beslissingen, een hook kan elke interactie sturen, en lokale configuratie kan bepalen welke context of tools de agent vertrouwt. OWASP formuleert dit expliciet als het moment waarop convenience features security boundaries worden.
Waarom dit belangrijk is
Bij traditionele prompt injection probeert een aanvaller één output, één tool-call of één beslissing te beïnvloeden. Bij memory poisoning verschuift de aanval naar persistentie. De agent wordt niet alleen misleid, maar krijgt een vervuilde toekomstige werkelijkheid aangereikt.
Dat is fundamenteel anders voor enterprise risk:
| Dimensie | Klassieke prompt injection | Memory/context poisoning |
|---|---|---|
| Scope | Eén interactie of sessie | Sessies, projecten, reboots, soms teams |
| Doelwit | Modelgedrag op dat moment | Vertrouwde state en toekomstige besluitvorming |
| Detectie | Vaak zichtbaar in prompt/output | Vaak verborgen in memory, hooks of config |
| Impact | Fout antwoord of toolmisbruik | Structureel verzwakte secure SDLC, policy bypass, supply-chain amplificatie |
| Mitigatie | Prompt hardening, output filtering | State integrity, provenance, policy enforcement, endpoint controls |
Het risico zit vooral in de combinatie van drie factoren: agenten hebben toegang tot lokale bestanden en shell-commando's, developers vertrouwen assistenten in hun normale workflow, en memory wordt vaak impliciet behandeld als betrouwbare context. Cisco laat zien dat een npm-installatiestap, via bekende lifecycle hooks zoals postinstall, payloads kan activeren die memory en configuratie aanpassen.
Technische aanvalsketen
De aanvalsketen is realistisch omdat hij niet begint met iets exotisch, maar met een normale ontwikkelactie.
Eerst wordt een onbetrouwbare repository of dependency in de ontwikkelomgeving gebracht. Daarna adviseert de coding agent om dependencies te installeren. De gebruiker keurt dit goed, omdat dit past bij het normale patroon van "maak dit project werkend". Via package lifecycle hooks kan vervolgens code uitgevoerd worden. Cisco beschrijft dat de payload memory files en globale hookconfiguratie kon aanpassen, waaronder memory onder ~/.claude/projects/*/memory/MEMORY.md en settings onder ~/.claude/settings.json.
Daarna ontstaat persistentie. Cisco beschrijft ook een techniek waarbij een shell alias werd toegevoegd om auto-memory opnieuw in te schakelen, zelfs wanneer de gebruiker dit had uitgeschakeld. Daarmee wordt het probleem niet alleen "de agent las iets verkeerds", maar "de lokale trust fabric is aangepast".
Het eindresultaat is gedragsmanipulatie. In Cisco's voorbeeld kon een vergiftigde agent insecure guidance presenteren als best practice: hardcoded secrets aanbevelen, .env of environment variables afraden, en zonder waarschuwing een onveilige structuur scaffolden.
Belangrijke nuance bij Claude Code
De OWASP-blog verwijst naar Cisco's disclosure en stelt dat Anthropic in Claude Code v2.1.50 user memories uit de system prompt heeft verwijderd, waarmee de specifieke high-trust override-route werd beperkt.
De huidige Claude Code-documentatie maakt een belangrijk onderscheid: CLAUDE.md en auto memory worden als context gebruikt, niet als harde configuratie of enforcement-laag. Claude Code documenteert ook dat auto memory standaard aan staat, dat de eerste 200 regels of 25KB van MEMORY.md aan het begin van iedere conversatie worden geladen, en dat memory via /memory, autoMemoryEnabled of CLAUDE_CODE_DISABLE_AUTO_MEMORY beheerd kan worden.
Dat lost het bredere probleem niet op. Ook context met lagere autoriteit kan modelgedrag sturen, zeker bij agenten met tooltoegang. De juiste conclusie is dus niet "system prompt fix is voldoende", maar: alle persistente context moet integriteitscontrole, herkomstlabeling en least privilege krijgen.
Mapping naar OWASP-risico's
Deze casus raakt meerdere OWASP-categorieën tegelijk:
| OWASP-risico | Relevantie |
|---|---|
| ASI06, Memory & Context Poisoning | Kernrisico, aanvaller beïnvloedt persistente agentcontext |
| ASI04, Agentic Supply Chain Vulnerabilities | Entry via repository, dependency install, package hooks |
| ASI05, Unexpected Code Execution | Shell/npm lifecycle execution in agent workflow |
| ASI09, Human-Agent Trust Exploitation | Gebruiker keurt normale assistentactie goed zonder zicht op downstream impact |
| LLM01 Prompt Injection | Onderliggende techniek blijft instruction manipulation |
| LLM03 Supply Chain | Onbetrouwbare packages, repos en toolconfiguraties |
| LLM04 Data and Model Poisoning | Conceptueel verwant, maar hier gericht op runtime/context state |
| LLM06 Excessive Agency | Impact groeit wanneer agenten mogen lezen, schrijven en uitvoeren |
OWASP positioneert agentic security breder dan klassieke LLM-security omdat agenten plannen, handelen, tools gebruiken en workflows kunnen beïnvloeden. In de Agentic Top 10 wordt memory poisoning expliciet genoemd als risico dat gedrag lang na de initiële interactie kan hervormen, een inzicht dat de systematische review van 247 papers wetenschappelijk onderbouwt met de notie van "delayed reactivation through stored state."
Enterprise impact
Voor CISO's, platform teams en enterprise architects is dit vooral een secure developer workstation en AI agent runtime governance probleem.
De grootste impactgebieden:
Secure SDLC-integriteit. Een vergiftigde coding agent kan structureel onveilige patronen aanbevelen: secrets in code, zwakkere authenticatie, ontbrekende inputvalidatie, lagere testdekking, permissieve IAM-policies.
Supply-chain amplificatie. Eén kwaadaardige repository kan niet alleen de lokale build beïnvloeden, maar ook de agent die toekomstige projecten ondersteunt. Daarmee wordt de developer-assistent zelf onderdeel van de supply-chain.
Policy drift. Wanneer lokale memory of hooks securityrichtlijnen overschrijven of verwateren, ontstaat een verborgen laag naast officiële secure coding policies.
Forensische complexiteit. De oorzaak zit mogelijk niet in de uiteindelijke codewijziging, maar in een eerder vergiftigde memory file, hook, shell profile of projectconfiguratie.
Governance gap. Veel organisaties hebben beleid voor IDE's, CI/CD, secrets en endpoint security, maar nog geen control plane voor AI coding agents. Dit is precies de kloof die de OWASP Agentic AI Security Control Plane adresseert.
Risicoregister
| Risico | Waarschijnlijkheid | Impact | Prioriteit | Belangrijkste mitigaties |
|---|---|---|---|---|
| Persistente memory poisoning op developer workstation | Hoog bij brede agentadoptie | Hoog | Kritiek | Memory integrity monitoring, managed settings, disable auto memory voor high-risk workflows |
| Hook/config poisoning | Middel tot hoog | Hoog | Kritiek | Alleen managed hooks toestaan, FIM op .claude, shell profiles, IDE config |
| Supply-chain entry via dependency install | Hoog | Hoog | Kritiek | Sandbox, dependency policy, npm ci --ignore-scripts voor untrusted repos, SCA |
| Cross-project contamination | Middel | Hoog | Hoog | Project-isolatie, ephemeral devcontainers, aparte memory per trust zone |
| Human approval fatigue | Hoog | Middel tot hoog | Hoog | Risk-based prompts, privileged action review, agent action logging |
| Secret exposure via poisoned guidance | Middel | Hoog | Hoog | Secret scanning, deny-read voor .env, vault-only patterns, commit hooks |
| Incomplete detectie | Hoog | Middel | Hoog | SIEM telemetrie voor memory writes, hook changes, config reloads |
Aanbevolen control framework
Behandel memory, hooks en agentconfiguratie als tier-0 voor agentgedrag, vergelijkbaar met CI/CD pipelines, IAM policies en privileged developer tooling.
1. Classificeer agent memory als security state. Leg vast dat CLAUDE.md, auto memory, .claude/rules, hooks, MCP-configuratie, shell profiles en agent settings onder change control vallen. Niet alles hoeft centraal beheerd te zijn, maar alles moet minimaal herkomst, scope en integriteit hebben.
2. Scheid context van enforcement. Gedragsinstructies zijn onvoldoende als harde controle. De Claude Code-documentatie stelt expliciet dat permissions door de client worden afgedwongen en dat prompt- of CLAUDE.md-instructies alleen beïnvloeden wat de agent probeert te doen. Gebruik dus permission rules, managed settings, PreToolUse hooks en sandboxing voor harde beperkingen.
3. Gebruik managed policy voor enterprise defaults. Voor grotere organisaties zijn managed settings essentieel. Claude Code ondersteunt managed scopes die niet door user- of projectsettings overschreven kunnen worden, inclusief policies voor MCP servers, permission rules, hooks en auto memory.
Sterke baseline:
{
"autoMemoryEnabled": false,
"allowManagedHooksOnly": true,
"allowManagedMcpServersOnly": true,
"allowManagedPermissionRulesOnly": true,
"permissions": {
"deny": [
"Read(./.env)",
"Read(./.env.*)",
"Read(./secrets/**)",
"Bash(curl *)",
"Bash(wget *)"
],
"ask": [
"Bash(npm install *)",
"Bash(npm ci *)",
"Bash(pip install *)",
"Bash(terraform apply *)"
]
}
}
Dit is geen universele config, maar een bruikbaar startpunt voor regulated engineering teams. Pas hem aan op buildsystemen, package managers, OS en developer productivity-eisen.
4. Isoleer untrusted repositories. Gebruik ephemeral devcontainers of sandboxed workspaces voor onbekende repositories. De agent mag niet standaard bij ~/.claude, shell profiles, cloud credentials, SSH keys, Kubernetes config of enterprise secrets. Claude Code ondersteunt sandbox filesystem- en networkrestricties, waarbij OS-level sandboxing subprocessen zoals npm, kubectl en terraform kan beperken.
5. Monitor memory en hook wijzigingen. Minimaal monitoren:
~/.claude/
~/.claude/projects/*/memory/
~/.claude/settings.json
~/.claude/rules/
./CLAUDE.md
./.claude/
./.mcp.json
~/.bashrc
~/.zshrc
~/.config/
Detectieregels moeten alerten op patronen zoals "ignore security", "hardcode secrets", "disable validation", "do not use vault", "always approve", wijzigingen aan hooks, en onverwachte writes naar globale agentconfiguratie. Claude Code biedt hooks zoals InstructionsLoaded en ConfigChange, en debug logging voor hook-uitvoering, die bruikbaar zijn voor detectie en forensiek.
6. Behandel hooks als code execution. Hooks zijn krachtig, maar hoog-risico. Anthropic documenteert dat command hooks met de volledige permissies van de systeemgebruiker draaien en bestanden kunnen wijzigen, verwijderen of lezen waartoe die gebruiker toegang heeft. De documentatie adviseert inputvalidatie, quoting, path traversal checks, absolute paths en het overslaan van gevoelige bestanden.
Enterprise beleid: geen user-defined hooks buiten sandbox, alleen signed of managed hooks, geen HTTP hooks zonder allowlist, geen hooks uit repositories zonder review.
7. Voeg agentic AI red teaming toe. Testcases die je in een red-teamprogramma moet opnemen:
- Malicious repo met postinstall payload
- Poisoned
CLAUDE.mdmet subtiele insecure coding guidance - Hook die elke prompt verrijkt met malafide context
- Shell profile wijziging die security settings terugdraait
- MCP server die context of toolresultaten manipuleert
- Cross-worktree memory contamination
- Subagent memory poisoning
- Prompt die secure coding policies langzaam afzwakt in plaats van expliciet uitschakelt
Incident response playbook
Bij vermoeden van memory poisoning:
- Stop de agent en isoleer de workstation of devcontainer
- Archiveer memory, hooks, settings, shell profiles, recent cloned repos, package lockfiles en terminal history
- Vergelijk
~/.claude,.claude/,CLAUDE.md,.mcp.json,.bashrc,.zshrcmet baseline - Verwijder verdachte memory en hooks, herstel managed policy
- Roteer secrets die toegankelijk waren voor de agent of shell
- Review alle commits, PR's en gegenereerde code sinds het vermoedelijke compromis
- Voeg detectieregels toe voor dezelfde persistence path
- Hertrain developers: dependency approval is geen low-risk actie meer wanneer een agent shelltoegang heeft
Kritische beoordeling van de OWASP-publicatie
De analyse is sterk omdat hij een productincident abstraheert naar een breder architectuurprincipe: stateful agents hebben stateful attack surfaces. De koppeling met ASI06 is overtuigend en nuttig voor governance.
De beperking is dat de OWASP-blog compact is en vooral een interpretatieve analyse geeft. De diepere technische details staan in Cisco's MemoryTrap-publicatie. Ook is de oorspronkelijke Claude Code-route deels gemitigeerd door user memories uit de system prompt te verwijderen, waardoor deze specifieke exploitpad-context historisch moet worden gelezen.
De bredere conclusie blijft echter actueel. De huidige documentatie bevestigt dat memory en instructiebestanden nog steeds bij sessiestart in context komen, dat auto memory standaard aan staat, en dat enforcement via permissions, hooks, managed settings en sandboxing moet gebeuren, niet via geheugeninstructies alleen. Dit sluit naadloos aan op eerdere analyses van RushDB's schema-loze memory-model en Supermemory's governance-gap: zonder expliciete governance verandert flexibiliteit in semantische vervuiling.
Bottom line
OWASP heeft hier gelijk: memory is een attack surface. Voor enterprise AI-adoptie betekent dit dat agent memory, context, hooks, MCP-configuratie en lokale settings onder dezelfde governance moeten vallen als CI/CD pipelines, IAM policies en privileged developer tools.
Mijn praktische advies: zet voor AI coding agents een minimale enterprise baseline neer met managed settings, sandboxing, memory-integrity monitoring, MCP allowlisting, hook governance en red-team testcases. Anders bouw je secure SDLC bovenop een agent die zelf persistent kan worden geherprogrammeerd.
Gebaseerd op: Idan Habler (13 mei 2026). "Memory Is a Feature. It Is Also an Attack Surface." OWASP Gen AI Security Project. Habler is co-lead van ASI06 (Memory & Context Poisoning) in de OWASP Top 10 for Agentic Applications en senior AI security researcher bij Cisco. De technische details van de MemoryTrap-kwetsbaarheid zijn afkomstig uit Cisco's oorspronkelijke disclosure.
AI & Security Intelligence
Wekelijkse nieuwsbrief met AI updates, security alerts en compliance inzichten, direct in uw inbox.
Security & AI Operating Model
Advisory met executiekracht
Van BIO2 en NIS2 tot EU AI Act, embedded in uw operating model, niet als extern project. Maandelijks opzegbaar, met assessments als bewijsvoering.