Context Poisoning: Diagnose, Isolate, and Stop Inference-Time Agent Corruption

The third patch looked confident. Same wrong import. Same skipped validation. You had not changed the model. You had fed it its own mistakes until they read like ground truth.

Context poisoning is an inference-time exploit (OWASP ASI06) that corrupts an agent's active context, RAG retrievers, or lasting memory with stale or malicious material. Unlike single-turn prompt injection, it persists across tool loops and sessions, driving cascading reasoning failures and documented debugging-decay drops after repeated fix attempts. Defend with temporal hybrid retrieval, upstream sanitization, and dual-context handoffs that reset reasoning without erasing verified state.

Last verified: 21 August 2026 (NotebookLM sources; no live CLI run on this pack).

The formatter ran twice before I noticed the pattern. Attempt one introduced a brittle workaround. Attempt two defended it. Attempt three rewrote the same mistake with better comments. None of it needed a human after the first fifteen minutes. The session I dreaded finished while I made coffee, and the model never recovered because the transcript had become the spec.

If you have ever nuked a chat and instantly watched the agent get smarter, you already felt context poisoning. You just did not have a name for the mechanism.

This guide is troubleshooting for inference-time corruption: how poison enters, how it loops, and how to isolate it without throwing away every verified fact. It is not context engineering best practices for healthy agent design, not the prompt engineering vs context engineering definitional split, and not Anthropic context management as a platform feature tour. Those siblings cover different primaries. Here we own context poisoning, rag poisoning, and context pollution llm as one failure-first job.

On this page

• What context poisoning is (and is not)

• Accidental vs adversarial vectors (including RAG poisoning)

• Multi-turn context pollution and feedback loops

• Defensive and architectural mitigations

• Dual-context fresh starts without amnesia

• Detect drift before the agent fails hard

• FAQ

Context poisoning corrupts memory and retrieval at inference time, not model weights.

What context poisoning is (and is not)

Picture a hospital whiteboard where nurses log vitals, allergies, and active orders. Someone writes "penicillin OK" in the margin during a chaotic shift. The next nurse reads the board, not the chart. Orders propagate. The error survives handoffs because the board outranked the source of truth.

Now imagine a separate attack where a visitor shouts a fake code over the intercom once. Loud. Scary. Gone in thirty seconds. Staff reset. No sticky residue on the board.

The whiteboard is persistent shared state. The intercom is a transient override. Large language models face the same split when they ingest instructions mixed with data.

Context poisoning is the whiteboard problem. An attacker, a stale index, or your own debugging transcript writes bad material into the surfaces the model treats as ground truth: retrieved chunks, tool outputs, memory stores, open files, and multi-turn history. The model weights stay untouched. The active window rots.

That distinction matters for threat modeling and for search intent. Training-time data poisoning alters weights before deployment. Inference-time context poisoning exploits the runtime window. If you need the training-time job, see the planned guide on data poisoning. If you need single-turn chat overrides, see prompt injection defenses.

Inference-time context poisoning vs training-time data poisoning

Training-time attacks corrupt datasets or fine-tuning pipelines so the model learns wrong associations permanently. Inference-time attacks leave weights alone and corrupt what gets assembled into the prompt at request time.

The operational difference is detection and rollback. Weight poisoning needs retraining or rollback artifacts. Context poisoning can often be fixed by purging a vector row, clearing tool history, or starting a fresh reasoning session while keeping a fact ledger.

Memory poisoning vs transient prompt injection

Memory and context poisoning, including agentic memory poisoning as a list-level threat, targets durable state: RAG indexes, agent memory APIs, session logs, and tool-result chains. OWASP classifies this family as ASI06 in the Agentic Top 10 for 2026. Prompt injection, by contrast, usually lives in the immediate user message and ends when the session ends or the message scrolls out of attention.

Memory poisoning persists. Prompt injection is often one-shot.

Indirect prompt injection sits between the two in practice: a third-party document smuggles instructions into retrieved context. The delivery is transient per fetch, but the effect persists until you purge the source or filter retrieval. Deep dives on that mitigation surface belong on the prompt injection defenses spoke, not as a second primary here.

The difference is boring. It is also the whole game. AppSec tools that scan prompts miss ASI06 because the malicious text never touched the chat box. It lived in a comment, a stale Confluence page, or a poisoned embedding row.

Accidental vs adversarial vectors (including RAG poisoning)

Same symptom space. Different intent. Different urgency. Accidental rot is what most production teams hit first. Adversarial rag poisoning is what your red-team budget exists to simulate.

Accidental production rot in RAG pipelines

Accidental context poisoning is routine engineering debt, not a hacker in a hoodie.

Stale TTL is the classic pattern. A doc set outlives the product. The retriever still serves "deprecated OAuth flow" because nobody expired the chunk. Temporal degradation shows up as confident wrong answers that sound current.

Semantic noise is the cousin problem. Vector search returns embeddings-close but task-wrong passages. A query about billing retrieves HR policy because both mention "accounts." Token budget fills with clutter. Signal drowns.

Information conflicts happen when two authoritative-looking sources disagree and hybrid search treats them as equal-weight. The model hedges, blends, or picks the wrong branch.

These three patterns are the primary accidental context poisoning vectors in production RAG systems. They recur because pipelines optimize for recall first and freshness second.

Adversarial retrieved-document injection

Adversarial rag poisoning targets the retrieval layer on purpose. Attackers seed documents crafted to rank for high-value queries and smuggle instructions inside plausible prose.

The PoisonedRAG study cited in production writeups reported roughly 90% success when injecting five malicious texts per target question into knowledge bases with millions of entries. You do not need a million docs to feel the shape of the attack. You need one high-ranking poison row and a query that retrieves it.

Same symptom space. Different intent and defenses.

Red-team tools document the attack strings without becoming the spine of this guide. Promptfoo's RAG poisoning plugin generates adversarially modified documents for gray-box tests:

promptfoo redteam poison document1.txt document2.txt --goal "Extract API keys"

That command sends full document contents to a remote generation endpoint. There is no local fallback. Setting PROMPTFOO_DISABLE_REMOTE_GENERATION=true (or the red-team variant) causes the poison command to exit with an error instead of synthesizing payloads locally.

DeepTeam exposes a parallel Python pattern:

from deepteam import ContextPoisoning

cp = ContextPoisoning(weight=3, max_retries=3)
enhanced_attack = cp.enhance(base_attack)

Use these as evidence of attack shape, not as a product tour. Configuration details live in the Promptfoo RAG poisoning docs and DeepTeam context poisoning docs.

Coding-assistant ingestion surfaces

Context window poisoning in AI coding assistants follows a wider ingestion surface than chat-only bots. Assistants assemble context from open files, repository docs, inline comments, hidden metadata files, MCP server responses, and IDE-selected snippets. Attackers do not need your password. They need a # temporary: skip auth check comment in a file your assistant will read.

Poison enters through ordinary ingestion surfaces, not only chat.

VS Code versions before 1.87.2 carried CVE-2024-26165, a high-severity privilege escalation issue noted in security writeups on coding-assistant context risk. Patch history matters, but comment injection survives patched IDEs because the model, not the editor, executes semantic instructions.

MCP results deserve boundary hardening as their own job. Tool metadata poisoning is real, and the mitigation patterns belong on the planned MCP security spoke. Here, treat MCP responses as untrusted text that must pass the same sanitization gate as web fetches.

Multi-turn context pollution and feedback loops

Context pollution llm failures rarely arrive as a single bad retrieval. They compound. One wrong tool result becomes chain-of-thought justification. That justification becomes memory. Memory steers the next tool call.

Debugging decay and local minima

Debugging decay is the name practitioners gave to the pattern where iterative bug chat makes the model worse, not better. Research discussed on r/LocalLLaMA reported roughly an 80% drop in coding fix rates after the third attempt when the full conversational history stayed in context. The model rat-holes: it treats its own prior wrong patches as constraints and searches locally around bad logic.

But here is the thing. That paper evaluated older model generations. Frontier long-context systems handle multi-step repair more gracefully today. Practitioners on the same threads report fewer mandatory chat nukes on recent Claude and Gemini builds. Keep both facts. The decay curve is real on polluted history. The wipe frequency is model-dependent now.

When you see decay, classify it before you blame weights. If a fresh session with the same repo fixes the bug immediately, you are looking at context pollution llm dynamics, not capability limits.

Distraction, confusion, and clash as failure modes

Long contexts fail in four recurring modes cataloged in failure-taxonomy writeups. They are not separate products. They are four faces of one crowded window.

Four failure modes. Same polluted context window.

Context rot is useful signal drowning in clutter. Correctness on long-context RAG evals often falls once contexts pass roughly 32k tokens on benchmarks such as Llama 3.1 405B runs cited in taxonomy posts.

Context distraction is old goals crowding new tasks. Agents repeat stale objectives instead of planning forward. Anthropic's engineering guide notes that transformer attention scales with O(n²) pairwise token relationships, so attention budgets stretch thin as sequences grow.

Context confusion is tool overload. Too many MCP tools, too many JSON schemas in the system prompt, and the model calls the wrong function or hallucinates parameters.

Context clash is sharded multi-turn design. Breaking one benchmark prompt into a chatty back-and-forth dropped average accuracy about 39% in cited tests, with OpenAI o3 falling from 98.1 to 64.1 on one Salesforce-style task. Early wrong assumptions cement because later turns inherit them.

One bad tool result can cascade into lasting memory.

The propagation loop is mechanical. Tool output enters the transcript. Chain-of-thought rationalizes it. Memory or session state stores the rationalization. The next turn retrieves the stored error as fact. Redis's agent-reasoning writeup names the same cascade across tool output, chain of thought, and memory contamination across sessions.

This Short walks the Pokémon-agent case study in under a minute: one hallucinated action enters history and permanently poisons downstream planning.

https://www.youtube.com/shorts/qQ5SvhpndNQ

If you prefer primary sources, pair the clip with Anthropic's context engineering guide on long-horizon tasks and dbreunig's taxonomy post on how long contexts fail.

Defensive and architectural mitigations

Defense starts upstream of the model. If poisoned text is already inside the window, you are negotiating with corrupted attention. Filter retrieval, boost trustworthy metadata, compact aggressively, and isolate sub-agents before you tune prompts.

Temporal filtering and metadata boosting

Temporal filtering is the fastest win for accidental rot. Elasticsearch Labs documents hybrid search patterns that embed relative date ranges directly in retriever filters:

{
  "range": {
    "last_updated": {
      "gte": "now-6M"
    }
  }
}

Adapt the field name to your stack. The mechanism is what matters: hard-exclude chunks older than your freshness SLA unless the query explicitly asks for history. A one-year variant uses "gte": "now-1y" inside the same filter array on RRF-style retrievers.

Metadata boosting resolves information conflicts without deleting older docs. A bool query with weighted should clauses prioritizes deployment-specific tags:

{
  "bool": {
    "should": [
      { "term": { "deployment_type": { "value": "serverless", "boost": 3.0 } } }
    ]
  }
}

Stack-agnostic middleware can mirror the same idea in Python against pgvector or ChromaDB: apply age thresholds at query time, then re-rank by environment tags before tokens enter the prompt. The Elasticsearch context poisoning guide shows the DSL shape; your job is to port the intent.

Compaction, tool clearing, and minimal toolsets

Anthropic recommends compaction, structured note-taking, and sub-agent architectures for long-horizon agents. Tool result clearing is the lightest compaction: purge raw tool payloads from message history once summaries exist. The Claude Developer Platform exposes that pattern natively.

Claude Code uses a hybrid fetch model worth naming because it explains accidental poisoning paths: CLAUDE.md files inject upfront, while glob and grep pull dynamic segments. Static injection rots when the repo changes but the markdown does not. Dynamic fetch rots when hidden files or comments poison what grep returns.

Minimal toolsets attack context confusion directly. If twelve MCP servers register forty tools, the model sees forty ways to fail. Disable inactive servers for the task. Return condensed sub-agent summaries instead of full search traces.

Filter first. Compact second. Clear tool noise.

Sub-agent isolation is the architectural version of the same idea. Let a research sub-agent absorb messy retrieval. Pass one paragraph upstream. Poison stops at the boundary if you enforce structured handoffs.

Offline checks when remote poison generation is blocked

Promptfoo's poison command requires remote generation. Air-gapped teams cannot rely on it without exfiltrating document contents. Build local checks instead.

A practical offline recipe:

1. Seed a canary query set tied to high-risk intents (credentials, admin actions, PII export).

2. Embed approved golden answers and forbidden phrases with a local embedding model.

3. On index updates, retrieve top-k for each canary query and score cosine similarity drift against golden baselines.

4. Flag chunks whose similarity to forbidden instruction templates crosses a threshold you calibrate on known bad examples.

5. Block promotion to production retrieval until a human reviews flagged rows.

This is not as elegant as gray-box synthesis. It runs entirely inside your VPC. Pair it with regex guards for obvious injection templates (ignore previous, system:, base64 blobs in comments) on ingest.

The KodeKloud lab below implements selective RAG, summarization, and metadata age validation in Python if you want a guided pass.

https://www.youtube.com/watch?v=Ctl59wNrnKo

Vendor gateways like Kirin, Redis Iris, or TrustGuard can add runtime inspection. Treat them as optional accelerators, not prerequisites. The patterns in this section port without proprietary middleware.

Dual-context fresh starts without amnesia

Here is where most guides stop at "start a new chat." That advice fixes decay and causes amnesia. Developers on r/LocalLLaMA describe the better move as a context handoff: wipe reasoning pollution, snapshot verified facts, spawn a clean reasoning session seeded with the snapshot only.

Ephemeral reasoning vs immutable state facts

Split agent memory into two lanes.

Ephemeral reasoning context holds chat turns, chain-of-thought, rejected patches, and exploratory tool traces. It is allowed to be wrong. It should be cheap to delete.

Immutable state facts hold verified errors, file paths, reproduction commands, test output, environment constraints, and human-approved decisions. Treat this lane as append-only with explicit invalidation. Never let the model silently rewrite facts without a validation hook.

Wipe polluted reasoning. Keep verified facts.

The handoff bridge copies a curated snapshot from facts into a fresh reasoning session, then blocks backward contamination. Reasoning stays disposable. Facts stay durable.

When to wipe and when not to

Wipe reasoning when you see debugging decay signatures: repeating wrong imports, defending failed patches, or escalating tool calls that mirror prior mistakes. Three failed fix attempts with monotonic confidence is a practical trigger, aligned with the decay research, even if frontier models sometimes recover earlier.

Do not wipe facts when tests still fail for known, reproduced reasons. The fact ledger should carry the stack trace, the failing assertion, and the last good commit hash. Wiping facts turns a context problem into a ground-truth problem.

On frontier models with strong long-horizon repair, prefer compaction and tool-result clearing before a full wipe. I tried aggressive nukes on recent builds and lost useful intermediate hypotheses I still needed. Compaction first, wipe second, facts never.

Snapshot handoff checklist

Before you spawn the fresh session, snapshot:

• Verified errors: exact message text, line numbers, test names.

• Paths: repo root, relevant files, branch name.

• Constraints: language version, feature flags, "do not touch" modules.

• Human decisions: approved approach, rejected approaches, security boundaries.

Then reset reasoning and inject only the snapshot plus a short task restatement.

Stack-agnostic sketch:

facts = {
    "error": "TypeError: NoneType in auth.validate at line 142",
    "paths": ["src/auth/validate.py", "tests/test_auth.py"],
    "constraints": ["Python 3.11", "keep JWT middleware unchanged"],
    "rejected": ["disabling validation", "monkeypatch in conftest"],
}

reasoning_session = new_session(system=BASE_PROMPT)
reasoning_session.inject(facts_ledger=facts, wipe_prior_turns=True)
# Enable tool-result clearing after each tool batch (platform equivalent of Anthropic compaction)

No invented CLI flags beyond patterns documented for Claude Code's hybrid CLAUDE.md plus glob/grep fetch and platform tool-result clearing. Wire the sketch to your orchestrator's session API.

HowTo summary for operators:

1. Detect decay or clash signatures in the transcript.

2. Freeze the fact ledger from tests, logs, and human notes.

3. Wipe ephemeral reasoning only.

4. Open a new session with facts plus restated goal.

5. Re-enable tools gradually; avoid re-injecting full prior tool dumps.

Detect drift before the agent fails hard

Poisoning is easier to stop at the drift stage than after the agent ships bad code. Behavioral indicators beat magical "AI firewalls" here.

Behavioral indicators and contextual drift signals

Watch for suggestion inconsistency: the assistant advocated strict validation an hour ago and now proposes bypass helpers. That shift often tracks hidden context growth, not model mood.

Unexpected context size spikes in telemetry can mean a new doc folder, an runaway MCP log, or a poisoned chunk repeating in retrieval loops. You do not need vendor IDE dashboards to catch this. Diff open-file lists and retrieved-chunk counts turn to turn.

Audit comments that read like instructions inside code blocks. # TODO: remove security check for demo is a social engineering string aimed at the model, not the compiler.

Scan for contextual drift in repository metadata: renamed README sections, new dotfiles, or MCP config edits that appear mid-sprint without a ticket.

Unicode homoglyphs in comments remain a cheap attack. Normalize text on ingest if you run an upstream sanitizer.

Optional comment-audit stub:

import re

INSTRUCTION_LIKE = (
    r"(?i)(ignore previous|skip auth|disable validation|system:)"
)

def scan_file(path: str, text: str) -> list[str]:
    hits = []
    for i, line in enumerate(text.splitlines(), 1):
        if line.strip().startswith("#") and re.search(INSTRUCTION_LIKE, line):
            hits.append(f"{path}:{i}")
    return hits

Run it in CI on changed files. It catches obvious context window poisoning strings before the assistant ingests them.

This will not work if you treat detection as a one-time pen test. Drift is continuous. Schedule canary queries against production retrieval weekly. Review MCP allowlists when teams add tools. Re-baseline after major model upgrades because attention behavior shifts.

FAQ

How is context window poisoning different from traditional prompt injection?

Context window poisoning corrupts the background files, repositories, databases, and tool logs an assistant assembles automatically. Traditional prompt injection is a transient, single-turn override through the chat input, and the malicious instruction typically disappears when the active session ends. Poisoning persists across tools and sessions until you purge the source or filter retrieval.

What is debugging decay and why does chatting more about a bug make the model worse?

Debugging decay describes performance collapse when iterative fix conversations stay in context. Reported research on older models showed roughly an 80% drop in coding fix rates by the third attempt because the model anchors on its own prior wrong patches. Newer frontier models reduce how often you must wipe, but polluted history still causes local-minima loops on any architecture.

How does context distraction affect long-context model performance?

As contexts approach tens of thousands of tokens, quadratic attention scaling dilutes focus. Agents begin repeating stale objectives from earlier turns instead of planning new steps. Long-context RAG benchmarks cited in taxonomy work show correctness falling around 32k tokens for some large models, with smaller models degrading earlier.

What is context clash and how do sharded prompts hurt accuracy?

Context clash happens when multi-turn transcripts contain contradictory instructions or facts assembled in stages. Sharded prompt designs that split one task into many chat turns let early wrong assumptions cement. Cited benchmark work reported about a 39% average accuracy drop, including sharp falls on strong reasoning models when prompts were conversationalized.

What are the primary accidental context poisoning vectors in production RAG systems?

The three recurring accidental vectors are stale documents without TTL validation, semantic noise from embedding-close but task-wrong retrieval, and information conflicts where hybrid search treats contradictory docs as equal-weight. Multi-turn sessions that write early incorrect reasoning back to memory amplify all three.

What is the OWASP classification for memory and context poisoning?

Memory and context poisoning is classified as ASI06 in the OWASP Top 10 for Agentic Applications 2026. The label marks a shift from protecting static model weights to securing dynamic runtime memory, RAG stores, and tool-mediated state.

How can developers use temporal filtering to defend RAG systems from context rot?

Developers embed relative date filters such as "gte": "now-6M" or "gte": "now-1y" in hybrid retriever queries so outdated pages never enter the prompt. Pair temporal filters with metadata boosting when multiple valid versions coexist for different deployments.

What is the benefit of tool result clearing in agent context management?

Tool result clearing removes bulky historical tool payloads from the message history after summaries exist, preserving token budget and reducing distraction from obsolete logs. Anthropic documents it as one of the lightest forms of compaction on the Claude Developer Platform.

How do hidden files and code comments become attack vectors in AI coding assistants?

Assistants ingest open files, comments, hidden metadata, and MCP responses when building context. Attackers hide natural-language instructions in those surfaces, such as comments that tell the model to skip validation, so insecure code generates without a direct chat injection.

The next wave of agent security products will sell "poison-proof memory" the way WAF vendors sold "SQL-proof forms." Some layers will help. Some will be theater with a compliance PDF. What I am watching is simpler: teams that treat retrieval, tool output, and chat history as three different trust zones, not one blob labeled context.

Whether frontier models outgrow mandatory fresh starts is still open. The dual-context pattern stays useful because it separates facts you verified from reasoning that was always disposable.

Pick one failing agent loop this week. Classify the last failure as accidental rot, adversarial injection, or multi-turn decay. Apply one temporal or metadata filter on retrieval, or one upstream comment scan if you run coding assistants. Then run one dual-context reset: snapshot verified errors and paths, wipe reasoning only, reopen with the ledger. If the loop is healthy design rather than poison, start from context engineering best practices. If the bug is transient chat overrides, use prompt injection defenses. For MCP hardening, use MCP security. For platform compaction features without the failure lens, see Anthropic context management.

Until then...

• Sage

PS. Interactive challenge: open your last three agent transcripts that went sideways. Highlight every line the model wrote that later turns treated as fact. Count how many are test output versus speculation. That ratio is your decay thermometer.