Memory Poisoning: When an Agent's Own Persistent Memory Becomes the Attack Surface

Memory poisoning is the injection of false, misleading, or adversarial content into an agent's persistent memory store, where it survives beyond the session that created it and is later retrieved as if it were verified fact. Unlike a single bad response, a poisoned memory entry does not need to be repeated by an attacker or re-triggered by a fresh mistake: it sits in the store until a semantically related query surfaces it, then shapes the agent's reasoning on a task the attacker was never present for. That delay is the defining property. A prompt injection that fails is over when the turn ends; a memory injection that succeeds keeps paying out.

This is a persistence-layer failure, not an input-side one, which separates it from the mechanisms already covered on this site. Context rot is the model losing reliable access to information that is still present in a single long window. Memory poisoning is different: the window can be short and clean, and the agent still acts on a false premise, because the premise was written to durable storage and read back as ground truth. It also differs from ordinary context drift, where cached content simply goes stale through the normal passage of time; a poisoned entry is not stale, it was never true, and it was placed there specifically because it would be retrieved and trusted.

Mechanism

Memory poisoning requires a write path into the store and a retrieval path that surfaces poisoned content without re-verifying it. Both are structural features of any agent designed to remember across turns, which is why the vulnerability tracks memory capability rather than any specific implementation bug.

A systematic taxonomy of the write side, evaluated across two agent systems (OpenClaw and HERMES, both run on GPT-OSS-120B), identifies four distinct channels through which adversarial content enters memory: explicit instruction-executed writes, where the agent is told directly to remember something; system-prompt-driven writes, where content is evaluated against a retention policy and stored if it passes; compaction-driven writes, where summarization folds attacker content into a persisted digest; and experience-to-procedure writes, where the agent generalizes a past interaction into a reusable skill (Dash et al., arXiv:2606.04329). The same paper splits attacks into two signal classes: strong-signal attacks that contain a detectable explicit command, and weak-signal attacks, such as Policy-Conformant Fact Injection and False Precedent Insertion, that are semantically indistinguishable from legitimate content and therefore harder to filter. Measured attack success rates diverged sharply by agent design: an average of 34.25% on OpenClaw versus 66.67% on HERMES, with retrieval success rates of 17.40% and 64.70% respectively. The paper's own conclusion is the operationally important part: "agents designed to write and retrieve memory more aggressively are more exploitable," meaning the same design choices that make long-horizon memory useful also widen the channel poisoned content travels through.

The retrieval side has been shown to work through query-only interaction, with no need for direct access to the memory store at all. MINJA, a memory injection attack tested against three agent types, EHRAgent on medical record datasets, RAP on a web-shopping benchmark, and a general-purpose QA agent on MMLU, achieved over 95% injection success across all agents and datasets and an average 76.8% attack success rate in eliciting the intended malicious reasoning, using GPT-4 and GPT-4o as the underlying models across nine victim-target pairs per configuration (Dong et al., arXiv:2503.03704). The method works by having the attacker's queries elicit a chain of "bridging steps" from the agent itself, then progressively withdrawing an indication prompt so the resulting record reads as the agent's own natural reasoning, ready to be retrieved as a precedent when a later, unrelated victim query is semantically close enough.

A third study isolates the delay explicitly. In a "sleeper" attack, adversarial instructions embedded in external content, a document, a webpage, a repository, manipulate the agent into storing a fabricated memory about the user during an initial interaction. That entry then persists undetected until a later, semantically related question causes retrieval to surface it, at which point it steers the response toward the attacker's original objective (Pulipaka et al., arXiv:2605.15338). Injection success ranged from 95% to 99.8% across six frontier models, and the resulting adversarial usage rate on goal-adjacent queries ranged from 60% to 89% in agentic settings, with end-to-end success on behavioral tasks between 41.0% and 73.9%. The authors' framing captures why this is a state-decay problem rather than a one-shot exploit: "the effect need not be immediate: the attacker can repeatedly influence future behavior without being present."

How it differs from adjacent failure modes

Memory poisoning can look like several things it is not, and the distinction determines which mitigation applies.

It is not state externalization failing by design; it is what happens when externalized state is treated as trusted by default. That article's pitfalls list already names the symptom, "trusting recalled facts" and "stale state files," without naming the mechanism that can put a false fact there deliberately. The fix set is related but not identical: staleness is solved by freshness rules, poisoning requires provenance checks and write-side validation, because a poisoned entry can be perfectly fresh.

It is not tool-use drift, where selection degrades toward a recently- or memory-favored tool without any single entry being false. A poisoned memory can look exactly like a legitimate precedent and still steer tool selection, plan formation, or a factual answer, which is why weak-signal attacks are the harder half of the taxonomy above: they do not trip a content filter because nothing about them is anomalous in isolation.

It is not role drift, which erodes persona and permission boundaries through gradual pressure inside a session. Memory poisoning can produce role-drift-shaped symptoms, an agent suddenly willing to do something it previously refused, but the cause is a discrete injected record rather than accumulated conversational pressure, and it can appear at the very start of a fresh session if that session retrieves a poisoned entry from a prior one.

How to measure

• Write-path audit: log every memory write with its channel (explicit instruction, policy-evaluated, compaction, or procedure synthesis, per the taxonomy above) and its source content. A spike in writes attributable to external, untrusted content (documents, tool outputs, web pages) rather than direct operator instruction is the leading indicator.
• Provenance coverage: for every retrieved memory entry the agent acts on, check whether it carries a source and verification status. Entries with no recorded provenance are unauditable by construction and should be flagged regardless of content.
• Retrieval-outcome divergence: replay a fixed probe query at different points in a session with the persistent memory store live versus a clean, empty store, per the method in drift regression tests. A material behavioral divergence traceable to a specific memory entry, rather than to context length or recency, is the signature to isolate.
• Dormancy testing: deliberately seed a test store with a known-false, semantically plausible entry in a non-adjacent session, then issue a later, related query and check whether it surfaces and is acted upon. This tests the exact dormancy-then-activation pattern documented for sleeper attacks, and it is testable without adversarial intent since your own team controls both the seed and the probe.

Mitigation

Never let a memory write happen on the same trust level as the content that triggered it. External content, tool output, retrieved documents, web pages, should not be able to reach the store through the same path as an explicit, operator-issued instruction; the taxonomy's weak-signal attacks specifically exploit the case where these paths are merged.

Attach provenance and a verified/unverified flag to every stored fact, per the fact-store pattern in state externalization, and gate retrieval on it: unverified entries can inform a draft but should not be actable without a check. This is a structural requirement, not a filtering one, because the weak-signal attack classes above are built to pass content filters by design.

Treat compaction as a write path deserving the same scrutiny as an explicit memory command, since Salience-Driven Compaction Poisoning specifically targets the summarization step to fold adversarial content into what looks like a routine digest. A compaction step that can be influenced by the content it is compacting is a poisoning vector, not just a lossy-summary risk.

Bound how aggressively memory is written and retrieved to what the task requires. The measured gap between OpenClaw's 34.25% and HERMES's 66.67% attack success rate tracks directly with how aggressively each system writes and retrieves memory, which means the write/retrieval policy itself is a tunable security parameter, not just a performance one.

Related terms

• State externalization: the durable-memory pattern memory poisoning attacks against; its pitfalls list names the symptoms this article names the mechanism for.
• Context rot: an input-side degradation of a single window; memory poisoning is a persistence-side injection that survives across sessions.
• Tool-use drift: selection degradation without a false entry; a poisoned memory can produce similar symptoms through a different cause.
• Role drift and role pinning: gradual persona erosion within a session, versus a discrete injected record that can appear at session start.
• Drift regression tests: where clean-store-versus-live-store probes and dormancy tests belong in an ongoing suite.

FAQ

Is memory poisoning only a security concern, or does it happen without an attacker? The research above studies it as an adversarial attack, but the same write and retrieval paths that let a crafted query poison memory also let an agent's own hallucinated fact get stored and later retrieved as precedent, with no attacker involved. The mechanism, unverified content entering a trusted store, is the same either way; only the intent behind the initial write differs.

Does a short context window protect against memory poisoning? No. The attacks documented here operate on the persistent store, which is read back into a fresh, short context on the next relevant query. A clean window at the start of a session offers no protection if the memory it retrieves from is already poisoned.

Is this the same as prompt injection? Related but distinct. Prompt injection manipulates a single inference by hiding instructions in input content. Memory poisoning frequently begins with a prompt injection, malicious content in a document or tool output, but its defining feature is what happens next: the injected content is written to persistent storage and re-activated later, independent of the original injection vector. Sleeper-style attacks show the two can be separated by an arbitrary number of sessions.

Can filtering memory content at write time fully solve this? Not by itself. Weak-signal attack classes, Policy-Conformant Fact Injection and False Precedent Insertion among them, are specifically designed to be semantically indistinguishable from legitimate content, so no content filter catches them reliably. Provenance tracking and verification gating at retrieval time are necessary complements, not optional extras.