# Memory Is a Feature. It Is Also an Attack Surface > Source: > Published: 2026-05-14 01:05:44+00:00 As co-lead of **OWASP ASI06: Memory & Context Poisoning **entry as part of [OWASP Top 10 for Agentic Applications](https://genai.owasp.org/2025/12/09/owasp-top-10-for-agentic-applications-the-benchmark-for-agentic-security-in-the-age-of-autonomous-ai/) , I have spent a lot of time thinking about a simple question: what happens when an AI agent does not just process untrusted input, but carries it forward? That is the core issue behind ASI06. Agentic systems do not just respond in the moment. They retain context, reuse memory, and rely on persistent state to guide future reasoning and actions. That is what makes them useful. It is also what makes them vulnerable. That is exactly why our recent **Cisco** research on Claude Code stood out to me. In the vulnerability we called [ MemoryTrap](https://blogs.cisco.com/ai/identifying-and-remediating-a-persistent-memory-compromise-in-claude-code), we found that a routine developer workflow could turn into persistent prompt injection. The path was surprisingly ordinary: clone a repository, let the agent help, approve a dependency installation, and move on. But the malicious payload did not stay inside the project. Instead, it reached **persistent memory**, the **global hooks configuration**, and even influenced a highly trusted instruction layer through the **system prompt**. In other words, a one-time action could shape the model’s future behavior across sessions, projects, and even reboots. That is what made this finding so important to me. It was not just another prompt injection story. It was a very real example of the exact risk ASI06 is meant to highlight: attacker-controlled content poisoning memory and context that the system continues to trust over time. What makes this case especially striking is how normal it looked. Claude Code was not doing something obviously dangerous. It was being helpful. It noticed missing dependencies and suggested installing the required npm packages. That is the kind of assistance these tools are built for. **And that is exactly the problem.** In agentic systems, helpful behavior can become the entry point. Once malicious content reaches trusted surfaces like memory, hooks, or configuration, the attacker is no longer just influencing one response. They are influencing future reasoning. That is the shift I think the industry still underestimates. We often talk about memory, hooks, and local configuration as convenience features. In practice, they are part of the agent’s trusted operating environment. A memory file is not just stored text. It can influence future decisions. A hook is not just a script. It can shape every interaction. A local configuration file is not just a preference. It can become part of the model’s control plane. Once those surfaces are poisoned, the system may continue treating attacker-controlled content as legitimate guidance. That is why [ MemoryTrap](https://blogs.cisco.com/ai/identifying-and-remediating-a-persistent-memory-compromise-in-claude-code) maps so clearly to **ASI06: Memory & Context Poisoning**. The issue is not just that the model saw something malicious once. The issue is persistence. The corrupted context remains available, continues to circulate, and can shape future planning, tool use, and behavior. From my perspective, that is one of the most important security lessons in agentic AI right now. As these systems become more stateful, memory stops being just a product feature. It becomes a security-relevant state. To Anthropic’s credit, after we at Cisco disclosed the issue, **Claude Code v2.1.50** removed user memories from the system prompt, reducing the specific high-trust override path we identified. That was the right fix for the path we found. But the broader lesson goes well beyond one product. How many other agentic tools still treat memory, summaries, retrieved context, hooks, or local state as implicitly trustworthy? How many systems allow persistent context to shape future behavior without enough validation, separation, or visibility? That is the bigger question MemoryTrap raises. For me, the takeaway is simple: **memory should be treated as part of the attack surface**. If an agent can retain context and reuse it later, that context deserves the same scrutiny we already apply to execution paths, credentials, and other sensitive control surfaces. Otherwise, the line between a helpful workflow and a persistent compromise becomes much shorter than most teams expect. Memory makes agents more useful. It also makes them more exposed.