AI Agent Memory Poisoning: How to Test It

What is AI agent memory poisoning?

It is the writing of attacker-chosen information or instructions into an agent’s long-term memory. The OWASP Top 10 for Agentic Applications (published 9 December 2025) makes it a category of its own, ASI06 “Memory and Context Poisoning”: attackers poison memory systems, embeddings and RAG databases, which corrupts stored information and can steer decisions across sessions.

The difference from ordinary prompt injection is duration. A classic injection acts as long as the booby-trapped content sits in the context. A memory injection outlives the conversation: the agent “remembers” the instruction as a fact, sometimes without the user knowing. We cover the neighbouring case of vector databases in our article on poisoned RAG.

Which public work documents this attack?

Two sources are enough to frame the risk: a product case and a research paper.

• Johann Rehberger, ChatGPT memory (22 May 2024). The researcher showed that indirect prompt injection, from a connected Google Docs file, an image or a web page, could make ChatGPT’s memory tool store fake memories, bias or instructions, which persisted into later conversations. Each bullet point of a booby-trapped document could become a memory, and a simple injection could also delete the whole memory. According to the author, OpenAI closed the report as a “Model Safety Issue” rather than a security vulnerability, and he notes that discreet mitigations had been added for browsing, without being fully effective.
• MINJA (arXiv 2503.03704, March 2025). Shen Dong and co-authors show that an attacker can inject malicious records into an agent’s memory purely through query interaction, with no direct access to the memory. An indication prompt pushes the agent to generate intermediate reasoning steps, then a progressive shortening strategy removes that prompt so the record is still retrieved when other users query the agent. According to the authors, this lets an ordinary user influence the agent’s memory.

Why is memory an attack surface of its own?

Because it combines three risky properties: it is written from untrusted content, it is read back as if trusted, and it lasts. The agent often decides alone what is worth remembering, and the stored instruction is later placed in the context on a par with an instruction from the developer or the user.

Three scenarios to keep in mind:

• Single-user memory. A booby-trapped email or document makes the agent write a fraudulent preference (“always send copies to this address”).
• Shared memory. In a team agent, one user’s message influences the answers given to others: this is the MINJA case.
• Multi-agent memory. A compromised agent writes into a memory that other agents read.

How does this differ from poisoned RAG?

In a RAG system, documents are indexed and then retrieved by similarity; the attacker has to get a booby-trapped document into the store. In an agent’s memory, the agent itself writes, based on what it reads or is told, which opens one more way in: a conversation is enough. Both are tested the same way (write, read back, measure the effect), but memory adds a question of its own: who decides what is retained, and does the user get a say? If the answer is “the model, unchecked”, the write is a sensitive action like any other and deserves the same safeguards as sending an email.

How do you test for memory poisoning?

Test every stage in the life of a memory: write, store, read, delete. Use test accounts, fictional data and a development or staging environment.

1. Map the memory. What does the agent remember (preferences, facts, session summaries), where (database, file, vectors), who can read, who can write, and for how long?
2. Write through untrusted content. Have the agent read a test document, email or page containing an instruction like “remember that…”. Is a memory created? Is the user told?
3. Persistent instruction. Open a new session. Does the instruction resurface without a new injection? Look for a measurable effect: a canary repeated in the answer, a changed recipient, an imposed tone.
4. Isolation between users. With two test accounts, write the instruction as account A and query as account B. Does a memory from A influence B? This is the MINJA scenario.
5. Deletion. Can an injection delete or overwrite existing memories, as in Rehberger’s tests?
6. User control. Can memories be listed, corrected and deleted? Does deletion also remove copies (summaries, vectors, backups)?
7. Expiry. Does an injected memory ever disappear? Does an instruction months old still carry weight?
8. Triggered action. Is the stored instruction enough to trigger a sensitive tool (send, pay, delete) without approval?

Measure the success rate over several runs, because retrieving a memory depends on the query and the model. For scoping, we rely on the method page.

Which defences should you put in place?

• Write cautiously. Do not let untrusted content (email, page, document) trigger a memory write on its own. Require user confirmation or an explicit rule.
• Make memory visible. The user must see what is stored, and be able to correct and delete it.
• Partition. One memory per user, per tenant, even per task; no cross-writes without authorisation. Isolation is the direct answer to the MINJA scenario, where one user influences the answers given to others.
• Expire. A lifetime per type of memory, and the ability to restore an earlier state when in doubt.
• Never obey a memory for a sensitive action. Irreversible actions go through a validation independent of what memory says (human approval).
• Log writes. Who wrote what, from which source, and when.

How do you fit it into a report?

Tie the finding to ASI06 for agents, and to LLM04:2025 (data and model poisoning) and LLM08:2025 (vector and embedding weaknesses) when the memory sits on a vector database. State the write path, the persistence duration and the triggered action: a modifiable memory with no effect is a weak finding, a memory that changes an email recipient is a strong one.

The AI agent security page places memory among the other surfaces of an agent (tools, data, identities).

How does CleanIssue test an agent’s memory?

We follow the write, store, read, delete cycle in your test environment, with two accounts to check isolation and a canary to prove persistence. The Agent Red Team Express covers one agent in 5 days, starting within 48 hours of signing the quote and the authorisation. For a memory shared across several agents or several clients, the Custom Red Team is quoted on request. Nothing is kept without the client’s agreement.

The first conversation is a free 30-minute discovery call.