How Do You Prevent Memory Poisoning Attacks on AI Agents?

Published 28 October 2026 by Gaurav Dadhich. Every paper, advisory and figure below was read at its primary source on 28 October 2026.

You prevent memory poisoning by treating every memory write as untrusted input, recording where each memory came from, and putting the controls that decide what a memory can do (scope, tool permissions, trust tiers and rollback) in code rather than in the prompt. Classifiers and model refusals help, but they miss: in Arize's test published on 26 October 2026, a support agent that refused all 98 direct requests to exfiltrate data still pulled another customer's record on 28 of 100 runs when a web page framed the lookup as routine, and binding the tools to the logged-in session cut the leaks to 0.

Memory turns that kind of one-off injection into a standing one: an injection that lands in long-term memory is retrieved and trusted again next week, in a different conversation, sometimes for a different user or agent. Microsoft's AI Red Team reported in June 2026, after twelve months of engagements against deployed agents, that memory poisoning through cross-domain prompt injection "requires only a single successful injection, which the agent then propagates across subsequent sessions."

What memory poisoning is, and how it differs from prompt injection

Memory poisoning is the corruption of anything an agent stores and later reuses (conversation summaries, extracted facts, preference records, embeddings, RAG stores, memory files) so that its future reasoning, planning or tool use turns biased, unsafe or useful to an attacker. That is close to the wording of ASI06, "Memory & Context Poisoning", in the OWASP Top 10 for Agentic Applications 2026, which explicitly excludes one-time prompts because those belong to LLM01, prompt injection.

The two usually share a seed. What differs is lifetime, timing and trust, and each of those changes the defence:

Microsoft's Learn guidance calls persistent memory "a configuration layer for the AI system", so anything that can write to it can reconfigure the agent.

How poisoned content gets into agent memory

Indirect prompt injection through pages, documents and tool output. Palo Alto Networks' Unit 42 built a proof of concept on Amazon Bedrock Agents (a travel assistant on Nova Premier v1, with Bedrock Guardrails off) in which a malicious web page manipulated the session-summarisation step, so the injected instructions were stored in long-term memory and loaded into later sessions. Unit 42 is explicit that this is not a Bedrock vulnerability (Amazon says the Guardrails prompt-attack policy mitigates it); the general lesson is that the summariser is a writer, and it reads untrusted text.

Ordinary users, through normal queries. MINJA (Dong et al.) showed that an attacker with nothing but chat access can get malicious records into an agent's memory that are later retrieved for a victim's related queries, with no write access to the store. Across three agents (RAP, EHRAgent and a QA agent) on GPT-4 and GPT-4o, the current version of the paper reports an average 98.2% injection success rate (malicious records stored) and 76.8% attack success rate, where an attack succeeds when the agent's response to a later victim query contains the attacker's reasoning steps, tested on 30 victim queries per target (10 for the MMLU-based QA agent).

Other agents. OWASP lists cross-agent propagation as an ASI06 example, and a NeurIPS 2026 paper, Reward Hacking as a Transmissible Strategy in Multi-Agent Coding Systems (Hu et al.), found that reward hacks spread between coding agents through "code, shared memory, and natural-language plans."

A poisoned knowledge base. AgentPoison (Chen et al., NeurIPS 2024) poisoned under 0.1% of the memory or knowledge base of a driving agent (Agent-Driver), a knowledge QA agent (ReAct on StrategyQA) and a health-records agent (EHRAgent), on GPT-3.5 and LLaMA3 backbones with two retriever types. Averaged over those settings, every retrieved demonstration was a poisoned one in 81.2% of test cases, the agent output the attacker's target action in 59.4%, and the attack reached its real-world outcome (for the driving agent, a trajectory deviation past a set threshold) in 62.6%, while benign accuracy fell by 0.74%. PoisonedRAG reports a 90% attack success rate from injecting five texts per target question into knowledge bases of 2.7 to 8.8 million texts (NQ, HotpotQA, MS-MARCO), where success means the answer to one of 100 target questions contains the attacker's chosen answer (substring match, which the authors checked against their own human evaluation), across eight LLMs with PaLM 2 as the default.

The agent's own outputs. OWASP's sixth ASI06 mitigation is to "prevent automatic re-ingestion of an agent's own generated outputs into trusted memory," which it calls bootstrap poisoning. MemoryGraft (Srivastava and He, December 2025) planted fabricated "successful experiences" that a MetaGPT DataInterpreter agent on GPT-4o later retrieved and imitated.

A summary carried between sessions or a MEMORY.md file counts as memory here too.

Memory poisoning in shipped products and recent studies

Bad Memory separates two things most write-ups merge. Testing Claude Code and Codex with Claude Haiku 4.5, Claude Opus 4.7, GPT-5.2 and GPT-5.5, the authors found it hard to make an agent overwrite its own memory files from untrusted external content, but payloads already sitting in a memory file did compromise current and later sessions, with success varying widely by model and goal. Persistence, measured directly as whether the planted payload is still in the memory files at the end of a sequence, is the sharpest result: Opus 4.7 refused credential exfiltration in every probe, yet the planted rule was still there at the end of 100% of those sequences, across ten trials.

One correction for anyone reading other guides: the Agent Security Bench headline figure they quote is an average across all of that benchmark's attacks, not a memory poisoning result.

What OWASP and MITRE say about memory poisoning

OWASP released the Top 10 for Agentic Applications on 9 December 2025. ASI06 builds on three entries of the 2025 LLM Top 10 (LLM01 Prompt Injection, LLM04 Data and Model Poisoning, LLM08 Vector and Embedding Weaknesses). Its nine mitigations are baseline encryption and least privilege, content validation of every write, memory segmentation, authenticated sources with minimal retention, provenance with anomaly detection, no re-ingestion of the agent's own outputs, adversarial testing with snapshots and rollback, expiry of unverified memory, and retrieval weighted by trust and tenancy. On the MITRE side, Microsoft's attack catalog maps the attack to ATLAS AML.T0080, AI Agent Context Poisoning, with sub-techniques for memory and thread.

Which defences still hold when the model is fooled

Sort every control by whether it still works after the model is fooled. Classifiers, judges and refusals are probabilistic; scope bindings, permission checks, provenance records and rollback are deterministic. Build the deterministic ones first, because the evidence on the probabilistic ones is uneven.

MINJA's authors tested detection on their own attack. A targeted detection prompt flagged 131 of 135 malicious records on EHRAgent and 0 of 135 on RAP, while a general prompt caught only some records on two agents and raised 34 false positives out of 50 benign records on the third. The MPBench study (Dash et al., June 2026) concluded that existing prompt injection defences do not cover memory poisoning. Refusals are no better as a boundary, which is what both the Arize numbers and Opus 4.7's persisting rule show: a refusal is something the model did on one run.

Microsoft's June 2026 post on guarding AI memory says it plainly: "Prompting alone is not a reliable security boundary." Keep the classifier, but never as the only thing between a web page and a tool call.

Defences against memory poisoning, from write path to rollback

1. Validate the write path

Every write passes a policy before commit that checks the writer, the source, the memory type, and whether the content carries instructions, secrets or new external contacts. Prefer typed, schema-bound memory (a preference, an identifier, a dated fact) over free text, because an imperative such as "always use this vendor" has no valid slot to land in. Block credentials and payment data outright, and require user intent before writing anything derived from an untrusted source. Forcepoint X-Labs scores candidate memories on source, behaviour-shaping phrasing, unknown contacts and conflict with existing memory, which is a reasonable starting rule set. Microsoft 365 Copilot runs prompt-injection classifiers on memory writes and is designed to run a task-adherence check on every explicit one.

2. Record provenance on every memory

Store source, writer identity, session, timestamp, model version and what the entry was derived from. Provenance is not a defence on its own, but without it the only response to a found poison is wiping the store.

3. Enforce scope and tenant isolation in code

Bind memory reads, memory writes and every sensitive tool to the authenticated user, tenant and agent at the data layer, with no parameter the model can change. OWASP's cross-tenant vector bleed scenario is a loose namespace filter; Arize's fix was a session-scoped tool (a LangGraph agent on deepseek-flash, one run per page at temperature 0.7, leaks counted by a check over the trace). Isolation does not stop a user's own memory being poisoned, but it caps the blast radius at that user.

4. Assign trust tiers

Keep system policy in a read-only tier that agents cannot write, keep user preferences separate from content derived from fetched pages, and require explicit review for changes to high-impact files such as CLAUDE.md and AGENTS.md, as the Bad Memory authors recommend. OWASP suggests requiring two factors (a provenance score plus a human-verified tag) before a high-impact memory can surface at all.

5. Quarantine and review instead of commit

When a candidate memory conflicts with an existing one, introduces a new vendor, domain or payee, or touches a protected category, hold it for confirmation. Forcepoint's example is a new "official travel provider" that contradicts the corporate one and should never replace it automatically.

6. Expire unverified memory

OWASP's eighth mitigation is direct: "Expire unverified memory to limit poison persistence." A time-to-live or decay on low-trust entries bounds how long a successful injection keeps working, while verified facts and policies stay exempt.

7. Filter at read time

Treat retrieved memory as candidate context, because what was safe to write can be unsafe to use later: re-check it for injected instructions, rank by trust as well as relevance, and never let a retrieved memory override system instructions or widen tool permissions. Microsoft applies Prompt Shields to memory at retrieval, before it enters the agent's context.

8. Audit everything and keep rollback

Log every create, read, update and delete with identity, source and provenance; keep versions so you can see when an entry changed and restore a known-good state. Microsoft 365 Copilot records memory updates in the organisation's audit log.

Shared memory in multi-agent systems needs write rules

One shared memory across agents is also a transmission channel. Hu et al. found that self-review and verifier gating "reduce but do not eliminate delivered hacks", which argues for gating at the memory boundary too: agents write into their own scope by default, promotion into shared scope goes through a checker, and every shared entry names the agent that wrote it. Treat a peer agent's write with the same suspicion as a web page.

How to test an agent for memory poisoning

Run these in CI and before every model, prompt or tool change.

Score write, persistence and action separately, because Opus 4.7 refused the action and kept the rule. Grade with deterministic checks over traces wherever you can write the rule down. Arize's span check (did a customer tool run for an id other than the session's) counted all 28 leaks, while an LLM judge that read only the final answer caught 5. Our one-week test plan covers the non-adversarial side.

Detecting memory poisoning in production and cleaning it up

Poisoning shows up as gradual drift, so monitor the mix of memory sources retrieved, the rate of low-trust writes and memory-driven tool calls against a baseline, and run the deterministic checks online. When you find an entry, trace everything derived from it through provenance, quarantine it instead of deleting it, review the decisions made while it was live, and re-check the rest of the store for the same source.

Tools you can use, and what they cost

OWASP Agent Memory Guard is an open-source Incubator project that sits between an agent and its memory store and screens operations against a declarative policy. Azure AI Content Safety Prompt Shields and the Bedrock Guardrails prompt-attack policy detect injected instructions in content. Microsoft lists the costs: retrieval latency from runtime checks, and logging volume weighed against data minimisation.

What to ask a memory vendor about memory poisoning

Ask whether isolation is enforced in the storage layer or by a filter the caller passes, whether every memory carries its source and writer, whether an update keeps the previous version, which data is never stored regardless of settings, whether writes can be held for review, and whether memory changes reach your audit log. Our guide to choosing an agent memory layer has the wider checklist, and what a vector database does and does not give you covers filtering and tenancy at the store.

Where Maximem Synap fits

Maximem Synap takes care of several of these controls at the memory layer. Every memory can be traced (where it came from, what it replaced, why it changed and what it used to say), and an update is recorded rather than overwritten, so a bad entry can be followed back to its source. Memory is isolated by default across your account, your tenant, the individual person and the conversation, and a read sees the levels above it, never below and never sideways. Payment card details, security codes, PINs, passwords, API keys, private keys and raw biometric data are never stored for any customer, with no setting to turn that off. Ambiguous identity matches go to a review queue instead of being guessed, and each agent's memory architecture is approved by a person, versioned and can be rolled back. Two things stay with you whichever layer you use: deciding which sources may write at all, and keeping tool permissions in your own code. The security page has the rest.

Frequently asked questions

Is memory poisoning the same as prompt injection?

No. Prompt injection is usually the delivery method, and memory poisoning is what happens when the injected content is saved and reused in later sessions. OWASP files them separately, as LLM01 and ASI06.

Can a prompt injection classifier stop memory poisoning?

Not on its own: in MINJA's own tests, a detection prompt that caught 131 of 135 poisoned records on one agent caught 0 of 135 on another. Use classifiers on writes and reads, and put scope, permissions and rollback in code.

Do coding agents like Claude Code have this problem?

They do, through memory and instruction files loaded at the start of a session. Cisco's April 2026 report led to a change in Claude Code v2.1.50, and the Bad Memory study measured planted memory-file payloads against Claude Code and Codex. Our review of 2026 Claude Code skills covers the related marketplace risk.

Is memory poisoning a compliance issue?

It can be. Microsoft's guidance is to protect memory like customer data and govern it like a system that can act, so a poisoned memory that leaks personal data is a data incident.

Sources

All retrieved on 28 October 2026.

• OWASP Top 10 for Agentic Applications 2026, ASI06
• OWASP Agent Memory Guard
• Microsoft Security blog, Guarding AI memory, 22 June 2026 and taxonomy of failure modes v2, 4 June 2026
• Microsoft Learn: Manage memory safety in agentic systems, AI memory and context poisoning, Input, context and retrieval hygiene
• Arize, A web page talked our agent into leaking a stranger's data, 26 October 2026
• Unit 42, indirect prompt injection poisons AI long-term memory, 9 October 2025
• Rehberger, SpAIware, 20 September 2024
• Cisco, persistent memory compromise in Claude Code, 1 April 2026
• Forcepoint X-Labs, persistent memory poisoning in AI agents
• Papers: AgentPoison, arXiv 2407.12784; MINJA, arXiv 2503.03704 v5; MemoryGraft, arXiv 2512.16962; Bad Memory, arXiv 2607.14611; MPBench, arXiv 2606.04329; Agent Security Bench, arXiv 2410.02644; PoisonedRAG, arXiv 2402.07867; Reward Hacking as a Transmissible Strategy, NeurIPS 2026