What Is Context Poisoning?

What is context poisoning?

Google's Gemini team described the failure in the Gemini 2.5 technical report. Writing about the agent that played Pokémon on Gemini 2.5 Pro, the report gives an example of fixation: the model "was deluded into thinking that it had to retrieve the TEA in order to progress," an item from the remakes that does not exist in the original game, and "spent many, many hours" looking for it. It then names "an especially egregious form of this issue": context poisoning, "where many parts of the context (goals, summary) are 'poisoned' with misinformation about the game state, which can often take a very long time to undo" (§8.2).

Drew Breunig generalized the idea in How Long Contexts Fail (June 2025): "Context Poisoning is when a hallucination or other error makes it into the context, where it is repeatedly referenced." It is the first of his four context failures, ahead of distraction, confusion and clash, which LangChain's Context Engineering for Agents (July 2025) cites before setting out its write, select, compress and isolate strategies.

The word has a second, adversarial meaning. MITRE ATLAS lists AI Agent Context Poisoning (AML.T0080): "Adversaries may attempt to manipulate the context used by an AI agent's large language model (LLM) to influence the responses it generates or actions it takes," either through the agent's memory or through prior messages in a thread. Both meanings share the mechanism. Only the source of the bad content differs.

How context poisoning works

An illustrative sequence in an invoice-reconciliation agent:

1. 1.On turn 12 the model misreads a tool result and writes "vendor 4471 is on credit hold" into its running summary.
2. 2.From turn 13 on, every prompt is assembled from that summary, so the claim arrives as established state, not as a guess.
3. 3.The agent skips the vendor's invoices and drafts a ticket to lift the hold. Each new note repeats the claim.
4. 4.On turn 30 a fresh tool result shows no hold. One correct observation now competes with a dozen entries that say otherwise.
5. 5.Appending a correction is not enough. The false entries have to be removed or the summary rebuilt.

The fix starts with what is allowed into the fields the model re-reads every turn:

# Goals and summaries are re-read every turn, so gate what enters them.
def commit_to_summary(state, claim, evidence_ids):
    supported = [e for e in evidence_ids if e in state.tool_results]
    if not supported:
        state.scratch.append({"claim": claim, "status": "unverified"})
        return state
    state.summary.append({"claim": claim, "evidence": supported})
    return state

Two more defenses follow the same logic. Rebuild summaries from tool results, not from the previous summary, so an error can't copy itself forward. And run risky subtasks in separate contexts, which Breunig calls context quarantine: "isolating contexts in their own dedicated threads" (How to Fix Your Context).

Why context poisoning matters in real-time systems

Context poisoning is an in-prompt failure: the false claim lasts because the agent keeps re-reading its own context. A stale fact is a different failure. A balance that trails the latest transaction, or an order status a cache has not yet updated, was true once. It enters the prompt already out of date because the store it came from lags its source. That is context lag, and it sits upstream of the prompt. Evidence gates and summary rebuilds address poisoning; they cannot make a lagging store current. A fresh read, in turn, does not remove a hallucination already copied into a goal list.

The two do interact. A stale value read once and then written into a summary behaves like poison, because every later turn treats it as settled. Keep live values out of durable summaries and re-read them at the step that acts on them. The broader split between in-prompt failures and stale inputs is covered in context rot vs. context lag.

FAQ