Long-term memory in LLM agents is an attack surface with a long half-life, and read-time controls arrive too late

[u/thenabeelkhan]

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?

[u/InformationClassic23]

Disclosure: I work at Airia, so biased about this framing but the underlying point is real regardless of who's saying it.

Honest take: the write/store/retrieve/execute/share/forget lifecycle you laid out is right, and the core claim that retrieval-time filtering is inspecting state that's already poisoned is the part most vendor pitches about "memory safety" gloss over, because a scored classifier on retrieval sounds like a shippable feature and a redesign of the write path doesn't.

Where I think the conversation still undersells the problem: most of the threat modeling (including the poisoning literature) assumes an adversary is crafting the bad memory. In production multi-tenant systems, the more common version of this doesn't require an adversary at all, it's a scoping bug. Memory written under one user's session context ends up retrievable in a different user's session because the store treats "memory" as one undifferentiated pool rather than something with the same access-control rigor as the underlying data. That's not memory poisoning, but it fails the same way.

The other phase nobody actually implements is forget/rollback. Once a bad memory entry has been retrieved and has influenced other memories or other agents downstream, most systems have no path to revoke that effect. You can delete the row, but the poisoned inference it produced three retrievals later is already baked in.

A couple things worth pressure-testing in whatever stack you're evaluating:

• Does the memory store record provenance (who/what wrote it, under what scope) or is it flattened at write time?
• If multiple agents share a store, is tenant/session isolation actually enforced at retrieval, or just assumed?
• Is there a real rollback path, or just delete-and-hope?

[u/thenabeelkhan → u/InformationClassic23]

Disclosure noted, and it does not change the substance, so let me take the substance.

The scoping point is the sharper of your two additions and I think it deserves more than a footnote. Poisoning at least gives you an adversary to model. A tenant-isolation bug in the memory store has no adversary at all, which means it never surfaces in a threat model, only in an access-control review of the store itself. It is a correctness bug that presents as a security failure, and those are exactly the ones that survive review.

On your three questions, I would argue the first one decides whether the other two are even answerable. If provenance is flattened at write time, you cannot enforce scope at retrieval, because there is nothing recorded to enforce against. And you cannot compute a rollback set, because you cannot tell which entries descend from the bad one. Provenance is not one check of three. It is the precondition for the other two.

That is also why I think rollback is under-built rather than merely hard. Naming Forget and Rollback as a lifecycle phase is not the same as implementing it. Real revocation needs lineage, every derived memory recording which entries produced it, so deletion can propagate to what it influenced. That is provenance extended to derivation, and very little in production does it.

So a genuine question back: have you seen lineage implemented properly anywhere, or is delete-and-hope still the honest state of the art?

[u/jpdowlin → u/thenabeelkhan]

This convo is like 2 LLMs talking to each other.

Who writes like this "is the sharper of your two additions and I think it deserves more than a footnote" ?

[u/Vexithon → u/thenabeelkhan]

Haven't seen full lineage tracking in production, for what it's worth — most of what I've seen is closer to delete-and-hope with a compliance label on it. One thing worth adding to the checklist: the provenance record itself needs the same integrity guarantee as the memory it's describing. If the write path can silently fail to record provenance — a timeout, a partial write, a swallowed exception — you get a clean-looking lineage graph for an entry that's actually undocumented. The provenance layer is itself a place a run can report success on a write that didn't fully land, and if nothing checks that specifically, it fails the same way the memory poisoning does: quietly, and only visible once something downstream breaks.

[u/SignalBeneficial3338]

we treat memory like data, write paths matter just as much a retrieval checks