Agent Memory Poisoning vs RAG Poisoning: Reach, Persistence and Clean-Up

Agent memory poisoning and RAG poisoning both plant content that an AI system later trusts, but they differ in who writes the bad entry, how many users it reaches and how hard it is to remove, and teams that treat them as one problem end up with the wrong controls. Memory poisoning corrupts what an agent remembers about a user, a project or itself, usually through the agent's own writes. RAG poisoning corrupts a shared knowledge corpus through the ingestion pipeline, so one document can reach every user whose question retrieves it. This guide compares the two on threat model, reach, persistence, detection and clean-up, and gives a decision framework for where to put controls. It is for AI platform owners, AppSec and detection teams who run agents with persistent memory, retrieval or both. The mechanics of each attack are covered in the AI Agent Memory Poisoning Guide and AML.T0070 RAG Poisoning; this page is about telling them apart and defending each correctly.

Key takeaways

• Short answer: the writer and the reach differ. In memory poisoning the agent (or its summariser) writes the entry, usually for one user or project; in RAG poisoning an ingestion pipeline writes it into a corpus that many users query.
• Memory carries more authority, RAG carries more reach. Memories are loaded as facts about the user or as standing instructions; retrieved chunks are loaded as reference material, but for everyone whose query matches.
• Controls sit at different gates. Memory needs write-time gating inside the agent (AML.M0031 Memory Hardening); RAG needs source vetting and provenance at ingestion (AML.M0025 Maintain AI Dataset Provenance) and permission-aware retrieval.
• Detection looks in different logs. Memory poisoning shows up as unusual memory writes and diffs per principal; RAG poisoning shows up in retrieval logs as one chunk appearing across many unrelated sessions.
• Clean-up must chase derivatives. A poisoned document can be laundered into agent memories, summaries and caches, so deleting the source rarely ends the incident.

Definitions and where each sits

Agent memory poisoning

Agent memory is state an agent keeps between sessions: saved preferences, facts about the user, session summaries, project instruction files and, in multi-agent systems, shared scratchpads. MITRE ATLAS models the attack as AML.T0080 AI Agent Context Poisoning, with the sub-technique AML.T0080.000 Memory describing manipulation of memory to persist changes into future chat sessions, noting that because memory is controlled through normal conversation, an adversary can inject memories via direct or indirect prompt injection. The MINJA research (Dong et al., arXiv 2503.03704) showed that an attacker can plant malicious memory records purely through normal queries, without direct access to the memory store, designed to be retrieved when a different user later asks a related question.

Platforms implement memory in ways that change who controls the store (listed alphabetically):

• Amazon Bedrock AgentCore Memory: short-term memory captures turn-by-turn interactions within a session; long-term memory automatically extracts and stores insights such as preferences, facts and session summaries across sessions. Automatic extraction means the write decision sits in the platform's extraction step.
• Anthropic memory tool: operates client-side; the model requests file operations (view, create, str_replace, insert, delete, rename) under a /memories path and your application maps that path onto real storage and runs the commands. The application is responsible for path validation, stripping sensitive data, size caps and expiry.

RAG poisoning

Retrieval augmented generation indexes documents into a vector or hybrid search store and injects the top-ranked chunks into the prompt at query time. ATLAS defines AML.T0070 RAG Poisoning as injecting malicious content into data indexed by a RAG system to contaminate a future thread, noting the content may be targeted to surface for a specific query and may carry false information, prompt injections or false RAG entries (AML.T0071). OWASP LLM08:2025 Vector and Embedding Weaknesses lists data poisoning from insiders, prompts, data seeding or unverified data providers. The PoisonedRAG research (Zou et al., arXiv 2402.07867) reported about a 90% attack success rate with five malicious texts per target question in a knowledge database of millions of texts, and found the defences it tested insufficient.

Side-by-side comparison

Threat models

Self-written malicious memories

The distinctive feature of memory poisoning is that the victim system does the writing. An agent reads a web page, an email or a tool result containing indirect prompt injection (AML.T0051.001), and the injected text asks it to remember something: that a domain is trusted, that the user prefers files sent to an address, or that a check can be skipped. The write looks like normal behaviour, because remembering is the feature. The poisoned entry then returns in later sessions with the authority of the user's own preferences. Variants include:

• Personal memory: reach is one user, but persistence is indefinite and the user may never look.
• Project instruction files: files in a repository that coding agents load automatically. Anyone who can commit can write them, which turns code review into memory review.
• Team or multi-agent memory: shared scratchpads or stores read by several agents. Reach approaches RAG scale while authority stays at memory level, the worst combination.
• Session summaries: a summariser compresses a poisoned conversation into a clean-looking summary, losing the evidence of where the instruction came from.

Poisoned documents in the corpus

RAG poisoning needs no interaction with the agent at all. The attacker writes content into any source the pipeline indexes and crafts it to rank for chosen queries (AML.T0066 Retrieval Content Crafting). The ingestion path decides who can attack: inbound email and public forms are open to anyone on the internet, shared drives to employees and guests, curated policy libraries only to named owners. In the EchoLeak 2025 case a crafted email sent to a user was later retrieved as context for that user's ordinary questions. In SalesBleed 2026, a record submitted through a public web-to-lead form sat in the CRM and became dangerous only when an agent retrieved it for an employee. Both show the pattern: stored data, no login, no click, triggered on retrieval.

Where they meet

The two attacks chain. A poisoned document retrieved once can instruct the agent to save a memory, converting a query-dependent RAG entry into an always-loaded memory for that user. The reverse also happens when agents write memories or summaries back into a shared index. Treat any pipeline where agent output becomes indexed input as both a memory store and a corpus, and apply both sets of controls. See Agentic RAG vs Classic RAG for architectures where the agent decides what to retrieve and store.

Reach, persistence and authority compared

Controls for each

Memory: gate the write

• Write policy: ATLAS AML.M0031 describes restricting an agent's ability to store memories by requiring external authentication and validation for memory updates, semantic integrity checks on retrieved memories before actions, and monitoring and remediation processes for poisoned memory.
• No writes after untrusted input: block or require confirmation for memory writes in any turn that processed external content (AML.M0030 Restrict AI Agent Tool Invocation on Untrusted Data applies directly when memory is a tool).
• Typed memory: store preferences and facts in structured fields; reject free-text entries that contain imperative instructions, URLs, email addresses or tool names unless the user confirmed them.
• Provenance per entry: record writer (agent, summariser, user), source session, source content reference and timestamp. Our recommendation: sign each entry with a key held by the memory service, so entries written outside the service fail verification.
• Visibility and expiry: let users see and delete memories; expire entries that have not been used, as the Anthropic memory tool documentation advises for its files.
• Repository files as code: require code-owner review on agent instruction files and block agents from editing them without approval.

RAG: gate the source and the retrieval

• Ingestion vetting: OWASP LLM08 recommends data validation pipelines, auditing the knowledge base for hidden codes and poisoning, and accepting data only from trusted and verified sources. Extract text in a way that exposes hidden content (white text, tiny fonts, metadata) before indexing.
• Source trust tiers: tag every chunk with origin and trust tier at ingestion; sensitive workflows retrieve only from high-trust tiers. Open-writer sources (email, forms, public channels) never feed the same index as policy content without a tier filter.
• Signing and integrity: hash or sign approved documents at publication and verify at ingestion and periodically in the index, so silent edits in the source or the vector store are detected (NIST SP 800-53 SI-7).
• Permission-aware retrieval: filter chunks by the caller's entitlements, which also limits whose answers a poisoned chunk can reach. See the Permission-Aware RAG Guide.
• Retrieval filters: strip instruction-like text from retrieved chunks or mark it as data, and cap how many chunks from a single low-trust source can enter one answer.

Decision guidance

Use these questions to decide which threat dominates a system and where to spend first:

1. Does the agent write anything that a later session reads? If yes, memory poisoning is in scope regardless of what the product calls the feature.
2. Who can write to each indexed source? If anyone outside the organisation can (email, forms, public channels, web crawl), RAG poisoning is your highest-reach risk.
3. Is any store shared across users or agents? Shared memory needs RAG-grade ingestion controls and memory-grade write gating.
4. Can the agent act after reading? Either attack only becomes an incident when the agent has tools that send, write or pay. Constrain those first if you can only do one thing.
5. Can you answer "which sessions loaded entry X"? If not, fix logging before tuning detection, because clean-up depends on it.

Small organisations using a hosted assistant should turn off or restrict persistent memory for accounts that process external content, keep retrieval scoped to curated sources and rely on the platform's memory viewer for review. Large organisations should run memory as a service with its own write API, provenance and signing, and treat each RAG source as a data product with an owner, trust tier and ingestion controls. See the AI Agent Memory Security Guide and the RAG Security Guide.

How to implement: a phased approach

1. Map stores: list every memory store, summary store, instruction file convention and index, with writers, readers, scope and retention. Threat Modelling RAG Systems gives a method.
2. Add provenance: ensure every memory entry and chunk records writer, source and timestamp; backfill where possible and mark the rest as unknown provenance.
3. Log reads: record which entries and chunk IDs were loaded into each session, with user and agent identity.
4. Gate in audit mode: run memory write policy and ingestion vetting in log-only mode for two to four weeks; review what would have been blocked.
5. Enforce: block instruction-like memory writes after untrusted input, apply trust tiers to retrieval, and require approval for shared memory writes. Keep a switch to return each control to log-only.
6. Snapshot: version memory and index state so you can roll back to a known-good point without wiping everything.
7. Test: plant benign canary entries in each store and confirm detection, tracing and purge work end to end. The RAG Security Test Plan Template helps for the corpus side.

Detection and measurement

For memory, alert on writes containing URLs, addresses, tool names or imperative phrasing; writes in turns that followed external content; bursts of writes; and edits to repository instruction files by agents. For RAG, alert when a newly ingested chunk is retrieved across many unrelated users within hours, when low-trust chunks appear in answers to sensitive queries, when hidden-text extraction flags a document, and when retrieved content precedes an unusual tool call. OWASP LLM08 recommends detailed immutable logs of retrieval activity.

Purge procedures

Clean-up differs because the unit of contamination differs. Preserve evidence first: export the entry or chunk, its provenance, read logs and the snapshot before deleting.

The AI Agent Memory Poisoning Response Playbook gives roles and decision points for the memory side.

Common failure patterns

• Deleting the document and closing the ticket: the poisoned chunk was retrieved last week and saved into three users' memories, which still load every session.
• One index for everything: inbound email, public form submissions and HR policy share an index with no trust tier, so the most open writer competes with the most trusted source.
• Memory as an invisible feature: agents write memory with no log, no viewer and no expiry, so nobody can say what they remember or why.
• Treating repository instruction files as documentation: they are standing instructions for every coding agent and need code-owner review.
• No read logs: without chunk IDs and memory entry IDs per session, scoping an incident means guessing.
• Agent output fed back into the corpus: summaries and generated documents re-indexed without vetting turn one successful injection into a durable corpus entry.

Framework mapping

Worked scenario

Setting. A support organisation runs an assistant that answers agents' questions from an index of the knowledge base and closed tickets, and keeps per-agent memory of preferences. Customers can open tickets by email.

What happens. A customer email, later closed as a ticket and indexed, contains hidden text crafted to rank for refund questions. It tells the assistant that refunds over a threshold should be confirmed by sending account details to an external address, and that the user prefers this. Over a week the chunk is retrieved in 40 sessions; in six of them the assistant also saves "user prefers external refund confirmation" to memory.

Why the distinction matters. The security team finds the chunk through retrieval logs and deletes the ticket from the index, which stops new retrievals. Memory poisoning remains for six support agents and loads every session regardless of query. Because each memory entry carries provenance pointing to the poisoned session, the team finds all six, deletes them, reviews outbound messages from those sessions and moves closed tickets into a low-trust tier that the refund workflow no longer retrieves. Memory writes after retrieval from low-trust tiers now require the user's confirmation.

Practitioner checklist

• Inventory every memory store, summary store, instruction file and index with writers, readers and scope.
• Record writer, source and timestamp on every memory entry and every chunk.
• Log which entries and chunk IDs each session loaded, with user and agent identity.
• Block or confirm memory writes in turns that processed external content.
• Assign a trust tier to every indexed source and filter sensitive workflows to high-trust tiers.
• Extract hidden text and sign or hash approved documents before indexing.
• Put agent instruction files under code-owner review.
• Snapshot memory and index state, and test purge with canary entries quarterly.
• Include derivative memories, summaries and caches in every purge.

Standards and references

• MITRE ATLAS: AI Agent Context Poisoning
• MITRE ATLAS: RAG Poisoning
• OWASP: Top 10 for LLM Applications 2025
• OWASP: Top 10 for Agentic Applications for 2026
• arXiv: PoisonedRAG, Knowledge Corruption Attacks to Retrieval-Augmented Generation of Large Language Models
• arXiv: Memory Injection Attacks on LLM Agents via Query-Only Interaction
• Amazon Web Services: Amazon Bedrock AgentCore Memory
• Anthropic: Memory tool

Related NHI Mgmt Group resources: MITRE ATLAS AML.T0080 AI Agent Context Poisoning · OWASP LLM Top 10 LLM08 Vector and Embedding Weaknesses Guide · Prompt Injection Guide · AI Data Poisoning and Backdoors Guide