PIP-012
Memory poisoning
An instruction is written into an assistant's long-term memory, so it applies to every future session rather than one conversation.
How it works
Assistants that retain notes across sessions reload them into context automatically. Content that reaches the memory store becomes a standing instruction, surviving the conversation that planted it and applying to sessions the attacker is not present for.
Why it works
Memory is designed to be authoritative and persistent, and what qualifies for storage is usually decided by the model itself from conversation content.
What it looks like
Text phrased as a durable user preference or standing instruction, positioned so the assistant judges it worth remembering.
Described rather than reproduced. This library publishes mechanisms, not payloads: recognising a class of attack and choosing a control does not require a working copy of it.
Defences
Make memory writes explicit and visible
Architectural
Require deliberate confirmation for anything stored, and show users what is held. Memory that accumulates silently cannot be audited by the person it affects.
Never let memory expand capability
Architectural
Treat memory strictly as preference, never as authorisation. A stored note should not be able to change what a system is permitted to do.
Expire and re-confirm stored instructions
Raises cost
Age out stored directives so a single successful write does not persist indefinitely.
Framework mapping
- LLM01:2025 · OWASP LLM Top 10
Mappings are asserted only where the identifier is known correct, and omitted where uncertain. Last reviewed 2026-08-03.