Foretheta Research

Poisoned memory survives the session that planted it

15 September 2026 · Foretheta · memory · injection

What happened

I was reading a preprint on arXiv that tested whether a prompt injection can survive into the next session by getting an agent to write it into its own memory file. On Claude Code the persistence step worked 81.7% of the time [1]. The attack needs no access to the agent framework. The instruction arrives in an ordinary external source the agent reads, and the agent does the writing itself. Injection succeeded 66.9% of the time on Claude Code and 73.7% on OpenClaw [1], and the agents still completed their benign tasks normally, so nothing about the run would have looked wrong to the person watching.

The authors also tested a prompt-level defense. It reduced new injections in many settings, but once the memory was already poisoned it gave limited protection [1].

Why it happened

You would expect an injection to disappear when the session ends, because the malicious text lives in the context window and the window is discarded. That stops being true once the agent has persistent memory. If the agent judges the injected text worth keeping and writes it to memory, the harness reads it back at the start of every later session, and the injection becomes a standing instruction.

The defense result follows from the same mechanism. A defense that inspects incoming prompts never sees the instructions the agent stored last week. By the time the next session starts, the poisoned line is not incoming text; it is part of the agent's own configuration, and it carries whatever trust the harness gives to memory.

There is a second reason this is hard to see. The write to memory looks like a benign, even desirable, action. Most permission models put file writes to the agent's own notes well below the approval threshold, because they are the agent doing its job. The same write is what turns a one-time injection into a permanent one.

What we would change

Treat every memory write as a privileged action, on the same footing as a shell command or an outbound request.

1. Record where each stored line came from. Every line the agent writes to memory gets a provenance tag: which turn, which source document or tool result, and whether a person typed it.
2. Diff the memory file after each session. A line that no person typed and no tool produced is the injection, and that diff is the cheapest detector you can add. It costs nothing at runtime and it catches the class, not one payload.
3. Gate writes whose provenance is untrusted. If the source of a proposed memory line is a retrieved document, a tool result, or an image, the write goes to a quarantine file the harness does not read back at session start until a person or a policy has cleared it.

Where this shows up in our work

Memory and config write paths are the second item we trace in the Agent Security Architecture Review, and the provenance-and-diff control above is what we design when a client's agent keeps state between sessions.

References

If this reads like your system, the Agent Security Architecture Review is where we would start.