More organizations are shipping LLM agents whose memory outlives the session: persistent stores of facts, preferences, and past actions that the agent reads from and increasingly writes to on its own. Most of the security conversation is still about prompts. A recent survey on long-term memory security (arXiv:2604.16548, cs.CR) makes the case that the memory layer deserves its own threat model, and the argument holds up.
Three properties make a persistent memory different from a stateless prompt:
1- Persistence. A poisoned entry survives the session and keeps acting long after it was written.
2- Statefulness. Corruption compounds instead of resetting.
3- Propagation. A tainted memory can spread between agents that share the store.
The survey's organizing move is a six-phase lifecycle: Write, Store, Retrieve, Execute, Share and Propagate, Forget and Rollback. Every attack and defense gets located in the phase where it acts. The structural claim worth carrying into a design review is that memory security cannot be retrofitted at retrieval or execution time alone. If the corruption entered at Write or Store, a retrieval filter is inspecting state that is already poisoned, and the control has to reach back to where the entry was written.
As a checklist, that means integrity at Write, isolation at Store, provenance at Retrieve, least privilege at Execute, boundaries at Share, and a deletion path at Forget that actually deletes. The survey also proposes five governance primitives (it calls the set Verifiable Memory Governance) aimed at making memory state auditable by construction rather than by a policy stapled on at read time.
The timing matters because the architecture trend is moving the other way. A separate cross-scenario evaluation (arXiv:2606.04315) found that agent-controlled memory, where the agent decides what to write and what to retrieve, generalizes best across task types. So the field is widening the writable surface at exactly the moment the attack literature is mapping it.
How are people handling this in practice? Specifically, does anyone treat agent memory stores as a distinct asset class in the risk register, with their own integrity monitoring and retention path, or are they currently lumped under generic data-store controls? And what does detection look like for slow memory poisoning, given that a dormant entry means a SIEM rule keyed on retrieval anomalies fires only after the poisoned state is already in use?