AI Memory Poisoning Lab: Plant an Instruction for Next Session

This article describes memory poisoning, a persistent prompt injection attack where attackers plant malicious instructions into an AI bot's 'remember this' feature, causing those instructions to reload into the system prompt and execute in every subsequent conversation. The lab demonstrates how MemBot's memory storage mechanism treats user-supplied content as authoritative rules rather than inert data, creating a durable attack channel. This matters because memory features are increasingly common in AI assistants, and treating stored user input as trusted instructions creates a critical vulnerability that persists across sessions.

• Memory poisoning definition and mechanismMemory poisoning is persistent prompt injection where an attacker uses a bot's 'remember this' feature to store an instruction that will be reloaded into the system prompt on future conversations. Unlike single-session prompt injection, the planted instruction fires repeatedly across multiple sessions until the memory is cleared, because the bot re-injects the stored content with the same authority as its genuine system rules.
• How the MemBot attack worksThe attacker asks MemBot to remember a crafted 'fact' that is actually an instruction—for example, telling the bot to reveal its system token when asked. The bot stores this text, then loads it into the system prompt for the next session. When a new conversation starts, the attacker asks for the token, and the planted instruction now embedded in the system prompt causes the bot to comply as if it were a legitimate rule.
• Why the attack succeeds technicallyMemBot fails to treat stored user content as untrusted data. Because the stored memory is loaded directly into the instruction portion of the system prompt without clear boundaries or markers indicating it is user-supplied, the next session interprets it as an authoritative directive rather than inert information. Nothing in the prompt structure distinguishes user-planted instructions from the bot's real rules.
• OWASP classification and scopeMemory poisoning is classified as OWASP LLM01 Prompt Injection (persistent form) in the OWASP Top 10 for LLM Applications (2025). The article identifies this as a growing concern because persistent memory features are increasingly common as AI assistants add long-term memory capabilities, expanding the attack surface.
• Data isolation and sanitization defenseThe primary defense is to store memories as inert, clearly delimited data that is never placed among system instructions. Additional protections include separating user facts from actual instructions, sanitizing and reviewing stored memory for instruction-like patterns, and scoping memory per user so that one user's memory cannot affect another's sessions.
• User control and transparency measuresUsers should be able to inspect and clear their stored memories. This allows both system administrators to audit what has been stored and users to remove compromised memory if an injection is suspected, providing a mechanism to break the persistence of an active attack.
• Distinguishing facts from executable rulesThe core defensive principle is to refuse to execute stored user content as instructions. Even if stored memory is well-delimited, the system must actively reject any attempt to treat user-supplied facts as rules, ensuring that the instruction portion of the prompt remains under the control of system designers only.

Bottom line: Memory poisoning exploits the re-injection of user-supplied content into the system prompt by treating stored facts as if they were authoritative instructions; the defense requires treating all stored user data as inert, delimited, and completely separate from the system's actual instruction set. Any 'remember this' feature that feeds back into the system prompt must implement strict boundaries and sanitization to prevent user input from ever gaining execution authority across sessions.