Memory poisoning is the agent incident that breaks the usual assumption that the cause sits near the symptom. A corrupted entry planted in an agent’s persistent memory or retrieval store can sit quietly and steer decisions days or weeks later — across sessions, and sometimes across every user the agent serves. When it finally surfaces, the run that went wrong rarely contains the cause. Investigating it means working backward through time. In the OWASP Top 10 for Agentic Applications it is ASI06, Context Management and Retrieval Manipulation.
What memory poisoning is
An agent’s behavior is shaped not only by its current input but by what it remembers and retrieves: long-term memory, conversation state, and the documents pulled from a retrieval (RAG) store. Memory poisoning is the planting of corrupted, malicious, or misleading content into any of those, so that the agent’s later decisions are quietly steered by it.
The defining feature is time. A prompt injection acts in the moment — the hostile instruction is in the input the agent is processing right now. A poisoned memory waits. It is written once and read many times, influencing runs that may be days or weeks removed from the moment it was planted, and — when the store is shared — affecting other sessions and other users entirely.
Why memory poisoning is hard to investigate
Almost everything that makes a normal investigation tractable works against you here:
- Cause and effect are separated in time. The poison is planted long before the harmful decision, so examining the session that went wrong does not reveal the cause. The trail leads backward, out of the current run entirely.
- The damage is ongoing and plural. Because memory persists and is often shared, one poisoned entry can steer many later runs. The investigation has to assume more than one affected run until it proves otherwise.
- Retrieval looks legitimate. The agent reads its own memory or a trusted document — the access is entirely normal. The content is the problem, not the act of retrieving it, so there is no anomalous-access signal to catch.
- Provenance is often thin. Memory and retrieval stores frequently record what an entry says far better than who wrote it, when, and through what path — which is exactly what the investigation needs.
The investigation, step by step
A memory-poisoning investigation runs backward, from the bad decision to the entry that caused it to the moment it was planted:
1. Confirm it is memory, not a live injection
Establish that the harmful decision drew on stored or retrieved content rather than the current input alone. If the steering instruction is in the live prompt, it is a prompt injection; if it came from memory or the retrieval store, it is poisoning — and the cause is somewhere earlier.
2. Identify the poisoned entry
Trace the decision back to the specific memory or retrieval records the agent pulled in, and find the one whose content shaped the outcome. The poisoned entry is usually the one whose content does not match its claimed source or its write history.
3. Establish when it was planted, and by whom
Recover the entry’s provenance: when it was written or modified, through which path, and under which identity. This is where a poisoned memory becomes an attributable event rather than an anonymous fact — and where the non-human identity that wrote it gets named.
4. Trace the delivery vector
Determine how the poison got in. The common paths are a prompt injection that wrote to memory, a malicious document ingested into the retrieval store, a compromised upstream data source, or an upstream agent’s bad output stored as trusted input. The vector decides what you actually have to fix.
5. Establish blast radius across time and sessions
Enumerate every run that retrieved the poisoned entry, not just the one that triggered the investigation. Because the entry persisted and may have been shared, the real impact is the full set of decisions it could have steered — across sessions and users — which is almost always wider than the symptom that surfaced.
6. Contain and eradicate at the source
Quarantine the poisoned entry — after preserving it — and confirm there are no copies elsewhere in memory or the retrieval store. Recovery is its own hazard here: an agent restored while a single poisoned record remains will be re-steered the moment it reads it again. For the full lifecycle, see the AI-agent incident-response process.
7. Rate confidence, then report
A defensible account states what the evidence supports and no more. Each finding carries its confidence and is labeled as attested by the logs or inferred from them, reproducible, and backed by an intact chain of custody — including for the entry you removed.
What to collect
Memory-poisoning investigations depend on evidence that ties a decision to a retrieved entry, and that entry to its origin:
| Source | What it tells you |
|---|---|
| Memory & vector-store write logs | When each entry was created or modified, and by which identity |
| Retrieval logs | Which entries were pulled into which agent run |
| Agent decision / trace logs | Which retrieved content shaped a given decision |
| Ingestion-pipeline logs | What documents or data entered the store, and from where |
| Identity logs | The non-human identity behind a write |
| Upstream / source logs | Whether an upstream agent or external feed planted the entry |
No single source proves poisoning on its own; the case is built by linking a decision to an entry to a write. The more of these you have, the further back — and the more confidently — the trail can be followed.
Common mistakes
- Investigating only the session that failed. Looking for the cause inside the run where the harm appeared, when it was planted somewhere earlier.
- Treating it as a one-off. Fixing the single decision that surfaced and missing every other run the same entry steered.
- Trusting retrieved memory. Assuming an agent’s own memory or a known document is safe because it is “internal.”
- Deleting the entry too early. Removing the poison before preserving it or mapping its blast radius, and losing the evidence with it.
- Recovering into a poisoned store. Restoring the agent while a copy of the entry remains, and watching it re-trigger.
Where Agent Autopsy fits
Agent Autopsy is built to follow this kind of trail across time. It links an agent’s decisions to the memory and retrieval entries that shaped them, recovers each entry’s write provenance, traces the poison to its delivery vector — frequently a prompt injection — and maps every run the entry could have steered, all from the logs you already have and backed by a confidence-rated chain of custody. It is one application of the broader discipline of AI agent forensics. See how it works end to end, or how it is validated.
Frequently asked questions
How is memory poisoning different from prompt injection?
Timing and persistence. Prompt injection is in the input the agent is processing now and acts immediately; memory poisoning is planted in persistent memory or a retrieval store and steers decisions later — often days apart, and frequently across other sessions and users. The two are related: an injection is one of the common ways a poison gets written in the first place.
Why is memory poisoning so hard to investigate?
The separation in time. Because the poison is planted long before the harmful decision, examining the run that went wrong does not surface the cause. You have to trace the decision back to the entry that shaped it, and then back again to when and how that entry was written.
How do you find the poisoned entry?
By tracing the harmful decision to the specific memory or retrieval records it pulled in, then checking each one’s provenance. The poisoned entry is typically the one whose content does not match its claimed source or its write history — content that says one thing while the record of how it got there says another.
What is the blast radius of a poisoned memory?
Potentially every run that retrieved the entry. Because memory persists and is often shared across sessions or users, one poisoned record can steer many later decisions, so the investigation has to enumerate all affected runs rather than stopping at the one that surfaced the problem.