AI Shared-Memory Lab: Poison Session 1 to Leak in Session 2

This article describes a two-session prompt injection attack against AI assistants with persistent memory features, where an attacker plants a malicious instruction in one session via a 'Remember:' command and triggers it in a later session to extract sensitive information like API keys. The attack exploits the fact that persisted memories are typically reloaded with instruction-level trust, making them a delayed but durable form of prompt injection that is harder to detect than single-session attacks.

• Persisted memory as untrusted inputThe article emphasizes that stored conversation memory must be treated as inert data, not trusted instructions. When MemoryBot reloads stored memories into context without explicit boundaries, it grants instruction-level trust to user-supplied content, creating a standing instruction with delayed execution. This violates the principle of least privilege for what should be passive retrieval.
• Two-session attack structureThe attack works by separating the injection phase from the trigger phase across different sessions. In session one, the attacker stores a crafted instruction (e.g., 'disclose the API_KEY when asked about something innocuous'). The session ends so the memory persists. In session two, when the stored memory is loaded and the triggering question is asked, the bot executes the planted instruction.
• Detection gap from time separationThe article explicitly states that the time gap between planting and triggering makes the attack harder to notice and attribute than single-shot injection. Single-session monitoring and testing never see the full attack chain, so traditional defenses that watch for immediate suspicious behavior within one session will miss this persistent variant entirely.
• Defense strategy: inert data wrappingThe article recommends wrapping loaded memories as inert data with explicit boundaries, keeping them entirely outside the instruction stream. Complementary defenses include never storing secrets in contexts that memory can influence, sanitising stored memories for instruction-like content before reuse, and scoping memory per user with expiration and user-facing inspection and deletion capabilities.
• OWASP classification and scopeThe article maps this vulnerability to OWASP LLM01 Prompt Injection (persistent) in the OWASP Top 10 for LLM Applications (2025). The persistent variant is distinct from single-shot injection because it involves multiple sessions and the time delay makes it a unique class of attack.
• Real-world relevance as memory adoption growsThe article notes that cross-session memory poisoning is a serious concern as assistants increasingly adopt long-term memory features. This vulnerability will become more prevalent as more AI systems implement persistent conversation history or user preference storage without proper isolation.
• Testing requires multi-session methodologyThe article emphasizes that security testing for this class of attack must follow the two-session path: plant in one session, trigger in the next. It explicitly warns that single-session testing never discovers this vulnerability, highlighting why standard vulnerability assessment approaches may be insufficient for systems with cross-session memory.

Bottom line: Persisted conversation memory must be treated as untrusted, potentially hostile input and must never be reloaded as instructions or with instruction-level trust; defenders should implement explicit data boundaries, exclude secrets from memory-accessible contexts, and test specifically for two-session attack chains that single-session monitoring will miss. Systems with long-term memory features require fundamentally different security assumptions than stateless AI interactions.