What if the AI coding assistant you trust to write secure code was silently rewriting itself to serve an attacker? Not through a vulnerability in the model. Not through a phishing email. But through its own memory.

Cisco's AI Security Research team just dropped a disclosure that should terrify anyone using AI-powered coding agents. They found a way to compromise Claude Code's persistent memory — and maintain control across every session, every project, and even after reboots.

Anthropic patched it in v2.1.50. But the attack surface it revealed? That's not going anywhere.

What Is Memory Poisoning?

Modern AI coding agents like Claude Code don't just autocomplete lines. They remember your preferences, project structure, coding style, and past decisions. They store this in special files — typically MEMORY.md — that get loaded directly into the model's system prompt on every interaction.

Here's the problem: these memory files are treated as high-authority instructions. The model assumes they were written by you. It implicitly trusts them.

Memory poisoning is the act of modifying these files to contain attacker-controlled instructions. Once poisoned, the agent delivers manipulated guidance that appears legitimate to the user — because the model itself believes it came from a trusted source.

The Attack Chain: From npm Install to Total Compromise

Cisco's proof-of-concept is elegant in its simplicity:

Step 1: The Entry Point

The attacker publishes a malicious npm package. When you run npm install, a postinstall hook executes arbitrary code on your machine. Nothing new here — supply chain attacks via npm are a known threat. But the payload isn't what you'd expect.

Instead of stealing credentials or installing malware, it quietly locates Claude Code's memory files and injects attacker-controlled instructions.

Step 2: The Poison

The first 200 lines of Claude Code's MEMORY.md files are loaded directly into the system prompt. The attacker crafts instructions that look like legitimate coding preferences but actually:

  • Instruct the agent to introduce hardcoded secrets into production code
  • Systematically weaken security patterns across the codebase
  • Replace secure functions with vulnerable alternatives

From the model's perspective, these are just user preferences. It follows them without question.

Why This Is Worse Than Traditional Supply Chain Attacks

A typical npm supply chain attack is a one-time event. It executes, does its damage, and you might catch it in a security audit. Memory poisoning is persistent and compounding.

Three characteristics make it uniquely dangerous:

1. Cross-Session Persistence

The poison survives reboots. Every time you open Claude Code — on any project — the malicious instructions are loaded back into context. The attacker doesn't need to maintain access. They just need to get in once.

2. Cross-Project and Cross-User Propagation

Memory files exist at both the user level (global preferences) and project level. A poisoned global memory file affects every repository you work on. Worse, if you're collaborating on a project with shared memory, the poison can spread to teammates using the same tools.

Cisco researcher Idan Habler calls this trust laundering: attacker-controlled data blending into legitimate context, making it nearly impossible to trace.

3. Silent and Authoritative

The compromised guidance doesn't look malicious. The model presents it as helpful suggestions based on your preferences. A developer following Claude Code's recommendation to simplify authentication by removing the CSRF token has no reason to suspect the suggestion came from an attacker.

The Attack Surface Nobody's Measuring

Here's what Cisco's research reveals that most security teams haven't considered:

Memory is a control surface, not just a convenience feature. In agentic systems, persistent memory functions like a persistent instruction layer. When it's reused between tasks, sessions, or users, it becomes part of the system's decision context.

The risk isn't memory corruption in the traditional sense. It's that an attacker can alter what the model later recognizes as legitimate context. The model doesn't verify the provenance of its memory. It treats everything in MEMORY.md as user-authored truth.

This turns a single poisoned npm package into a long-term influence operation against every line of code you write.

What Anthropic Fixed (And What They Didn't)

Anthropic responded quickly. Claude Code v2.1.50 removes the capability for memory files to influence the system prompt directly. That's the right fix for this specific vector.

But the underlying architecture problem remains: AI agents trust their memory implicitly, and memory files are writable by any process running with user permissions. If you install a malicious package, it can modify:

  • Global memory files in your home directory
  • Project-level memory files in any repo
  • Configuration files that affect agent behavior
  • Shell profiles that inject environment variables

The attack surface isn't just the AI's memory system. It's the entire trust boundary between things the user wrote and things some npm package wrote on behalf of the user.

What Organizations Should Do Now

Cisco's recommendations are straightforward but require organizational change:

Treat AI memory like secrets and identities. Memory files should have the same governance, access controls, and audit trails as your API keys and service accounts.

Isolate agent memory per project. Don't let global preferences bleed across repositories. A memory file from an open-source project should never influence your internal production codebase.

Verify memory provenance. Before an agent acts on learned preferences, it should be able to answer: where did this instruction come from, when was it added, and has it been modified by a process other than the user?

Scan dependencies for memory manipulation. Security tools need to detect packages that attempt to write to AI agent memory locations — not just traditional malware indicators.

The Bigger Picture

This disclosure lands in a crowded month for AI security. IBM just announced Autonomous Security — a multi-agent defense system. OpenAI shipped sandboxing for its Agents SDK. Okta rolled out new AI access controls. The industry is waking up to the fact that AI agents aren't just tools anymore. They're active participants in your infrastructure with persistent state, network access, and the ability to execute code.

Memory poisoning is the natural evolution of supply chain attacks. Instead of compromising your code directly, attackers compromise the entity that writes your code. The AI becomes the persistent backdoor, and every line it generates is suspect.

If you're using Claude Code, Cursor, GitHub Copilot, or any AI coding assistant with persistent memory, audit those memory files today. Check what's in them. Verify nothing was added by a package you installed last week. Because if Cisco could do it for research, attackers are already doing it for profit.

Sources: Cisco AI Security Research (blogs.cisco.com), Help Net Security interview with Idan Habler, Anthropic Security Disclosure