Memory is een attack surface — ASI06 en de MemoryTrap-aanvalsketen

De 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.md met 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:

1. Stop de agent en isoleer de workstation of devcontainer
2. Archiveer memory, hooks, settings, shell profiles, recent cloned repos, package lockfiles en terminal history
3. Vergelijk ~/.claude, .claude/, CLAUDE.md, .mcp.json, .bashrc, .zshrc met baseline
4. Verwijder verdachte memory en hooks, herstel managed policy
5. Roteer secrets die toegankelijk waren voor de agent of shell
6. Review alle commits, PR's en gegenereerde code sinds het vermoedelijke compromis
7. Voeg detectieregels toe voor dezelfde persistence path
8. 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.