An attacker compromised Claude Code's memory system. No credentials were stolen. No malware was deployed. Instead, the attack poisoned the AI's stored context, the preferences, workflows, and learned behaviors it uses across sessions. When legitimate users returned, the AI served them instructions from the attacker's earlier interaction. The compromise spread silently from session to session, user to user.
This is MemoryTrap, a disclosed and now-remediated vulnerability that shows how AI memory creates a new category of persistent attack surface. Your secrets management and identity controls won't catch this. The attack targets something most security teams haven't classified as an asset yet: the contextual data your AI agents store between sessions.
What Happened
MemoryTrap exploited how Claude Code maintains continuity. The system stores preferences, earlier context, summaries, workflow patterns, and learned behavior for future sessions. An attacker injected malicious instructions into this memory layer during their own session. When other users interacted with the same AI instance later, it treated the poisoned memory as trusted context and acted on the attacker's embedded commands.
The vulnerability wasn't in the code or the network. It was in the trust boundary around stored context. The AI couldn't distinguish between legitimate learned behavior and injected instructions because both lived in the same memory space with the same authority.
Timeline
Initial compromise: An attacker injects malicious instructions during a normal interaction with Claude Code. The AI stores these as part of its learned context.
Persistence established: The poisoned memory persists across the attacker's session end. It's now part of the AI's "knowledge" about how to behave.
Cross-user propagation: A legitimate user starts a new session. The AI loads its stored memory, including the attacker's injected instructions, and treats them as authoritative context.
Continued spread: Each subsequent session potentially reinforces or spreads the compromised memory, creating a widening trust contamination.
Disclosure and remediation: Cisco AI Security Researcher Idan Habler disclosed the vulnerability. Anthropic patched the memory isolation controls.
Which Controls Failed
Memory isolation: There was no separation between user-specific context and system-wide learned behavior. An attacker's session data could influence other users' sessions.
Input validation on stored context: The system didn't treat memory objects as potentially hostile input when loading them for new sessions. It assumed stored context was inherently trustworthy.
Trust boundary enforcement: There was no mechanism to track the provenance of memory objects. The AI couldn't answer "where did this instruction come from?" or "who created this preference?"
Session isolation: Inadequate controls prevented one user's interactions from affecting another user's experience through the shared memory layer.
Anomaly detection: No monitoring flagged when stored context began producing unusual outputs or behaviors that diverged from expected patterns.
What Standards Require
NIST 800-53 Rev 5, AC-3 (Access Enforcement): Requires systems to enforce approved authorizations for logical access. AI memory that allows one user's context to influence another user's session violates this control. You need isolation between user sessions at the memory layer, not just at the authentication layer.
ISO/IEC 27001:2022, A.8.2 (Information Classification): Mandates that information be classified and handled according to its sensitivity. Your AI's stored context is information. It needs classification (user-specific vs. system-wide, trusted vs. untrusted source) and handling procedures that match.
OWASP ASVS v4.0.3, V4.1.1: Requires that access control rules be enforced on a trusted service layer. Your AI's memory system is a service layer. When it loads context, it's making an access control decision about what data to trust and apply. That decision needs enforcement rules.
SOC 2 Type II, CC6.1 (Logical and Physical Access Controls): Requires restricting logical access through authentication and authorization. Memory objects that persist across sessions are a form of logical access, they grant authority to influence future behavior. They need the same access controls as API keys or user credentials.
Lessons and Action Items
Classify AI memory as a privileged asset. Add your AI agents' memory systems to your asset inventory. Treat stored context with the same governance rigor you apply to secrets management. This means: access controls, encryption at rest, audit logging, and lifecycle policies.
Implement memory provenance tracking. Every memory object your AI stores should carry metadata: which user created it, when, from which session, and what trust level that session had. When the AI loads memory for a new session, it should evaluate that provenance before applying the context.
Isolate user-specific memory. User A's learned preferences should never influence User B's session. Create separate memory namespaces per user or tenant. If you need shared memory for system-wide learning, implement explicit approval workflows before promoting user-specific context to shared status.
Validate memory objects on load. Don't assume stored context is safe just because it's in your database. Run input validation against memory objects when loading them, the same way you validate external API responses. Check for instruction injection patterns, unexpected command structures, and deviations from your expected memory schema.
Add memory-specific monitoring. Instrument your AI systems to log when they load memory, what actions result from that loaded context, and whether those actions match expected patterns. Alert on anomalies: a memory object that suddenly starts triggering high-privilege operations, or context that produces outputs inconsistent with the user's role.
Test for memory injection. Add this to your security testing: Can you craft input that survives into stored memory? Does that stored input influence future sessions? Can you inject instructions that the AI will execute later? Your penetration tests should include memory poisoning scenarios, not just traditional injection attacks.
Define memory retention policies. How long should your AI remember? Longer memory means longer persistence for any compromise. Set retention limits based on the sensitivity of the operations your AI performs. High-privilege agents need shorter memory windows and more aggressive purging of stale context.
The MemoryTrap case closed with a patch. The broader issue remains open: as your organization deploys more AI agents with persistent memory, you're creating a new attack surface that sits outside your existing control frameworks. Start treating AI memory as infrastructure that needs governance, not as an implementation detail that takes care of itself.
