Quick answer: Agent memory poisoning is the permanent distortion of a long term memory AI agent's later decisions by placing a malicious record into its memory. The agent keeps a memory store to remember past interactions and trusts this memory in every new decision. If an attacker can slip a fake instruction or a false fact into this memory, the agent reads that poisoned record as a legitimate memory and produces the bad decision again and again. Unlike a one off prompt injection, this is persistent. DSET tests this flaw with its local AI engine KAOS and verifies every finding with a working proof.

Modern AI agents do not just answer a single question, they learn and remember over time. A customer assistant stores previous conversations, a personal agent the user's preferences, a workflow agent its past decisions in a memory. This memory makes the agent smarter, but it also creates a persistent attack target. Once a malicious record enters the memory, it poisons every decision the agent makes until it is deleted. This article explains what agent memory poisoning is, which scenarios it causes and the DSET and KAOS approach.

What memory poisoning is and how it differs from RAG

Memory poisoning is often confused with classic database attacks, but the difference matters. In a RAG system the model pulls relevant documents from a knowledge base to produce its answer, and for its security the topic of RAG and vector database security applies. Agent memory is a different thing: it is a persistent notebook where the agent stores its own past decisions, observations and user preferences. RAG brings in information from outside, while agent memory carries the agent's own internal state. When poisoning enters this internal state, the agent now accepts a false fact as its own memory, and this is far more insidious.

Which scenarios it causes

How the poisoned record enters and where it spreads determines the impact of the attack.

Poisoning path How it works Typical result
Direct memory injection A fake memory is written through user interaction The agent permanently makes the wrong decision
Cross session leakage Poison in one session carries into the next session The attack stops being one off
Cross user contamination Shared memory leaks from one user to another One user's poison affects another
Planting a false fact False information is stored as a memory The agent acts on wrong data
Instruction hiding A hidden command to trigger in the future is stored Delayed, timed malicious behavior

The essence of the table is this: in memory poisoning the danger is persistent rather than momentary, because poison that once enters the memory takes effect again in every later interaction. The cross user contamination scenario is especially critical; if poison one user puts into the memory affects another user's session, this shows that the same isolation principle as RAG customer isolation and privilege revocation is also needed in agent memory.

Why session and user isolation is critical

In a multi user agent system the most dangerous scenario is poison entering one user's memory leaking into another user's session. If agent memory is not strictly separated per user, an attacker inserts a record into the memory through their own session and that record steers the agent while serving another user. For this reason when agent memory is designed it must be tracked which user, which session and which trust level each record belongs to, and these boundaries must be enforced when reading from memory. Besides isolation, the trustworthiness of the source of every record written to memory must also be evaluated.

Its relation to data integrity and poisoning

Agent memory poisoning is the agentic systems face of a broader data integrity problem. Just as inserting a malicious sample into a model's training data corrupts the model, inserting a malicious record into an agent's memory corrupts the agent; for this parallel the topic of AI data poisoning and model security is illuminating. In addition, if an agent that trusts a poisoned memory acts with broad privileges the risk multiplies, which intersects with the topic of excessive agency in LLM agents.

The KAOS and DSET approach

DSET tests agent memory poisoning as part of the broader AI and LLM application penetration testing service, with its local AI engine KAOS. KAOS tries to insert a controlled poisoned record into the agent's memory, checks whether this record affects later decisions and tests whether isolation across sessions and users is actually enforced. It reports every flaw it finds with a working proof, under the principle of proof based verification. The difference is this: it does not settle for saying the memory could theoretically be poisoned, it shows that the inserted poison actually distorts a later decision.

Frequently asked questions

Is memory poisoning the same thing as prompt injection? No, they are related but different. Prompt injection often affects a single interaction and its effect passes when the interaction ends. In memory poisoning the malicious instruction is written to the memory permanently and is read again in every later interaction. So prompt injection is a momentary attack and memory poisoning is a persistent one. Often the poison is inserted into the memory through a prompt injection.

If I clean the memory frequently is this flaw solved? Cleaning reduces the impact but is not the root solution. The real solution is to evaluate the source and trust level of every record written to memory, to enforce strict isolation per user and session, and to subject critical actions taken by trusting the memory to additional verification. Memory cleaning is added alongside these layers, not in their place.

Is this risk not an exaggeration for a small agent application? The risk is as large as the memory's privilege. If your agent acts based on its memory, for example approves a payment or sends data out, poisoning the memory directly distorts that action. What matters is not that the application is small but how much the agent trusts its memory and how powerful an action it takes.

Sources

To examine the memory security of your AI agents with a proof based test, contact DSET. We provide AI agent penetration testing and consulting from our Ankara Hacettepe Teknokent laboratory.