InjecMEM: One Prompt Turns Agent Memory Into a Persistent Backdoor

One prompt. That’s all it took in the new InjecMEM research.

Researchers from Shanghai Jiao Tong University and Ant Group posted the paper on arXiv on 24 August 2026. By the next day CSO Online had picked it up. The finding is uncomfortable: an attacker can plant instructions that stick in an agent’s memory and keep influencing later answers on related topics. No special access required. Just a normal interaction that gets stored.

This is different from the prompt injection we have been talking about for years. Those attacks usually die when the session ends. This one does not.

How the attack is built

Classic prompt injection hits the model in the moment. InjecMEM goes after the memory layer that agents use for continuity and personalization.

The payload has two pieces. First, a retriever-agnostic anchor packed with topical cues that make the memory system more likely to pull the record later when someone asks about the same subject. Second, a short adversarial command. That command is optimized so that once the poisoned record shows up in context, the model produces the attacker’s chosen output.

They trained the command with gradient-based coordinate search, averaging across different templates and insertion spots so it still works when the memory system mixes records or drops the entry into a long prompt. They also tried joint optimization across backbones to see how well it transfers.

The whole thing is designed to need only one shot. No privileges, no multi-turn grooming, no direct write to the store. The agent’s own memory handling does the rest.

The numbers

On MemoryOS the attack hit a retrieval success rate of 35.4 percent at best and a conditional attack success rate of 76.6 percent. Joint end-to-end success sat at 35.6 percent. The usual baselines (DPI, BadChain, plain GCG) went to zero. They simply could not handle the retrieval-then-generate path and the variable placement that real memory systems introduce.

MemGPT was not immune either. Conditional ASR fell to 48.6 percent and joint success to 18.1 percent, but that is still a long way from safe. The attack kept working after more normal interactions had been written into memory, and it mostly left unrelated queries alone.

They also tested on real-user style data from WildChat (health and finance). Conditional rates there landed between 67 and 71 percent. Transfer worked better inside the Qwen2.5 family than across families, unless they optimized across multiple models at once.

The authors’ conclusion is blunt: memory is not just a feature. It is a security boundary.

Why the usual defenses do not stop it

Input and output filters are built for the current turn. InjecMEM writes the payload as a normal memory record. Once it is in the store it can look ordinary. When retrieval pulls it later, the system treats it as trusted history.

They tried several retrieve-time filters. LLM-as-a-judge, ProtectAI, and PromptGuard brought retrieval success down into the mid-30s, but the conditional attack success rate stayed above 75 percent. Perplexity filtering hurt the attack more, yet it also blocked a lot of legitimate content. Classic trade-off.

Stateless gateways that only watch the request between agent and model never see this. Provider-hosted memory, vector stores, local files like AGENTS.md or MEMORY.md are all outside their view. The poison can outlive the original tool that helped plant it.

Most of our current tooling still assumes the main risk is a malicious prompt reaching the model right now. When the risk lives in durable state the agent manages itself, those tools are incomplete by design.

What this means for the people building these systems

Every memory write is now a potential security event. It is not enough to ask what the model is allowed to say. You also have to ask who is allowed to write to long-term memory, what validation happens before something is stored, and how you will find and remove a poisoned record later.

A few practical moves:

• Put clear source attribution on every memory entry. Anything that came from untrusted input or external tools should carry a risk label that changes how (or whether) it gets retrieved.
• Keep high-value namespaces isolated. User personalization memory should not freely mix with shared organizational knowledge.
• Run periodic checks for strange topical clustering or sudden shifts in retrieval behavior on sensitive subjects.
• Stack imperfect filters at retrieval time with write-rate limits and human review for high-impact topics. None of them are perfect, but together they raise the cost.
• Treat memory stores with the same seriousness you already apply to credential or PII databases.

One more observation from the paper that makes detection harder: non-target queries stay mostly clean. If your monitoring only looks for spikes in refusals or toxic output, you will miss topic-conditioned influence that never sets off those alarms.

The same window also brought the context-leakage work showing that secrets sitting in the context window can still shape ordinary outputs even when the model correctly refuses direct extraction. Memory poisoning gives an attacker a second, longer-lived channel for the same class of problem.

Where this sits in the bigger picture

Memory is only one place where state outlives a single turn. Tool results, RAG corpora, multi-agent message buses all create the same kind of durability. Any channel the agent treats as trusted history becomes an attack surface the moment an adversary can write to it once.

Tools like Tencent’s AI-Infra-Guard already have modules aimed at agent workflows and skills. Model-level work such as Meta’s SecAlign family shows you can strengthen instruction hierarchy without destroying utility. Neither solves persistent memory poisoning by itself. You need the combination: better model behavior, hardened memory subsystems, continuous red teaming, and actual operational policy.

If you already run agent fleets, the immediate exercise is simple. List every path that writes durable state. Then ask three questions of each one:

1. Can an untrusted party influence this store with a single interaction?
2. Is provenance recorded?
3. What detection or purge mechanism exists if you later discover poisoning?

Closing note

InjecMEM is research, not an active campaign. The authors are careful about that. They present it as a framework for studying agent memory security and released code so others can test against it. That is useful. Defenders need concrete, reproducible attacks more than another abstract threat model.

The mental model that treats prompt injection as a session-scoped problem is no longer enough. Agents with longer memory and more autonomy expand the attack surface in time as well as in space. Inventory the durable state. Assume a single adversarial interaction can influence it. Build the controls from there.

Paper: arXiv:2608.23471. Code is public. CSO covered it the same day the research dropped.