AI Agent Memory Poisoning Response Playbook

Once a poisoned entry sits in an AI agent's long-term memory, every session that recalls it can act on the attacker's instructions, so deleting the entry is the last step of the response, not the first. Responders need to know which sessions, users and downstream agents recalled the entry, what it caused, whether it spread into summaries, embeddings or shared stores, and which clean state to return to. This playbook covers those questions for teams that run agents with persistent memory, from detection through quarantine, rollback, evidence and notification. Prevention lives in the AI Agent Memory Poisoning Guide and the wider agent response procedure in the AI Agent Incident Response Playbook; this page goes deeper on the memory-specific steps those pages summarise. Time targets and thresholds on this page are NHI Mgmt Group recommendations.

Key takeaways

Scope by recall, not by write. The write tells you how the entry arrived; the recall log tells you who was affected. Without retrieval traces that record entry IDs, you cannot scope the incident.
Quarantine before you delete. A quarantined entry stops being recalled but stays available as evidence and for comparison with snapshots. Delete only once scoping is complete.
Poison spreads into derivatives. Summaries, consolidated profiles, re-embedded chunks and other agents' stores can carry the instruction after the original entry is gone.
Pick the rollback point from evidence. Roll back to the last snapshot taken before the first poisoned write, then replay legitimate writes made since, rather than restoring yesterday's copy by habit.
Memory content can be personal data. Altered or exposed memories about users can trigger data breach assessment under data protection law, and actions the agent took on the poisoned memory may have their own notification duties.

How memory poisoning shows up

MITRE ATLAS describes the technique as AML.T0080.000 AI Agent Context Poisoning: Memory, in which an adversary manipulates an LLM's memory so that changes persist into future sessions, using direct or indirect prompt injection. Reports rarely arrive with that label. The usual first signals are below.

Signal	Typical source	First question to ask
Agent repeats an odd preference, trusted source or rule across unrelated sessions	User report, quality review	Is the behaviour coming from a stored entry or from the model or prompt?
Memory write originating from retrieved content (email, web page, document, tool output) rather than the user	Memory write log with provenance	What content triggered the write, and who else received that content?
Links to AI assistants with pre-filled prompts containing words such as "remember" or "trusted source"	Email, chat and proxy logs	Who clicked, and which assistants accept memory writes from a link?
Unexpected tool calls or egress following a recall	Agent traces, egress logs	Did the recalled entry precede the action in the same session?
Canary or honeytoken memory entry altered or recalled	Canary monitoring	Which write path reached the canary?
Memory store change outside the agent's own write API	Database or vector store audit log	Is this an application-layer poisoning or direct access to the store with stolen credentials?

Microsoft's research on AI Recommendation Poisoning, published in February 2026, found pre-filled "summarise with AI" prompts that told assistants to remember a company as a trusted source, and gave hunting logic for links to assistant domains whose prompt parameters contain memory keywords. That hunting logic carries over to any proxy or email log. See the AI Agent Honeytokens and Canaries guide for canary memory entries.

Triage: five questions in the first hour

Which store? Per-user memory, per-tenant memory, a shared organisational store, or a store read by several agents. Shared stores move the incident up a severity level.
How did it get in? Through the agent's own write tool after reading untrusted content, through a user, through an integration that writes directly, or through access to the database itself. The last case is a credential incident first: follow the AI Agent Incident Response Playbook for the credential and treat memory as one affected system.
What does the entry instruct? Exfiltration, a biased recommendation, a changed approval rule or a tool call. Instructions that cause actions are more urgent than ones that colour answers.
Is the write path still open? If the same content can write again, deletion will not hold.
Do you have recall traces? If retrieval logs do not record entry IDs, plan for a wider rollback and say so early.

Our severity guide: an entry in one user's memory that colours answers is low; an entry that triggered tool calls, or any entry in a shared or multi-agent store, is high; an entry that triggered data egress or financial actions is critical.

Scoping: who recalled it and where it spread

Scoping has two parts. The first is recall: every session in which the poisoned entry was retrieved into context. The second is propagation: every other place the entry's content reached.

Recall scoping. Search agent traces and retrieval logs for the entry ID (or the chunk IDs of a poisoned document) from the first write to now. For each hit record the session, the user, the agent version and every tool call that followed in that session. Where logs record only the query and not the result IDs, re-run stored queries against a snapshot that still contains the entry to estimate which sessions would have retrieved it, and label the result as an estimate. The Agent Activity Timeline Reconstruction guide covers joining traces to identity logs.

Propagation scoping. Check each path below, because removing the original entry does not remove these copies.

Propagation path	How poison travels	What to search
Memory consolidation	Background jobs summarise or merge entries into profiles	Consolidated entries created after the first poisoned write that cite or contain its text
Cross-user shared memory	Team or organisation memory recalled by every member	All users of the shared namespace in the window
Multi-agent handoff	One agent passes recalled content to another, which stores it	Handoff messages and the receiving agents' write logs
Retrieval corpus	Agent writes notes, tickets or documents that are later indexed	Documents authored by the agent in the window, and their embeddings
Caches	Semantic or response caches return answers built on the entry	Cache entries created in the window; flush if in doubt
Fine-tuning or evaluation sets	Conversation logs harvested for training	Exports taken in the window

Use exact-text and near-duplicate search for the instruction across stores, not only the entry ID, because consolidation rewrites wording.

Containment: quarantine versus delete

Contain in this order: stop new writes from the attacking path, stop recall of known entries, then decide on deletion.

Option	Effect	Use when	Risk
Quarantine flag	Entry kept but excluded from retrieval	Default first move; scoping is still running	Needs retrieval code that honours the flag; test it
Disable memory reads for the agent or namespace	Agent runs without long-term memory	Shared store affected or entry count unknown	Degrades service; users notice
Freeze memory writes	No new entries stored	Write path still open or under investigation	Legitimate writes lost unless queued for replay
Pause the agent	No sessions at all	Recalled entry drives tool calls, egress or payments	Business impact; use the kill switch procedure
Delete	Entry removed	Scoping complete, evidence exported	Destroys evidence if done first; derivatives remain

Where the store offers no quarantine state, export the entry and its metadata to evidence storage before removal, and record the hash of the export. The AI Agent Kill Switch and Containment Guide covers pausing agents safely. Revoke or rotate any credentials the poisoned instruction could have caused the agent to expose.

Eradication and rollback

Eradication means the entry, its derivatives and the write path are all dealt with.

Close the write path. Apply the fix that stops the same content writing again: require user confirmation for memory writes from retrieved content, strip memory tools from sessions handling untrusted input, or block the delivery link pattern. ATLAS mitigation AML.M0031 Memory Hardening covers validation of memory updates and remediation processes for poisoned memory.
Choose the rollback point. Use the table below.
Restore into isolation. Load the chosen snapshot into a separate namespace, search it for the instruction text and near duplicates, and confirm it is clean.
Replay legitimate writes. Re-apply writes made since the snapshot that came from trusted provenance (direct user statements, verified system writes), and leave out writes from the poisoned sessions unless a person reviews them.
Rebuild derivatives. Re-run consolidation and re-embed affected documents from clean sources; flush caches.
Cut over and watch. Switch retrieval to the restored namespace with the canary queries running, and keep the old store read-only as evidence.

Situation	Rollback choice
First poisoned write time known, snapshots exist before it	Last snapshot before the first write, plus replay of trusted writes
First write time unknown	Earliest snapshot that passes the instruction search, and say in the report that the window is uncertain
No snapshots, entries versioned	Revert affected entries to the prior version; quarantine entries with no clean version
No snapshots, no versions, single user	Targeted delete after export, then have the user review remaining memories
No snapshots, shared store, scope unknown	Rebuild memory from trusted sources or start empty; this is the costliest outcome and the strongest case for snapshots

Evidence to preserve

The entry and its metadata: content, ID, write time, writing session, provenance fields, embedding vector and version history.
The source content: the email, page, document or tool output that caused the write, with headers and URLs.
Recall traces: retrieval logs and full traces for every session in scope, including tool calls and model outputs.
Store snapshots: the pre-incident snapshot used for rollback and a snapshot of the store at containment.
Identity records: the agent identity, user identities and any credentials used or exposed, with their activity logs.
Change records: agent and prompt versions, memory configuration and the fix applied.

Hash exports and keep them under the retention your forensic readiness policy sets. See the Forensic Readiness Guide.

Notification triggers

Memory poisoning is not a reportable category in itself. Notification depends on what the memory held and what the agent did. Confirm each duty with your legal team.

Personal data: GDPR Article 4(12) defines a personal data breach as including alteration of personal data, not only disclosure, so a poisoned or exfiltrated memory about an identifiable user can be a breach. Article 33 requires notification to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to individuals, and Article 34 requires telling individuals where the risk is high.
Actions the agent took: payments, data sent outside, or changes to customer records follow the duties for those events, for example sector incident reporting or contract clauses.
High-risk AI systems: EU AI Act Article 73 requires providers of high-risk AI systems to report serious incidents, within 15 days of awareness in general and sooner in the cases it lists. The application date of the high-risk obligations has been the subject of EU simplification proposals, so confirm the date that applies when you assess an incident.
Platform providers: if the agent runs on a third-party platform, report the delivery mechanism to the provider so it can address the write path for other customers.

Measuring readiness

Share of agents whose retrieval logs record memory entry IDs (target 100 per cent for agents with tool access).
Snapshot interval and the age of the oldest restorable snapshot for each store.
Time to quarantine a known entry across all stores in an exercise (our target: under one hour).
Time to produce a recall list for an entry in an exercise.
Share of memory writes carrying provenance (user, retrieved content, system).

Run the scenario at least twice a year; the AI agent incident exercises guide has formats.

Common failure patterns

Deleting first: the entry is removed on discovery, so nobody can search traces for its ID or compare it with snapshots.
Forgetting derivatives: the original is gone but a consolidated profile still carries the instruction, and the behaviour returns days later.
Restoring the latest backup: yesterday's snapshot already contained the entry, because the first write was weeks earlier.
Treating it as one user's problem: the entry sat in a team namespace recalled by everyone.
Confusing memory poisoning with a compromised memory component: when the memory library itself is trojanised, the response is a supply chain and credential incident, as in the MemTensor MemoryOS supply chain attack, where backdoored package versions targeted the credentials in the agent's environment. See AI agent supply chain incidents.
Leaving the write path open: the same newsletter or shared document writes the entry again after cleanup.

Framework mapping

Framework	Reference	Where it applies
MITRE ATLAS	AML.T0080.000 AI Agent Context Poisoning: Memory; AML.T0070 RAG Poisoning	Classifying the incident and related retrieval poisoning
MITRE ATLAS	AML.M0031 Memory Hardening	Write validation and remediation of poisoned memory
OWASP Top 10 for Agentic Applications 2026	ASI06 Memory and Context Poisoning	Risk register entry for the scenario
NIST SP 800-53 Rev 5	IR-4, IR-6, CP-9, CP-10	Handling, reporting, memory snapshots and restoration
NIST CSF 2.0	RS.MA-01, RS.CO-02, RC.RP-01	Executing the plan, notifying stakeholders, recovery

Practitioner checklist

Log memory entry IDs in every retrieval trace, with session, user and agent version.
Record provenance on every memory write: user, retrieved content (with source), or system.
Build and test a quarantine flag that retrieval honours, before you need it.
Snapshot memory stores on a schedule and know which snapshot predates any given date.
On detection: close the write path, quarantine, export evidence, then scope recall and propagation.
Search derivatives (consolidated entries, agent-authored documents, caches, other agents' stores) by text, not only by ID.
Choose the rollback point from the first poisoned write, restore into isolation, replay only trusted writes.
Assess data protection and sector notification duties from what the memory held and what the agent did.
Exercise the scenario twice a year and track time to quarantine and time to recall list.

AI Agent Memory Poisoning Response Playbook: Scoping, Quarantining and Rolling Back Poisoned Agent Memory