Poisoned memory is the security problem that arrives the moment an AI agent stops forgetting. New research published in September 2026 argues that once an agent writes what it learns into a store it will read back later, an attacker no longer needs to win the conversation in front of them. They only need to get one sentence into the notebook and wait.
That argument comes from Abbas Yazdinejad, an assistant professor in the Department of Computer Science at the University of Regina, writing in The Conversation about work he carried out with Hadis Karimipour at the University of Calgary. Their paper is in IEEE Access, and its central claim is not that memory poisoning exists — that much was already documented — but that the risk is temporal, and that almost every way we currently test agents is blind to time.
We covered the underlying attack pattern when it first surfaced in our explainer on AI agent memory poisoning and hidden prompts. This article is about the follow-on finding: what a poisoned memory does in the days after it lands, why a security check run at the moment of injection tends to come back clean, and what a defensible test regime looks like instead.
Table of contents
- What a Poisoned Memory Actually Is
- How a Poisoned Memory Gets In
- The Research Behind the Poisoned Memory Warning
- Why a Poisoned Memory Waits Before It Acts
- How Often a Poisoned Memory Actually Sticks
- What a Poisoned Memory Changes for Security Testing
- Where a Poisoned Memory Meets Tools and Permissions
- Defending Against a Poisoned Memory in Practice
- What the Poisoned Memory Research Does Not Say
- Poisoned Memory: Common Questions
- References
What a Poisoned Memory Actually Is
The term describes adversarial content that has been written into an agent’s persistent state, rather than into the prompt it is currently answering. It survives the conversation that created it.
The notebook an agent keeps
Yazdinejad’s own analogy is a notebook. An agent completes a task, writes down something useful, and consults the page later. Slip a misleading line into that notebook — requests from this person have already been approved — and nothing visibly happens. The agent finishes several unrelated jobs correctly. The poisoned memory only matters when a relevant request finally arrives and the page gets read.
Why this is not prompt injection
Prompt injection is a single-turn problem: malicious text arrives, the model is steered, the damage lands inside that exchange. A poisoned memory separates the two halves. Injection happens once, in content the agent merely read — a document, a webpage, a repository, a support ticket. Activation happens later, in a session the attacker is not present for.
Where the memory physically lives
In practice the store is a vector index, a summarised conversation history, a scratchpad file, a user-profile record or a retrieval corpus. All of them are writable at runtime, which is what separates them from model weights. The OWASP AI Agent Security Cheat Sheet gives memory and context their own section for exactly this reason.
| Dimension | Prompt injection | Poisoned memory |
|---|---|---|
| Where it lands | The current prompt | Persistent agent state |
| Lifetime | One exchange | Across sessions |
| Attacker present at harm? | Yes | No |
| Detectable at injection | Often | Frequently not |
| Test that catches it | Single-turn red teaming | Trajectory-level evaluation |
| OWASP class | Injection controls | ASI06, Memory Poisoning |
How a Poisoned Memory Gets In
The injection channel is almost always ordinary content the agent was asked to process. Nobody has to breach the model, the host or the account.
Documents, pages and repositories
An agent that summarises a supplier PDF, reads a public webpage or indexes a code repository is ingesting text an attacker may control. If any part of that pipeline decides the content is worth remembering, the attacker has written to the store without ever holding a session. This is the route the sleeper poisoning work tested directly.
The summarisation step is the danger
Raw retrieved text is usually treated with suspicion. A summary of it often is not. When a pipeline compresses a long document into a durable fact and files it under a user profile, the provenance is stripped and the sentence is promoted from quoted material to remembered truth. A poisoned memory laundered through summarisation is much harder to spot on review than the paragraph it came from.
Tool output nobody reads
Agents also remember what their tools return. A ticketing system, a CRM note, a shared wiki or another agent’s response can all carry attacker-supplied text into the store, and none of them look like an untrusted boundary on an architecture diagram. In a multi-agent setup the write may be performed by a component that never saw the original document at all.
Why the attacker prefers this
The economics favour it. A prompt injection has to succeed while someone is watching the transcript. A poisoned memory only has to survive a write, then wait — and the research on delayed activation says the waiting period is exactly when nothing looks wrong.
The Research Behind the Poisoned Memory Warning
The study is the first large-scale attempt to measure this at the level of a whole interaction sequence rather than a single step.
Who ran it, and where it was published
The paper is Temporal Dynamics of Memory Poisoning in Web3-Style LLM Agents, by Yazdinejad and Karimipour, published in IEEE Access, volume 14, pages 76200 to 76221, in 2026. It is gold open access under a CC BY licence, so the full method is readable without a subscription — worth noting, because most agent-security claims this year have arrived as vendor blog posts.
The 2,614 trajectories
The authors built a schema-constrained dataset of 2,614 multi-step attack trajectories against memory-enabled large language model agents, executed over shared persistent memory. The setting is deliberately long-horizon and tool-using: Web3-style autonomous workflows, where an agent runs many steps and reuses what it stored. That is the shape of enterprise agent deployments too.
The four attack families
Every trajectory belongs to one of four families. The names matter, because they describe genuinely different mechanics rather than four labels for the same trick.
| Attack family | What the attacker writes | Temporal signature reported |
|---|---|---|
| Chain poisoning | A sequence of entries that build on one another | Non-monotonic risk trajectory |
| Policy rewriting | A remembered rule or permission that replaces the real one | Non-monotonic risk trajectory |
| Backdoor triggering | A dormant entry that fires on a specific later cue | Evades step-local evaluation until terminal steps |
| Slow drift | Small nudges that accumulate over many steps | Evades step-local evaluation until terminal steps |
Why a Poisoned Memory Waits Before It Acts
The paper’s contribution is a set of temporal risk metrics defined over trajectories rather than over steps. Three of them do most of the work.
Delayed activation
This is the headline. The authors report that a substantial fraction of attacks remain indistinguishable from benign behaviour until late-stage activation, despite exhibiting low or medium risk at all earlier steps. A scanner watching each step in isolation sees a well-behaved agent for the entire window in which intervention would have been cheap.
Non-monotonic escalation
Risk does not climb in a straight line. Chain poisoning and policy rewriting both produce trajectories where the agent looks more concerning at one point, then less concerning, before the attack finally develops. Any control that treats a falling risk score as evidence of recovery will stand down at precisely the wrong moment.
The earliest distinguishable point
The third metric asks when an attack first becomes separable from normal behaviour. For slow drift and backdoor triggering, the paper’s finding is blunt: that point arrives at the terminal interactions. Step-local evaluation is systematically evaded until then, which is a measurement failure rather than a detection tuning problem.
How Often a Poisoned Memory Actually Sticks
The IEEE Access work measures timing. A separate preprint measures success rates, and read together the two answer different halves of the same question.
The sleeper poisoning numbers
Hidden in Memory: Sleeper Memory Poisoning in LLM Agents, posted to arXiv in May 2026 by Sidharth Pulipaka and colleagues, tested the full pipeline: whether a fabricated memory gets written, whether it is retrieved later, and whether it then steers behaviour. Poisoned memories were added in up to 99.8% of attempts on GPT-5.5 and 95% on Kimi-K2.6.
From retrieval to action
The number that should worry anyone running tools behind an agent is the last one. Among successful retrievals, the poisoned memory caused attacker-intended agentic actions in 60% to 89% of evaluations across models. Retrieval is not a near miss. In most of these runs it was the whole attack.
What a Poisoned Memory Changes for Security Testing
If the risk is temporal, then the unit of evaluation has to change. This is the practical consequence of the whole paper.
Why snapshot testing comes back clean
Picture a security team that inspects an agent immediately after it ingests a suspicious document. Behaviour looks normal, so the interaction is logged as safe. That is the equivalent of reading a notebook one second after someone forged an entry but before anyone acted on it. The absence of harm is not evidence that the poisoned memory failed.
Trajectory-aware evaluation
What the authors argue for instead is trajectory-aware security testing: judging how behaviour develops across a sequence of interactions rather than scoring each step alone. Anthropic makes a structurally similar argument in its engineering guidance on evaluating agents, where the recommended unit is the whole run rather than the individual response.
What to actually log
Trajectory-level testing needs trajectory-level telemetry, and most agent stacks do not have it yet. The minimum useful record ties each memory write to the source that caused it, each retrieval to the write it came from, and each tool call to the retrieved entries in context at the time.
| Test approach | Unit judged | Catches delayed activation? |
|---|---|---|
| Single-turn red teaming | One prompt | No |
| Step-local risk scoring | One interaction step | Not for slow drift or backdoors |
| Static context snapshot | Memory contents at one moment | Only if the entry looks malicious |
| Trajectory-aware evaluation | The full interaction sequence | Yes, by construction |
Where a Poisoned Memory Meets Tools and Permissions
Memory alone produces a wrong sentence. Memory plus tools produces a wrong action, and that is where the business exposure sits.
The read and write asymmetry
Most teams have thought hard about what their agent is allowed to do and very little about what it is allowed to remember. Write access to the memory store is usually implicit, granted to anything the agent reads. A poisoned memory exploits that gap directly, because the attacker’s content never has to look like an instruction to the tool layer.
Blast radius in a shared store
The IEEE Access experiments ran over shared persistent memory, which is also how multi-agent deployments are commonly built. One poisoned memory in a shared store can be retrieved by an agent that never touched the original document, and by a user who has no relationship with the attacker at all.
The identity problem underneath
None of this is fixed by authentication alone. We made the wider version of that case in our piece on why passing authentication is not the same as staying trustworthy at runtime, and a poisoned memory is the cleanest example: the agent is exactly who it claims to be, holding exactly the permissions it was granted, and still acting on someone else’s instruction.
Defending Against a Poisoned Memory in Practice
The defensive picture is better than it was six months ago, mostly because the threat now has a name, a number and a reference implementation.
OWASP ASI06 and Agent Memory Guard
Memory poisoning is ASI06 in the OWASP Top 10 for Agentic Applications. OWASP Agent Memory Guard, announced on 1 June 2026, is the reference defence: a runtime layer that sits between the agent and its memory store and screens every read and write through a pipeline of detectors and a YAML policy that maps findings to allow, redact, quarantine or block. It ships integrations for LangChain, LlamaIndex and CrewAI, and uses SHA-256 baselines to flag out-of-band tampering.
A written memory policy
Treat the store as a privileged resource. Decide in advance which sources may cause a write, which fields are protected keys that nothing external may modify, and what happens when a write is rejected. A poisoned memory is far harder to plant when the write path has an owner.
Expiry, provenance and replay
Three controls do most of the work and none of them need a new vendor. Give remembered facts an expiry so an old poisoned memory cannot sit indefinitely. Record provenance so any entry can be traced to the document that produced it. Keep enough history to replay a trajectory after the fact, because that is the only way to find the injection once activation has happened.
| Control | Stage it protects | Effort |
|---|---|---|
| Screening on every memory write | Injection | Middleware, low |
| Protected keys that external content cannot set | Injection | Schema change, low |
| Provenance on every stored entry | Investigation | Schema change, medium |
| Expiry and periodic memory review | Dormancy | Policy, low |
| Screening on retrieval, not only on write | Activation | Middleware, medium |
| Trajectory replay in the evaluation suite | Detection | Tooling, high |
What the Poisoned Memory Research Does Not Say
Being precise about the limits is part of taking the finding seriously, and the paper is honest about its scope.
Simulation, not incident data
The 2,614 trajectories are simulated and schema-constrained. They are not a log of real intrusions, and the paper does not claim a base rate for poisoned memory attacks in production. What it establishes is that the risk is temporal and that step-local evaluation cannot see it — a measurement claim, not a prevalence claim.
One workflow shape
The environment is Web3-style autonomous workflows. That is a reasonable proxy for long-horizon tool-using agents, and it is not the same as a customer support agent, a coding agent or a retrieval assistant. Whether the same temporal signatures hold across those shapes is open.
No model leaderboard
The IEEE Access work does not rank vendors, and the arXiv figures cover a small set of assistants. Nobody should read “99.8% on GPT-5.5” as a statement that one vendor is careless — the write rates are high because memory features are designed to accept new information, which is the point of having them.
The benefit side is real
Memory is not a defect to be removed. It is what lets an agent hold context, learn preferences and finish work that does not fit in one interaction; systems without it face the opposite problem, closer to catastrophic forgetting than to compromise. The conclusion is that the information carried forward now needs protecting, not that agents should stop remembering.
Poisoned Memory: Common Questions
What is a poisoned memory in an AI agent?
It is adversarial content that has been written into an agent’s persistent store — a vector index, a summary, a user profile or a scratchpad — so that the agent later retrieves it and treats it as something it learned and can trust. The defining feature is that injection and harm are separated in time.
How is it different from prompt injection?
Prompt injection steers the exchange it arrives in. A poisoned memory steers exchanges that happen days later, in sessions the attacker never sees. That delay is why the same detection controls do not transfer.
Can a poisoned memory be detected at the moment it is planted?
Sometimes, but the research says not reliably. Slow-drift and backdoor-triggering attacks were indistinguishable from benign behaviour under step-local evaluation until the terminal interactions, and chain poisoning and policy rewriting produced risk that fell before it rose.
Does my agent have this problem?
If it writes anything it learns to a store it reads back in a later session, yes, in principle. If it also calls tools, the consequence extends from a wrong answer to a wrong action. An agent with a stateless context window each session has a much smaller version of the problem.
What is the single most useful control?
Screening writes to the memory store, because it is the only stage where the entry is still isolated. OWASP Agent Memory Guard reports 100% precision and 92.5% recall doing exactly that, which is a strong start and still leaves 7.5% for the later stages to catch.
Is trajectory-aware testing realistic for a small team?
Partly. Full trajectory replay is a tooling investment, but the cheap half is not: log the provenance of every memory write and give stored facts an expiry date. Both narrow the window a poisoned memory has to work in without any new platform.
Where does this sit in enterprise AI governance?
Alongside identity and permissions rather than inside them. Our work on autonomous AI agents and on cybersecurity treats memory integrity as its own control domain, because an agent can be correctly authenticated, correctly scoped and still be running on someone else’s remembered instruction.
References
Abbas Yazdinejad in The Conversation on Poisoned AI Agent Memories
Tech Xplore on AI Agents That Remember and the Hackers Who Poison Them
Temporal Dynamics of Memory Poisoning in Web3-Style LLM Agents in IEEE Access
Hidden in Memory: Sleeper Memory Poisoning in LLM Agents on arXiv
OWASP AI Agent Security Cheat Sheet
OWASP Agent Memory Guard Project
Help Net Security on OWASP Agent Memory Guard
More AI coverage: explore Progressive Robot's AI Models, Tools & Releases hub — hands-on reviews, setup guides and benchmarks in one place.