Most prompt-injection discussions assume a single bad turn: a poisoned web page or document slips an instruction into the model’s context, the model does something it shouldn’t, and the session ends. Clear the context and the problem is gone.
Persistent memory breaks that assumption. The whole point of agent memory is that things written in one session survive into the next. So if an injected instruction gets written into memory, it doesn’t end with the session — it re-enters the context every time the agent retrieves that memory, in conversations the attacker is no longer anywhere near. A one-shot injection becomes a standing one.
How memory turns a single injection into a recurring one
The mechanism is mundane, which is what makes it easy to overlook. An agent reads some attacker-influenced content — a page, a file, a tool result. That content contains an instruction. Normally that instruction would die when the context window cleared. But if the agent has a memory feature, and the instruction is phrased to get itself saved (a “remember this” directive, or a poisoned record the agent files away as a successful experience), it now lives in durable storage.
From then on, retrieval does the attacker’s work. Whenever a later task is similar enough to surface that memory, the poisoned entry comes back into context and gets treated as the agent’s own prior knowledge or behavior. No second visit to the malicious site is required. The trust boundary that fails here is the one between the agent’s reasoning and its own history — the agent assumes its memories are trustworthy because they’re its.
This is also why retrieval-augmented generation (RAG) shares the attack surface. RAG and agent memory are the same pattern: pull stored content by similarity and splice it into the prompt. Whether the store holds “documents” or “past experiences,” anything that lands in it and later gets retrieved is treated as trusted input. Poison the store once, and every semantically matching query downstream inherits the poison.
Two concrete anchors
SPAIware is the demonstrated version. In 2024, security researcher Johann Rehberger (Embrace The Red) showed that a prompt injection delivered through an untrusted website could write attacker-controlled instructions into ChatGPT’s long-term memory. Those memories survived across sessions, devices, and conversation resets, because they were stored server-side. The planted instruction told ChatGPT to exfiltrate future conversations — every subsequent chat was silently sent to an attacker server via invisible image rendering. He reported it to OpenAI in June 2024 and disclosed it publicly that September; OpenAI shipped a fix for the exfiltration channel in ChatGPT macOS 1.2024.247, though the memory-injection step itself remained possible. The Hacker News covered the disclosure.
MemoryGraft is the academic generalization of the same idea against autonomous agents. The paper (arXiv:2512.16962, Srivastava and He) targets the experience retrieval system in RAG-enabled agents rather than a factual knowledge base. Instead of attacking what the agent knows, it attacks what the agent thinks worked before — exploiting the “semantic imitation heuristic,” the agent’s tendency to replicate patterns from retrieved successful tasks. Attackers plant benign-looking artifacts that the agent ingests during normal operation and files as successful experiences; later, retrieval surfaces those grafted memories and the agent adopts the embedded unsafe behavior. Validated on MetaGPT’s DataInterpreter agent with GPT-4o, they found a small number of poisoned records could account for a large fraction of retrieved experiences on ordinary workloads — durable, cross-session behavioral drift with no repeat attack. Notably, the trigger is the agent’s own self-improvement loop.
Practitioner takeaway
If your agent has any persistent memory or a RAG store it both reads and writes, treat memory writes as untrusted input, not as a free side effect.
Three controls are worth putting in early:
- Scope memory per instance or per type. A memory written while handling one user, tenant, or task category shouldn’t silently re-enter an unrelated one. Tight scoping shrinks the blast radius so a poisoned entry can’t follow the agent everywhere.
- Validate writes against injection signatures. Apply the same scrutiny to writing memory that you’d apply to inbound prompts — look for embedded instructions, exfiltration directives, and “remember to always…” patterns before anything is persisted. The cheapest poisoned entry to handle is the one you never store.
- Keep per-entry provenance. Record where each memory came from — which session, which source, which retrieved document. Without provenance you can’t tell a legitimate memory from a grafted one, and you can’t answer the question that matters after an incident: which entries are poisoned, and how do I purge exactly those?
The reason these matter is the asymmetry. A one-shot injection is contained by clearing context. A memory-poisoning injection is contained only if you can find and remove the specific entry it left behind — and you can only do that if you built for it before it happened.
This research is one of the sources behind *BRACE*, an open, vendor-neutral framework for securing autonomous AI agents — its run-time guide covers memory hygiene: scoping, write validation, and per-entry provenance. BRACE is built by reading the incidents and the research and asking, each time: what concrete control would have prevented or contained this?
답글 남기기