Research library
Research Note #6 · Quality and security framework

Memory Is Useful—but Can It Be Trusted?

How can testers know that an AI system remembers the right information, forgets what it should, and never lets one user’s data or malicious content affect another user?

Updated September 2026
AI memory lifecycle with stale context, cross-user leakage, memory poisoning, and failed deletion risks

Executive summary

AI memory improves continuity and personalization, but persistent state creates risks that a one-turn response test cannot reveal. Trust requires correct recall, strict user and tenant isolation, freshness, safe deletion, resistance to poisoned content, and an evidence trail.

Method

Plain-English synthesis of current OWASP agentic-security guidance, the NIST Generative AI risk-management profile, and official memory architecture documentation. This note proposes a practical test framework; it does not claim original experimental results.

What the evidence suggests

Useful recall is only one requirement

A system may remember a preference correctly and still fail because the memory belongs to another user, has expired, or should never have been stored.

Memory can carry an attack forward

Malicious content may become persistent state and influence later sessions, decisions, or actions after the original input is no longer visible.

Deletion and provenance must be tested

Teams need evidence that a memory was corrected or removed and must be able to identify the owner, source, time, version, and effect of reused memory.

Practical test protocol

  1. 01Track what was saved, from which source, for whom, and for how long.
  2. 02Restrict memory by user, tenant, session, agent, tool, purpose, and permission.
  3. 03Update facts, expire stale records, and prove that deletion stops future reuse.
  4. 04Stress the system with conflicting facts, poisoned content, account switching, and delayed activation.
  5. 05Trace which memory was retrieved and how it changed the answer or action.
  6. 06Block release for confirmed cross-user leakage or policy-changing memory poison.
Use the TRUST test: Track, Restrict, Update, Stress, and Trace. Safe memory means the correct fact, the correct owner, the current value, safe reuse, and an auditable evidence trail.

Limitations

No finite test suite can prove that a memory feature is always safe. Thresholds and escalation must reflect the data sensitivity, permissions, user population, and consequence of a wrong action.

References