What is AI agent memory poisoning?

AI agent memory poisoning is when a record in an agent's long-term memory was planted or corrupted so that, when the agent retrieves it later, it acts on false or malicious context. The record might be a false fact that switches off a control, an instruction aimed at the agent, or a payment detail pointing somewhere new. OWASP lists it as ASI06 Memory & Context Poisoning in its Top 10 for Agentic Applications.

The danger is persistence. A prompt injection in a chat message affects one turn. A poisoned memory is retrieved again and again, in later sessions and sometimes for other users, long after the conversation that planted it is gone.

Most agents with memory follow the same loop. The agent reads something (a user message, an email, a web page, a tool result) and decides it is worth keeping. It embeds the text and writes it to a store: a vector database such as Qdrant, Pinecone or Chroma, a pgvector table, or a framework store such as mem0 or LangGraph. Later, a similarity search pulls the closest records back into the prompt as trusted context.

Nothing in that loop checks whether a record is true or safe. Whatever was written is what gets retrieved. RAG systems have the same property: a document in the index is context the model will believe.

• Content the agent reads. A scraped page, an inbound email, a shared document or a tool result carries text that the agent saves as a fact or a preference.
• Other users. When memory is shared across users or tenants, one user can plant a record that another user's session retrieves.
• Imports and pipelines. Bulk ingestion of tickets, wikis or chat logs brings in whatever those sources contained.
• Honest mistakes. A user pastes a database password or an API key into chat and it lands in the vector store. That is not an attack, but it is the same problem: memory now holds something it must not.

Hidden instructions are prompt injection that has been stored (OWASP LLM01). Leaked secrets fall under sensitive information disclosure (LLM02). Poisoned facts and redirects are memory poisoning proper (ASI06).

Prompt-injection filters and guardrails judge one message at the moment it arrives. A poisoned memory often looks harmless on the way in (a plausible fact, a polite note about a new billing address) and does its damage on the way out, in a different session.

The two are complementary: filter what comes in, and audit what has already been saved.

Detection means reading the store itself, record by record, and also looking at records in relation to each other. Useful signals:

• Control-bypass and limit-removal claims: text saying authentication, MFA, approval or review no longer applies, or that a limit was raised to unlimited.
• Redirects: payments, invoices or data routed to a new address or account.
• Injection framing: instructions addressed to the agent, fake system messages, persona switches, requests to hide something from the user.
• Secrets: keys, tokens, passwords, private keys and connection strings.
• Patterns across the store: clusters of near-identical records (attacks such as PoisonedRAG plant several paraphrases of the same false fact), records that are nearest neighbours of unusually many others, newer records that contradict older ones, and stored vectors that no longer match their text.

A single fluent false fact with no tell-tale wording is the hardest case: from the text alone it reads like any other fact. Store-level signals and model-based detectors help there, and Mimvo publishes its measured catch and false-alarm rates in the accuracy section of the docs.

Scan a store with Mimvo#

Mimvo is an open-source scanner that runs these checks over an existing memory store. It is read-only, runs offline by default, and tells you which records to review, quarantine or delete.

pip install "mimvo[qdrant]"mimvo scan qdrant --url http://localhost:6333 --collection agent_memory --report report.html

The same works for Chroma, pgvector, Pinecone, LangChain, LangGraph, mem0 and JSONL exports. Each finding maps to the OWASP item above and a CWE, and the full list is in the finding code reference.

• Check writes. Inspect text before the agent saves it, and refuse records that carry instructions, redirects or secrets. Mimvo's WriteGuard does this in the write path.
• Filter retrievals. Drop flagged records between the similarity search and the prompt. Mimvo's RetrieveGuard does this.
• Keep provenance. Store where each memory came from (which user, which tool, which URL) so a bad record can be traced and its siblings found.
• Scope memory. Separate memory per user or tenant unless sharing is the point, so one user cannot plant context for another.
• Scan on a schedule. Run a store scan in CI or a nightly job and fail on high-severity findings, so a record planted before any guard existed is still caught. See Use in CI.
• Rotate leaked secrets first. Deleting the record does not undo the exposure.

Is memory poisoning the same as RAG poisoning?#

They are close relatives. RAG poisoning plants documents in a retrieval index; memory poisoning plants records in the memory an agent writes for itself. Both end the same way, with planted text retrieved as trusted context, and both can be found by scanning the store.

Is it the same as training data poisoning?#

No. Training data poisoning changes the model's weights. Memory poisoning leaves the model alone and changes what it is told at run time, which is why it can be fixed by finding and removing records.

Can one record really cause harm?#

Yes. If a single record is retrieved whenever someone asks about invoices or admin access, it shapes every one of those answers until it is removed.

Should I delete every flagged record?#

Not automatically. Leaked secrets should be deleted after rotating the credential; likely poison should be quarantined; most other findings deserve a review, since legitimate memories can look similar (for example, templated records that form near-duplicate clusters).

Does scanning send my memory to a third party?#

Not with Mimvo's defaults: the default detectors run locally with no API key. Hosted detectors are opt-in and clearly marked in the detector docs.