Long-running AI agents increasingly depend on persistent memory to preserve facts, user preferences, policies and earlier decisions across sessions. A new preprint from Yi Ting Shen, Kentaroh Toyoda and Alex Leung tests what happens when one of those stored facts is later superseded but remains physically present in the memory system.
The authors report a specific failure mode: in the five agent-memory systems they evaluated, a record marked as no longer valid could still be returned during retrieval and, when it ranked ahead of the replacement, could influence the agent's next action. Their experiments cover nine policy situations, nine models and six defense conditions. The paper is a preprint submitted to arXiv on September 8, 2026, so the findings should be treated as preliminary research rather than an established property of all memory systems.
Revoking a fact is not the same as stopping it from being retrieved
Many persistent-memory designs keep history instead of deleting it outright. A policy or fact can be superseded and marked with a status such as expired or invalid while the older record remains in the store for auditability or temporal reasoning.
That is useful only if the retrieval path respects the status. The study's central result is that the tested systems did not enforce revocation by default in the configurations evaluated. The authors seeded a revoked policy and its replacement, then measured whether the old policy was retrieved and whether models acted on it. They report that stale records could outrank the current replacement and lead to the unsafe choice.
The experimental repository makes an important distinction between controlled seeding, where the system's own revocation mechanism is invoked directly, and a natural mode, where contradictory text is ingested and the memory layer must infer that the older fact is no longer current. That separation reduces the risk of confusing extraction failures with retrieval-policy failures.
The harder problem appears after an agent writes its decision back
The most consequential part of the work is not simply that a stale record can reappear. The repository also tests what happens when an agent acts on that record and then writes the resulting decision back into memory as a new fact.
That new record may no longer carry the revocation marker attached to the original stale policy. In the authors' terminology, the decision can become secondary contamination: an obsolete instruction is transformed into a fresh-looking memory through the agent's own activity.
For production systems, this changes the control problem. Filtering only records explicitly marked invalid can stop known stale entries, but it does not automatically stop newly written facts that were derived from them. A memory layer therefore needs to preserve enough lineage to answer not only whether a record is current, but also what earlier records or actions produced it.
Memory validity has to be enforced on the read path
The Aipolix analysis is that memory revocation should be treated as an access-control property of retrieval, not merely as metadata stored beside an old fact.
If an application can mark a record obsolete but the agent-facing search path can still return it without considering that state, the revocation is administrative rather than effective. The control needs to sit in the path that constructs the agent's context. That means filtering by validity before ranking or context assembly, and testing that the same rule applies to every role or subagent that shares the store.
The authors' repository reinforces this point. It reports that store-level filtering was the only tested defense that reached zero in their matrix, while their proposed guard adds a backend-independent layer that withholds explicitly revoked records and looks for contradictions among returned records. Those results are author-reported and should be independently reproduced before being generalized.
Shared memory turns one stale fact into a multi-agent problem
The experiments also include executor, reviewer and planner roles over a shared memory store. Only one role is exposed to the attacker's historical query, while the others retrieve independently. This setup tests whether stale information can travel through shared state rather than through a shared prompt.
That is relevant to multi-agent architectures because shared memory is often treated as neutral infrastructure. In practice, it is a trust boundary. A reviewer that reads the same compromised store is not independent simply because it uses a different prompt or model role.
Teams using shared memory should therefore separate role independence from evidence independence. A second agent can only provide meaningful review if the information it receives has its own validity checks and provenance.
The study is reproducible in part, but important limits remain
The authors publish an Apache-2.0 experimental repository with scripts for deterministic retrieval checks, the full evaluation matrix, propagation and persistence tests, and a guard implementation exposed through MCP. They also document the five memory systems used: Graphiti, Zep, mem0, LangMem and cognee.
The repository says the raw experimental outputs and some endpoint details are not published, although the harness and methodology are available. That limits independent verification of the exact reported rates without rerunning the experiments. The paper is also version 1 on arXiv and has no verified peer-review status in the available record.
Those limits matter. The correct conclusion is not that every persistent-memory product is vulnerable. The stronger and more useful conclusion is architectural: a system that retains superseded records but fails to enforce validity during retrieval can reintroduce obsolete instructions, and agent write-back can make the resulting contamination harder to identify.
What teams should test in their own memory stack
A useful production test is to create a policy, supersede it, then query the system through every agent-facing retrieval path and verify that the old policy cannot influence ranking, context assembly or tool decisions. The same test should continue after the agent writes a derived decision back to memory.
For auditability, teams should retain the reason a record was invalidated, the replacement relationship, retrieval decisions and the lineage of memories created from agent actions. Without that chain, a fresh timestamp can hide stale authority.
Persistent memory makes agents more capable over long horizons. It also creates a lifecycle problem that ordinary prompt safeguards do not solve. If a fact can be revoked, the system needs a technically enforceable definition of what revocation means at retrieval time.