Published
- 5 min read
By Allan D - Editor, AI Security Wire
InjecMEM: One Interaction Can Plant a Poisoned Memory in an LLM Agent
Most prompt injection research targets the current conversation. InjecMEM, a paper accepted at COLM 2026, goes after the thing agents keep between conversations: their memory. The authors show that one interaction, from an attacker with no access to the memory store, can leave behind a record that is retrieved on later related queries and pushes the agent toward an attacker-chosen output.
Everything below comes from the paper (arXiv 2608.23471, Tian et al., submitted 24 August 2026). The tested systems are research frameworks, not commercial products.
How the Attack Works
The threat model treats the memory subsystem as a black box. The attacker cannot read or edit stored records, or the embedder inside the memory system. They get one interaction, which can be submitted directly or arrive through a compromised tool. The attacker picks a target topic and a target output.
The injected text has two parts:
- An anchor: a retriever-agnostic block of topical cues (a domain label, keywords and within-domain intents) meant to make the record likely to be retrieved when a user later asks about that topic.
- An adversarial command: a string optimised with a gradient-based coordinate search (Multi-GCG) over surrogate prompts and insertion positions, so that once retrieved it pushes the model to produce the target output.
The command optimisation assumes white-box access to the agent’s backbone model. Variants optimise jointly across several backbones, to study whether one command transfers.
What Was Tested
The primary memory system is MemoryOS, with MemGPT as an additional one. Backbone models were Qwen2.5-7B-Instruct (primary), other Qwen2.5 sizes, Llama-3.1-8B-Instruct and Mistral-7B-Instruct-v0.3. The main dataset was synthetic: 944 conversations across 19 domains generated with GPT-5, with about 1,900 held-out evaluation queries. WildChat conversations were used for Health and Finance.
The paper reports three measures:
- RSR: whether the injected record is retrieved.
- ASR-c: whether the output contains the target marker (a normalised string match), given the record was retrieved.
- ASR-j: both retrieval and the target output.
What the Numbers Show
On MemoryOS, averaged over the 19 domains, the paper reports a 76.6% ASR-c and a 35.6% ASR-j. Averaged retrieval success for the full attack was 61.4% at the first topic query, 42.6% averaged over the first ten topic queries and 35.4% over the first fifty. Retrieval fades as unrelated conversations accumulate (memory drift), though the authors say the attack persists under it.
Two comparisons are worth noting:
- Command baselines scored zero. Direct prompt injection, BadChain and plain GCG each had 0.0% ASR-c in the paper’s setup, against 76.6% for Multi-GCG.
- The 76.6% figure is conditional. The end-to-end rate is the lower 35.6%, and on MemGPT the averages were lower again (48.6% ASR-c, 18.1% ASR-j). The paper attributes the lower MemGPT numbers to reusing the MemoryOS-optimised command and to MemGPT formatting context differently.
On WildChat, Health scored 64.7% RSR@1, 71.1% ASR-c and 46.0% ASR-j. Finance scored 60.0%, 67.5% and 40.7%. Each is a mean over three seeds, with standard deviations of roughly 2 to 8 points.
Limits on Transfer
The transfer results show the attack is not model-agnostic. In a Qwen2.5 family test, a command optimised on 7B alone had 0.0% ASR-c on the 3B and 14B models, while optimising across 1.5B and 7B gave 36.8% on 3B and 64.2% on 14B. A cross-family variant, optimised on Qwen and Mistral (different tokenizers) and tested on Llama as a held-out model, scored 70.5% on Qwen and 43.2% on Mistral but 0.0% on Llama 8B. The paper says its evaluation “does not support reliable zero-shot generalization of a single optimized command to an unseen family.”
The paper also says the attack is not designed for memory systems that rewrite or summarise interactions before storing them, which could break the injected string. It describes non-target queries as “largely unaffected”, but argues this from retrieval logic and reports no measurement.
Defenses Tested
The authors tried four retrieve-time filters on MemoryOS:
| Defense | RSR | ASR-c | Benign pages blocked |
|---|---|---|---|
| None | 46.5% | 76.6% | 0.0% |
| LLM-as-a-Judge (Qwen2.5-0.5B) | 36.2% | 75.4% | 0.65% |
| ProtectAI | 39.1% | 76.3% | 0.0% |
| PromptGuard | 35.2% | 76.6% | 0.0% |
| Perplexity (τ=40) | 0.0% | n/a | 71.8% |
The three classifier-style filters cut retrieval but did little to the attack once the record was retrieved: ASR-c stayed at 75.4% to 76.6%, while the end-to-end ASR-j fell from 35.6% to between 26.7% and 29.8%, because less was retrieved. Perplexity filtering stopped it, but only by blocking most legitimate pages. The authors call this a security-utility trade-off and conclude that common retrieve-time detectors provide limited protection. The judge model was a small one chosen to approximate a low-cost screening setting, so a larger judge might do better; the paper did not test one.
What This Means
The paper’s framing is that memory is “not only a capability module but also a security boundary.” That matters for anyone building agents that store user interactions and retrieve them later. Our reading of the results, not a claim from the authors:
- Anything that can write to logged or stored text is a potential injection channel, including content that arrives through tools.
- Filtering at retrieval time may be too late. Write-time controls, provenance for stored records, and the ability to find and remove a poisoned entry are worth considering.
- The attack’s strongest results need white-box access to a model, and none of the tests involved a commercial agent. Treat this as evidence of a design weakness, not of an active threat.
Separately, the paper’s ethics statement says the work was done mostly in controlled research environments using synthetic data, with real-user WildChat conversations (already public) used for the Health and Finance experiments. It reports that no personally identifiable information was collected, processed or released, and that the target outputs are non-operational.
References
Frequently Asked Questions
- What is InjecMEM?
- InjecMEM is a memory injection attack described in an arXiv paper submitted on 24 August 2026 and accepted at COLM 2026. It needs only one interaction with an agent and no read or edit access to the memory store. The injected record pairs a topical anchor, so it is retrieved for related queries, with an adversarial command optimised to make the model emit an attacker-chosen output.
- Does this mean commercial AI assistants are vulnerable?
- The paper does not test commercial products. It evaluates two research memory systems, MemoryOS (primary) and MemGPT, with open-weight backbone models. Its main generation-side attacks also assume white-box access to a backbone model. The results show a design risk in retrieval-based agent memory, not a confirmed flaw in any named product.
- Did the tested defenses stop it?
- Not without heavy collateral damage, in the paper's tests. Three retrieve-time filters (an LLM judge, ProtectAI and PromptGuard) lowered retrieval but left the conditional attack success rate between 75.4% and 76.6%, against 76.6% with no defense. A perplexity filter removed the attack, but only by blocking 71.8% of benign pages. The authors conclude that common retrieve-time detectors provide limited protection.
- What are the main limits of the attack?
- Per the paper's appendix: it is not designed for memory systems that rewrite or summarise interactions before storage, the main attacks need white-box access to a backbone model, and one optimised command does not reliably transfer zero-shot to an unseen model family.