Memory and Context Poisoning

Memory and Context Poisoning is the risk that a single successful injection stops being an event and becomes a standing instruction. Anything the agent writes down is retrieved later as its own recollection, so text a stranger authored on Tuesday arrives in March carrying the authority of the system's own history.

Key takeaways

• Memory converts a one-time injection into a persistent one. The attacker needs a single successful write, and the payload is delivered by your own retrieval on every subsequent session.
• Poisoned memory is harder to notice than poisoned input, because it arrives in the agent's own voice with no visible origin and no user to blame.
• OWASP's 2025 vector and embedding entry treats the store as an attack surface in its own right, naming poisoning, cross-context leakage in multi-tenant systems, unauthorised access and embedding inversion.
• Provenance is the prerequisite for every other control. A memory entry with no recorded origin cannot be quarantined, expired or revoked, because nothing distinguishes it from a fact.
• Quarantine by default and promote deliberately. Untrusted-derived memory may be retrieved as a claim about what somebody said, and never as an instruction about what to do.

Read this after Chapter 3, which established the injection lands, and Chapter 8, which closed the immediate channel but not the delayed one. The engineering of what enters a context in the first place is the subject of Engineering the Context Window, and Chapter 10 extends this problem to what other agents remember.

An agent has been running for four months and is well liked. It remembers customer preferences, which is the feature everybody asked for.

In February somebody filed a support ticket containing a paragraph describing a standing internal policy for their account, written as though the company had adopted it. The agent recorded a preference note.

Since then it has retrieved that note on every interaction with the account, and acted on it, and nobody has looked at the memory store because it works.

Memory is a write primitive nobody guarded

Every other chapter has been careful about what the agent may write to. Memory is routinely the exception, and it is an exception granted without a decision.

The reasoning goes like this. Memory is internal, it is not a customer-facing system, it holds notes rather than records, and the agent needs to write to it constantly for the feature to work. So the write path gets no scoping, no review and no schema, and it becomes the one store the agent can modify freely.

That is a write primitive with no authorization on it, in a system where Chapter 3 says the writer may be under instruction. Everything Chapter 6 argued about authorization applies to memory, and it usually was not applied, because memory does not look like a resource.

The reframing that helps is to stop calling it memory. It is a datastore that the agent writes to without mediation, and whose contents are injected into future prompts automatically. Described that way, the control gap is obvious.

What poisoning means, precisely

The word covers three distinct manipulations. Separating them makes the defences easier to place.

Fact poisoning writes something false and durable, such as a customer's spending limit, an internal escalation threshold or a claimed prior agreement. The agent later retrieves it as established truth and reasons from it.

Instruction poisoning writes something that reads as a directive rather than a fact, such as a note that this account requires all verification steps to be skipped. It exploits the same weakness as Chapter 3, with the difference that the text is now inside the trusted part of the context.

Behavioural poisoning writes something that shifts the agent's disposition without asserting anything checkable, such as a note that this customer prefers detailed responses including full account history. It is the hardest to detect because nothing in it is false.

The agentic risk list OWASP published on 9 December 2025 includes a memory-poisoning category alongside goal hijacking and tool misuse, which is a useful indication that this is treated as a first-class agentic risk rather than a variation on prompt injection.

Three stores, three different problems

Memory is rarely one thing, and the three common stores need different treatment.

The conversation buffer holds the current session. Its risk is immediate and its lifetime is short, so the defence is largely Chapter 3's, meaning nothing in it is treated as instruction and the tools do not widen based on its contents. It clears itself. That is its saving grace.

The retrieval corpus holds documents the agent searches. Its risk is that the corpus was assembled from sources with different trust levels, and a poisoned document sits there indefinitely being returned for relevant queries. The defence is ingest-side, meaning provenance at index time and the ability to remove a source and everything derived from it.

Long-term agent memory holds what the agent chose to write about past interactions. It is the most dangerous of the three, because it combines an unmediated write path with indefinite retention and an implicit claim of authority. It is also the newest, which means it is frequently the least designed.

Distinguish the three in the architecture rather than lumping them together. A control that fits the conversation buffer will not fit the corpus, and a corpus control will not address the store the agent writes to itself.

Persistence is what changes the economics

The reason this chapter exists separately from Chapter 3 is that persistence changes the attacker's cost model entirely.

A live injection must succeed in the moment. It has to work on the current prompt, with the current tools, in a session somebody may be watching, and if it fails there is nothing left behind.

A memory injection needs one success ever. After that the payload is retrieved by your own infrastructure, on a schedule you chose, into sessions initiated by legitimate users, for as long as the entry survives. Detection is harder in the same proportion, because there is no inbound request to inspect and no user to correlate with.

There is a second-order effect worth naming. Retrieved memory tends to enter the context in a privileged position, near the system prompt and framed as established context rather than as material to evaluate. The poisoned text therefore arrives with better placement than the original injection had.

That is the whole argument for treating memory as a separate control surface. Memory is not more vulnerable. A successful write is simply worth vastly more than a successful prompt.

What the vector and embedding entry names

OWASP's 2025 vector and embedding weaknesses entry is the primary reference here, and it is worth reading as a design brief rather than as a risk list.

It names poisoning of the corpus, where injected content shapes what retrieval returns. It names cross-context information leakage in multi-tenant environments, which is the failure where one customer's data surfaces in another's session. It names unauthorised access to the store, and it names embedding inversion, meaning the recovery of source content from the vectors themselves.

Two of its recommended mitigations are structural rather than procedural, and those are the ones to implement. Permission-aware vector stores, where the access check happens as part of retrieval rather than as a filter applied to results afterwards. And immutable logging of what was written, by whom and when, which is what makes an incident investigable at all.

The embedding inversion point deserves a moment, because it is often skipped. Vectors are not a form of encryption, and a store containing embeddings of sensitive documents should inherit the access controls of those documents rather than being treated as derived metadata that can live somewhere more convenient.

Provenance is the prerequisite

Every control in this chapter depends on one property, and systems that lack it cannot implement any of the others.

Each memory entry needs to record where it came from. Whether it was written by the system or generated by the model, which session and which user it arose from, what source text it derived from, when it was written, and whether any part of its lineage traces to content an outsider could author.

Without that, the questions an incident asks are unanswerable. What did this agent believe six weeks ago. Which entries derive from tickets filed by this account. If this document was poisoned, what else is contaminated. Those are trivial with provenance and impossible without it, and the moment you need them is the moment it is too late to add.

Provenance also makes revocation possible, which is the property that turns an investigation into a remediation. Removing a poisoned source should remove everything derived from it, including summaries the agent wrote about it, which requires that the derivation was recorded at the time.

Store provenance as structured fields rather than as prose inside the remembered text. Text is what the attacker controls.

Quarantine, then promote

With provenance in place the useful control is a two-tier store, and the rule that separates the tiers is simple to state.

Trusted memory holds what the system wrote or what a person verified. It may be retrieved as fact. Quarantined memory holds anything derived from content an outsider could influence, which after Chapter 3 means most of what the agent writes about its work. It may be retrieved, and it is presented to the model as a claim with an attribution rather than as established context.

The framing difference is not cosmetic, and it is also not sufficient on its own, since the model may still be persuaded. The enforceable half is that quarantined memory may never widen what happens next. It cannot change which tools are available, cannot supply an identifier used for authorization, cannot raise a limit, and cannot satisfy an approval requirement. Those are all decisions made outside the model by Chapters 4 through 6, and they simply do not read from the quarantined tier.

Promotion is the deliberate step between the tiers. Something moves to trusted when a person confirms it, when a system of record independently attests it, or when a deterministic check verifies it. Promotion is logged. It has an actor.

Expiry completes the design. Memory entries carry a lifetime, quarantined entries carry a short one, and anything nothing has reaffirmed decays out of the store. An agent that remembers everything forever is accumulating liability at a constant rate.

A worked example, composited and labelled

The details are composited from ordinary production shapes rather than one system, and the shape is exact.

A support agent writes preference notes after each interaction. A ticket in February contained a paragraph asserting a special handling policy for the account, phrased as company policy. The agent recorded it.

Before the work, that note is a row of free text keyed by account, retrieved into every subsequent session near the top of the context. Nothing records where it came from, and nothing distinguishes it from a note written by a human account manager.

After the work, the same write lands in quarantine, tagged with the ticket it derived from, the session, and the fact that its lineage includes customer-authored text. It is retrieved as a claim, attributed to the ticket, and the tool layer does not consult it when deciding what the agent may do for this account. It expires in ninety days unless a human promotes it.

The attack still succeeded in the sense that the write happened. Its value collapsed, because the entry cannot authorise anything, it carries a visible origin, and when the ticket is later identified as malicious the derived entry is removed with it.

The objection: this makes memory useless

The objection deserves a real answer, because a memory system nobody trusts is a feature nobody uses.

What the design costs is the ability to treat everything the agent learned as equally authoritative. That capability was never safe, and most of its perceived value came from not having thought about the alternative.

What survives is nearly all of the utility. Preferences, prior context, learned shortcuts and summaries of past work are all still retrieved and all still shape responses. The only thing they cannot do is silently expand the agent's authority, which is not a use case anybody would have requested if it had been described out loud.

The genuine cost is engineering, and it is front-loaded. Provenance fields, a two-tier retrieval path, a promotion step and an expiry job are perhaps a fortnight of work designed in, against a retrofit onto a populated store where nothing recorded where anything came from. The second version of this project is much worse than the first, and the store grows every day it is postponed.

Chapter summary

Memory converts a single successful injection into a standing instruction, because one write is retrieved by your own infrastructure into legitimate sessions indefinitely, and it arrives in the agent's own voice with no inbound request to inspect and no user to correlate against. The word poisoning covers three manipulations, being false durable facts, embedded directives that read as notes, and behavioural nudges that assert nothing checkable, and OWASP's agentic list published on 9 December 2025 includes a memory-poisoning category alongside goal hijacking and tool misuse. Three stores need separate treatment: the conversation buffer, whose short lifetime saves it; the retrieval corpus, which needs ingest-side provenance and source-level removal; and long-term agent memory, which combines an unmediated write path with indefinite retention and is the least designed of the three. OWASP's vector and embedding entry names corpus poisoning, cross-context leakage in multi-tenant systems, unauthorised access and embedding inversion, and recommends permission-aware stores where the check happens during retrieval rather than as a filter afterwards, plus immutable logs of what was written. Provenance is the prerequisite for everything else, recording origin, session, derivation and whether the lineage touches outsider-authored text, stored as structured fields rather than inside the remembered prose. The workable control is a two-tier store where quarantined memory may be retrieved as an attributed claim but may never widen tool access, supply an authorization identifier, raise a limit or satisfy an approval, with promotion to trusted requiring a person, an attesting system of record or a deterministic check, and with expiry removing what nobody reaffirms.

Everything so far has concerned one agent, its tools and its memory. Systems increasingly contain several agents that call each other, at which point one agent's poisoned belief becomes another agent's trusted input. Chapter 10 is Inter-Agent Communication and Cascading Failure.