Memory And Context Poisoning In AI Agents: How It Works And How To Defend.

Memory and context poisoning is an attack where someone plants false or malicious data in what an AI agent remembers or retrieves, so the agent behaves badly later, after the attacker has gone. OWASP lists it as ASI06 in its Top 10 for Agentic Applications 2026. It defines context as "any information an agent retains, retrieves, or reuses, such as summaries, embeddings, and RAG stores".

The key difference from ordinary prompt injection is persistence. OWASP says ASI06 excludes one-time input prompts and focuses on "persistent corruption of agent memory and retrievable context that propagates across sessions". Adversaries "corrupt or seed this context with malicious or misleading data, causing future reasoning, planning, or tool use to become biased, unsafe, or aid exfiltration". OWASP also notes that memory poisoning frequently leads to goal hijacking.

Anything that feeds the agent's memory is a possible way in. OWASP names uploads, API feeds, user input and peer-agent exchanges, which "may be untrusted or only partially validated". An AI agent that writes its own notes makes the problem worse, because it can store a poisoned instruction as if it were its own knowledge.

There are three common routes, and the sources name them separately. In the ATLAS data, context poisoning and its memory sub-technique are tagged "Realized", while RAG poisoning and false RAG entry injection are tagged "Demonstrated". Plan for all of them.

• Agent memory. MITRE ATLAS (data release v2026.09) lists AML.T0080 AI Agent Context Poisoning, with the sub-technique AML.T0080.000 Memory: changes that "persist across future chat sessions". Because memory is controlled through normal conversation, an attacker can add memories through direct or indirect prompt injection. There is also AML.T0080.001 Thread, where bad instructions last for the rest of a chat thread.
• RAG and vector stores. AML.T0070 RAG Poisoning means injecting malicious content into data a retrieval augmented generation system indexes, to contaminate a future thread. AML.T0071 False RAG Entry Injection hides a fake document inside a normal entry, which "bypasses data monitoring tools" and "prevents the document from being deleted directly". OWASP LLM08:2025, Vector and Embedding Weaknesses, adds cross-context leaks in multi-tenant vector databases and notes poisoning can be intentional or accidental.
• Connected data. AML.T0099 AI Agent Tool Data Poisoning covers poisoned data in repositories, knowledge bases and search indexes that an agent tool queries.

OWASP also lists slower forms. Long-term memory drift gradually shifts stored knowledge. Cross-agent propagation spreads contaminated context between cooperating agents. Example (illustrative). At acme.com, a support agent keeps a shared memory of refund rules. An attacker's message reinforces a fake rule until the agent stores it. Other agents reuse it, and refunds start going out against policy.

Poisoned entries look like ordinary data, and the damage shows up later. ATLAS notes that a false RAG document inside a regular entry gets past data monitoring. OWASP describes an attacker splitting attempts across sessions so earlier rejections drop out of the context, and "bootstrap poisoning", where an agent re-ingests its own outputs into trusted memory and reinforces the error. Because the corrupted state lives in a store, not in a single prompt, filtering prompts alone does not help. You have to control what gets written, what gets retrieved and who can change either.

There is also a trust problem on the retrieval side. An agent that finds a confident, well-formatted entry tends to use it. That is why OWASP asks for provenance scores and human-verified tags before high-impact memory is surfaced, and why it recommends detecting suspicious updates by their content and by how often they happen.

OWASP gives nine mitigations for ASI06, and its threats guide has a full playbook for memory. Together they come down to a few habits.

1. Validate before you write. "Scan all new memory writes and model outputs (rules + AI) for malicious or sensitive content before commit."
2. Segment memory. Isolate user sessions and domain contexts. For shared vector stores, use per-tenant namespaces and permission-aware storage, as LLM08:2025 advises.
3. Trust only curated sources. Allow authenticated, curated sources, and require source attribution so every entry can be traced. OWASP also asks teams to track data origins and transformations (LLM04:2025).
4. Weight retrieval by trust. Require two factors to surface high-impact memory, for example a provenance score plus a human-verified tag, and let low-trust entries decay.
5. Keep retention short. Minimize retention by data sensitivity, and expire unverified memory so poison does not persist.
6. Do not self-feed. Prevent automatic re-ingestion of an agent's own outputs into trusted memory.
7. Be able to roll back. Keep snapshots and version control, and log memory access and changes so you can restore a validated state. See monitoring and logging for AI agents.

CISA, the NSA, the FBI and partners make the same point for AI data in general. Their 2025 information sheet stresses data security for "the accuracy, integrity, and trustworthiness of AI outcomes" and recommends robust data protection and stronger monitoring and threat detection. Keep agent permissions small too: a poisoned memory can only trigger what the agent is allowed to do, so least privilege limits the blast radius. The mapping to other agent risks is in top threats to AI agents.

Start with an inventory, then close the write path.

Then connect the controls to people and policy. Put a human approval in front of high-impact actions using the human in the loop and least agency checklist, and record memory rules in the AI agent governance policy template.