What Is Context Window Poisoning?

Context window poisoning is the introduction of false, misleading, or manipulated content into an AI agent's active context window during a single session, such that the agent's own subsequent reasoning steps treat the poisoned content as established fact for the remainder of that session. It is a same-session, in-memory corruption — distinct from attacks that plant content in a durable store meant to persist across sessions.

Why This Needs Its Own Term

Multi-step agents accumulate context as they work: a retrieved document, a tool's response, an intermediate conclusion, all get appended to the running context that subsequent steps reason over. That accumulation is what makes multi-step agents useful — each step can build on what came before instead of starting from scratch. It is also the exact mechanism context window poisoning exploits.

If a false claim enters the context at step three — because a retrieved document contained inaccurate information, a tool returned a malformed or manipulated result, or an earlier reasoning step drew an incorrect conclusion — the agent has no inherent mechanism to distinguish that claim from a verified one once it is sitting in context alongside everything else. Steps four, five, and six reason over the poisoned claim exactly as they would over a verified fact, because from the model's perspective, everything in context looks the same: text to be conditioned on.

This differs from a single bad output. A model can produce one wrong answer and the error stops there if nothing downstream depends on it. Context poisoning is specifically about propagation — a false premise introduced once cascades through every later step that references it, and the compounding effect can produce a confidently wrong final result built entirely on a chain of individually reasonable-looking steps.

The Mechanism

Context poisoning typically arises through one of these paths:

Poisoned retrieval. A document, search result, or database record fetched mid-task contains false or manipulated information, and nothing in the agent's pipeline validates it against a more authoritative source before it is added to context.

Manipulated tool output. A tool call returns a result that has been altered — by a compromised upstream service, a misconfigured integration, or an attacker with write access to whatever the tool reads from — and the agent incorporates the tampered result as if it were ground truth.

Self-reinforcing error. The agent's own earlier reasoning step draws an incorrect conclusion, appends it to context as an established premise, and later steps build on it without re-examining the original evidence. No external attacker is required for this variant; it is a consequence of long reasoning chains accumulating unverified intermediate claims.

Deliberate injection via a trusted-looking channel. An attacker who cannot reach the user-agent conversation directly plants content in a source the agent is known to retrieve from — a wiki page, a shared document, a support ticket — engineered to be accepted as background fact rather than recognized as an instruction. This overlaps with indirect prompt injection but the goal here is corrupting what the agent believes, not directing what it does next.

Detection Signals

Because the corruption is session-scoped, detection has to happen either during the session — inspecting context as it accumulates — or in a post-hoc review of the session transcript. Once the session ends and context resets, the specific poisoned instance is gone, but the retrieval source or tool that produced it typically is not, and will poison the next session the same way unless fixed at the source.

Controls

Tag content with provenance. Every piece of context — retrieved document, tool output, prior reasoning step — should carry a marker for where it came from and how authoritative that source is. Provenance tagging is what allows downstream logic, or a human reviewer, to weigh a claim appropriately instead of treating everything in context as equally reliable.

Weight trust by source, not by recency. A claim from a verified internal system of record should not be overridden by a claim retrieved later in the same session from an unauthenticated external page, simply because the second one arrived more recently in context. Trust weighting has to be explicit rather than left to the model's implicit recency bias.

Re-validate high-consequence claims. Before an agent acts on a claim that has significant downstream consequence — an irreversible write, a financial transaction, a customer-facing statement — re-check that specific claim against an authoritative source rather than relying on whatever is already sitting in context.

Apply content guardrails to retrieved and tool-sourced content, not just to conversational input. The same inspection discipline used on user messages should extend to everything the agent pulls into its own context, since that is where poisoning actually enters.

How This Differs from Memory Poisoning and Indirect Prompt Injection

These three terms describe related but mechanically distinct problems, and conflating them leads to the wrong control.

The clearest distinguishing question is: does the corrupted content survive after this session ends, and was it an instruction or a false premise? If it disappears at session end and functions as a false fact rather than a command, you are looking at context window poisoning. If it persists in a writable store, it is memory poisoning. If it is a hidden instruction rather than a false claim, it is prompt injection, whether direct or indirect. An attack can combine more than one of these — an indirect prompt injection can be the delivery mechanism that poisons context, which then gets written into memory and persists — which is why the controls for each layer need to work independently rather than assuming an earlier layer already caught the problem.

Where This Fits in an Agent Governance Program

Context window poisoning is a content-layer risk, which places it squarely inside the guardrail component of a broader AI agent governance program rather than the identity or authorization components. An agent can have perfect credentials, a correctly scoped connection policy, and still poison its own reasoning through a single bad retrieval, because none of those controls inspect what the agent believes — only who it is and what it is allowed to call. This is precisely why a governance program needs guardrails as an independent control point rather than treating identity and authorization as sufficient on their own: a fully authorized, correctly authenticated agent is exactly the agent context poisoning targets, since the attack does not need to bypass access control at all.

Guardrail placement matters here more than in most other content-risk scenarios. A guardrail that only inspects the final response arrives too late — by the time output is generated, the poisoned premise has already propagated through every intermediate reasoning step. Inspection needs to happen at ingestion, when content first enters context, not only at the exit point. See designing guardrails: block, redact, or warn? for how to choose the right enforcement action once ingestion-time inspection flags a suspect claim.

Common Questions

Does a longer context window make poisoning worse? It increases the surface, not the severity of any single instance. A longer window means more retrieved documents, more tool calls, and more intermediate conclusions accumulate before the session ends, which gives poisoned content more opportunities to enter and more downstream steps to propagate through before anyone reviews the transcript. The underlying mechanism is the same regardless of window size.

Is this the same risk that retrieval-augmented generation systems face with irrelevant or low-quality retrieved documents? Related but not identical. Ordinary retrieval quality problems degrade an answer's accuracy without necessarily corrupting how the agent reasons about subsequent, unrelated steps. Context window poisoning specifically describes content that gets treated as a load-bearing fact for later reasoning, propagating error rather than simply degrading a single output's quality.

Can this happen without any external attacker at all? Yes, and that is an important operational distinction from prompt injection. A retrieval system returning a stale or low-quality document, or an agent drawing an incorrect intermediate conclusion during a long reasoning chain, can poison context with no adversary involved. Detection and mitigation controls need to work against both the accidental and the deliberate case, since from the pipeline's point of view a false premise looks the same either way.

What Good Looks Like

• Every item entering an agent's context carries a provenance tag, and the reasoning pipeline can distinguish a verified internal record from an unauthenticated external page.
• High-consequence actions re-validate their supporting claims against an authoritative source rather than trusting whatever is already in context.
• Content guardrails inspect retrieved documents and tool outputs, not only conversational input.
• Session transcripts are reviewable after the fact, so a poisoned claim that produced a bad outcome can be traced back to the specific retrieval or tool call that introduced it.
• Teams treat context poisoning, memory poisoning, and prompt injection as related but separately controlled risks, rather than assuming a defense against one covers the others.