Prompt Injection Persists in LLM Agent Memory: One Payload, Every Session

If your LLM agent writes anything to long-term memory, a single successful prompt injection can stop being a per-session incident and become a standing instruction that reasserts itself in every future session. A preprint posted the week of 2026-10-23 defines the attack class precisely: “Memory injections are prompt injections added to long-term memory, allowing them to be applied to future model contexts. This approach can make prompt injections automatically reusable, potentially leading to persistent effects.” The practical consequence for anyone shipping mem0-style stores, Letta, Zep, or a hand-rolled memory layer is that clearing a session no longer clears a compromise, and the familiar hygiene mechanisms, truncation, summarization, and retrieval ranking, will not scrub the payload either, according to the Zombie Agents study.

That changes where the decision lives. The question is no longer “how do I filter injections at prompt time” but “should this workload have persistent memory at all, and if it must, where do integrity controls sit in the memory lifecycle.” This article maps the memory designs engineers actually ship to their compromise blast radius and remediation cost, using six self-reported, unreviewed arXiv preprints. None of them is peer-reviewed, and none supplies production incident evidence; where a number appears, it is labeled accordingly.

One injection, every future context

The attack chain is simple enough to explain in two steps. In step one, the agent ingests untrusted content, a web page, a document, an email, another agent’s output, during an otherwise benign session. Embedded in that content is an instruction crafted to look memorable: a user preference, a standing rule, a fact about the environment. The agent’s memory writer stores it. In step two, days or weeks later, an unrelated task retrieves that memory, and the model treats stored content as instruction rather than data.

Zombie Agents formalizes this as a persistent attack: “untrusted external content observed during a benign session can be stored as memory and later treated as instruction.” The injection does not need to fire during the session in which it lands. It waits for retrieval, which the agent’s own relevance ranking will eventually supply.

Nor is this purely theoretical framing. The October 2026 preprint anchors prior art in SpAIware, which it identifies as the first peer-reviewed demonstration that memories are a critical attack surface and the only one to target the native memory feature of a major LLM-based service. That detail matters because it moves the threat off custom agent frameworks and onto the built-in “remember this” features that ship with mainstream products. The same preprint then attacks those products directly, reporting that “all evaluated services can be manipulated to persistently spread disinformation, generate harmful content, or simulate offline unresponsiveness, even in fresh sessions.”

The economics are what should worry a platform team. A prompt-time injection has to succeed once per session, per victim, per task. A memory injection succeeds once, and then the agent’s own retrieval infrastructure amortizes it across every future context. The attacker’s cost is fixed; the defender’s exposure grows with the deployment’s lifetime.

Storage varies by vendor; execution varies by nearly everything

The headline framing, one payload, every session, needs one honest qualification before it can guide a decision, and the same literature supplies it.

The Injection, Execution Dissociation study separated the two stages and measured them independently. Its self-reported result: malicious instructions were stored in persistent memory at rates exceeding 97.5% across all OpenAI models it tested, with nearly all OpenAI and Gemini runs storing the malicious rule regardless of execution resistance, while downstream execution ranged from 0% to 95% as a function of model generation, vendor, and defense configuration. Storage, in other words, is close to a solved problem for the attacker on OpenAI- and Gemini-class models. Anthropic is the exception that changes the risk picture for Claude-family deployments: the paper reports that “Anthropic models were the only ones that consistently blocked storage at the injection layer, leaving no adversarial state in persistent memory,” with one non-Anthropic exception, Meta’s Llama 4 Maverick, appearing in a single breadth screen. Execution is a model- and task-dependent lottery.

A second self-reported measurement, from “From Untrusted Input to Trusted Memory”, quantifies persistence across two agents with an average attack success rate (ASR) of 50.46% and an average retrieval success rate (RSR) of 41.05%. The HERMES agent in that study showed an average retrieval success of 64.70%, with a strong-signal attack variant the authors call Conditional Command Insertion reaching 92.76%. These are preprint numbers awaiting peer review, but the shape of the result is consistent across papers: the payload gets in, it stays in, and it comes back out often enough to matter.

So “every session” is accurate about reassertion, the payload is durably present and repeatedly surfaced, and inaccurate as a guarantee of execution. The right reading for a risk model: a stored injection is a recurring lottery ticket the attacker holds forever, not a single coin flip you already survived. A deployment where execution measured near 0% in a benchmark is one model update or one prompt-template change away from a different number, and on the models where storage is near-universal the payload is already written and waiting for that change. The Anthropic exception is real but snapshot-bound: the same paper cautions that frontier safety is “neither categorical nor vendor-uniform in our evaluation window,” so treat blocked storage as a property of the tested model versions rather than a permanent vendor guarantee.

Why memory hygiene fails as remediation

The instinctive response, “we’ll clean the memory periodically,” runs into the strongest negative result in this literature. Zombie Agents tested the mechanisms teams already run and reports that “common memory mechanisms, including truncation, summarization, and retrieval ranking, do not reliably remove malicious instructions once they enter memory.”

Each failure has a mechanism. Truncation drops old memories, but a well-formed injection reads like a high-value user preference and gets refreshed or re-embedded as the agent touches it. Summarization rewrites memories, but a summarizer is itself an LLM that treats the malicious instruction as content worth preserving; compression preserves semantics, and the payload’s semantics are the problem. Retrieval ranking demotes irrelevant memories, but the whole point of the injection is to be phrased so that future tasks retrieve it as relevant.

This has a direct implication for vendor claims. If a memory product’s security story is “we summarize and filter,” the self-reported evidence says that story does not hold. Remediation after a confirmed poisoning is not a cleaning pass; it is closer to a memory reset or rebuild, a cost that grows with how much legitimate long-term state the agent has accumulated. Nothing in these papers quantifies that cost for a production system, but the direction is clear: the longer memory persists before you discover the poisoning, the more you stand to lose by resetting it.

Mapping memory designs to blast radius

Putting the four measurement papers together yields a decision framework along three axes: how long the memory lives, how far a stored injection can travel, and what cleanup costs after the fact.

Two cells in that table are inference rather than measurement, and I want to mark them as such. The row-level mapping of designs to remediation cost follows from measured persistence plus measured cleanup failure; no paper benchmarked the full reset cost of a production deployment. And the fit recommendations are my judgment from those findings, not a benchmarked comparison of architectures.

Where integrity controls actually work

The literature converges on an uncomfortable claim: the control point is not retrieval. A separate preprint on origin-bound authority states it directly: “Memory integrity for LLM agents is not a detection problem but a question of whether an adversary can launder an untrusted memory’s authority.” Detection at retrieval asks a model to recognize that a well-phrased, contextually relevant memory is hostile. Prevention asks the system to never let untrusted content acquire the authority of a user instruction in the first place.

That reframing produces three candidate control placements, each with different evidence behind it.

Retrieval-time filtering is the weakest. It is the approach the cleanup results already undermine, and it inherits the general fragility of using models to judge model input.

Memory-layer tool-gating has the strongest empirical support in the packet, with a serious caveat. Of six defenses evaluated in the dissociation study, “only tool-gating at the memory layer consistently disrupted the attack, and even this defense can invert for models whose safety depends on execution refusal rather than injection resistance.” The inversion matters: if your model’s safety posture relies on refusing malicious instructions at execution time, gating which memories reach tools can interfere with the signals that refusal depends on. Before adopting the one consistently effective defense, you need to know which safety strategy your model actually implements.

Machine-checked gates with provenance are the most architecturally ambitious. PerMIT, posted the same week as the attack preprint, proves “two integrity theorems that are also machine-checked in Lean 4, which together ensure that environment-derived memory reaches a sensitive action only if confirmed at the gate.” Its authors self-report zero observed attack success on the Trojan Hippo benchmark. The theorems are machine-checked, which is a genuinely stronger guarantee than a heuristic filter, but the zero-attack-success figure is specific to one benchmark. PerMIT also frames persistent memory as “a largely undefended surface” and argues the same risk limits memory sharing between agents, which is worth weighing before wiring a shared memory bus into a multi-agent system.

The origin-bound authority paper takes the complementary position at write time: bind every memory’s provenance at the moment it is written, so that untrusted-origin content can never exercise instruction-level authority downstream, with machine-checked guarantees of its own.

The pattern across all three: the controls that work operate on the memory lifecycle (write-time binding, action-time gating), not on the prompt and not on retrieval scoring.

What remains unverified

Everything cited here is a self-reported arXiv preprint, unreviewed as of 2026-10-24, and several things a buyer would want are simply absent:

• No documented in-the-wild incident. The October preprint executed its attacks against the native memory features of the ChatGPT, Claude, and Gemini services, which is more than a pure benchmark, but it is a researcher-run experiment, not a real-world memory-poisoning compromise.
• The 0% to 95% execution spread is partially attributed by the dissociation paper to model generation, vendor, and defense configuration, but not at the level a practitioner needs. Which model properties, task types, or memory configurations put you near the bottom of that range is an open question.
• PerMIT’s zero attack success is one benchmark (Trojan Hippo). Its community trust scoring assumptions, runtime cost, and behavior against adaptive attackers are unverified.
• Letta and Zep are untested: no paper in this set evaluates either. Vendor-native memory is covered by the October preprint’s attacks on ChatGPT, Claude, and Gemini, and Mem0 appears as the harness target in the origin-bound authority study, where the undefended agent was poisoned in 50.0% of episodes.
• The persistence measurements could move in either direction under peer review.

Treat the numbers as directional evidence about a mechanism, not as rates to put in a risk register.

When should your agent’s memory persist at all

The practical verdict, bounded by the caveats above:

Default to ephemeral context for untrusted-content workloads. If the agent’s job is reading web pages, summarizing documents, or triaging inbound email, per-session memory removes the attack class entirely at the cost of continuity the workload probably did not need. This half of the recommendation is a bounded inference from measured persistence plus measured cleanup failure, not a benchmarked architecture comparison, but the asymmetry favors it: ephemeral memory costs you a feature; persistent memory costs you a trusted computing base you now have to defend.

Where memory must persist, treat it as part of the trusted computing base. The Zombie Agents conclusion is the minimum bar: “Defenses should treat memory as part of the trusted computing base. At minimum, systems should separate untrusted data from executable instructions during memory write and retrieval.” Concretely, that means binding origin at write time, so a memory derived from environment content can never masquerade as a user instruction, and gating sensitive actions on verified memory, along the lines PerMIT formalizes.

Do not share memory across agents until the integrity story is settled. Sharing multiplies blast radius, and the strongest defense in the packet is explicit that the risk currently limits it.

Budget for reset, not cleanup, in your incident response plan. If the hygiene results hold, the honest remediation after confirmed poisoning is rebuilding memory from a known-good state. Whether your agent’s accumulated memory is worth more than the exposure it creates is now a decision to make on purpose, per workload, rather than a default that ships with the framework.

The papers will be revised, and the numbers will move. The structural findings, storage dissociated from execution, hygiene mechanisms that fail, and integrity controls that belong at write time and at the gate, are the part worth designing around now.

Frequently Asked Questions

Do standard memory hygiene practices like summarization remove malicious injections?

Zombie Agents tested the mechanisms teams already run and reports that “common memory mechanisms, including truncation, summarization, and retrieval ranking, do not reliably remove malicious instructions once they enter memory.”

Which defense consistently disrupted the attack in the dissociation study?

Of six defenses evaluated in the dissociation study, “only tool-gating at the memory layer consistently disrupted the attack, and even this defense can invert for models whose safety depends on execution refusal rather than injection resistance.”

What is the recommended default for agents processing untrusted content?

Default to ephemeral context for untrusted-content workloads. If the agent’s job is reading web pages, summarizing documents, or triaging inbound email, per-session memory removes the attack class entirely at the cost of continuity the workload probably did not need.