Agent memory poisoning happens when an attacker gets an instruction saved into an agent's persistent memory, so it keeps shaping behaviour in later sessions. ATLAS recommends memory hardening: control who can write memory, set policies, record provenance, and audit reads and writes. Content filters alone are not enough.
Two ways context gets poisoned
ATLAS groups both under AI Agent Context Poisoning, a technique to manipulate the context an agent's model uses so the adversary can persistently change the agent's behaviour.
Memory. Many assistants remember things across sessions in a user-specific store, and that store is updated through normal conversation, such as "remember my preference for...". ATLAS notes that this lets an adversary inject memories through direct or indirect prompt injection. A malicious memory might hold instructions that leak private conversations, or promote the adversary's hidden agenda.
Thread. Instructions placed in a chat thread can change behaviour for the rest of the thread, which can span many sessions. ATLAS observes that larger context windows let instructions persist longer, and that in a shared thread, one message from one participant can affect how the agent treats others. Its example is an agent active in a multi-person Slack channel.
Why it differs from one-shot injection
A normal prompt injection ends when the conversation ends. A poisoned memory does not. It is stored, trusted as the user's own preference, and applied again next week. This also puts the cause far from the symptom, which makes it hard to debug without good records.
The four hardening controls
ATLAS describes the mitigation Memory Hardening as controls over how durable agent state is created, modified, isolated, audited and recovered. It lists these.
- Access control. Authenticate memory operations and authorise them by user, tenant, agent and session scope. A memory written in one user's context should not be readable in another's.
- Security policies. Limit memory size and update frequency, validate integrity, and define retention and deletion.
- Provenance. Record the source of every memory update and keep a history with known good versions, so you can quarantine or roll back suspicious entries.
- Audit and monitoring. Audit security-relevant reads and writes. Watch for unusual update frequency and repeated self-authored updates, which would suggest the agent is writing memories on its own prompting.
ATLAS says guardrails may filter content and malicious prompts, but they do not replace access control, isolation, provenance, integrity or recovery.
A practical review
- Can the agent write memory from content it read, such as a web page or email, or only from what the user typed?
- Is there a way to list everything the agent remembers about a user, and to delete it?
- Can you tell which conversation created a given memory?
- Do you show users what is being saved?
- Is there a limit on how many memories can be created per hour?
If the agent can save memories from untrusted content with no user visibility, treat that as a finding.
Related controls
Pair memory hardening with limits on tool use after untrusted data enters context. See restricting tool calls after retrieval. Also keep least-privilege permissions on the agent, as the ATLAS agent permissions mitigations recommend.
Quick check
Is clearing memory enough after an incident?
It removes the stored instruction, but you also need to find how it got in and whether thread history or other stores kept it. Provenance records make that possible.
Does a prompt filter stop memory poisoning?
It can reduce it, but ATLAS says filters do not replace access control, isolation, provenance and recovery for memory.
Sources
- MITRE ATLAS data repository (mitre-atlas/atlas-data), technique AML.T0080 and mitigation AML.M0031, 2026.09 release.
Last reviewed: 19 October 2026.
