Context Window Poisoning: OWASP ASI06 Defense Guide

Context window poisoning achieves attack success rates above 80% in controlled research, and enterprise deployments are deploying AI agents with none of the defenses that would catch it. OWASP classified this threat class as ASI06 in the 2026 Agentic AI Top 10, formally recognizing that long-context reasoning has created a new attack surface that sits outside the coverage of most existing AI security programs.

This guide explains what context window poisoning is, how it differs from prompt injection, the four documented attack patterns, why 200K-token context windows have made this problem substantially worse, and the layered defense architecture your team needs to deploy before an adversary uses it against you.

What Is Context Window Poisoning and Why OWASP Classified It as ASI06

Context window poisoning is an attack where an adversary pre-positions malicious instructions inside content that an AI agent will read and reason over: PDFs processed by a document AI, entries in a shared log file, conversation history passed between agent turns, or chunks retrieved from a RAG pipeline. When the agent's reasoning system encounters these instructions, it treats them as authoritative directives because they arrive from what the agent considers trusted internal context, not from a suspicious external user.

OWASP's 2026 Agentic AI Top 10 places this under ASI06: Memory and Context Poisoning. The classification acknowledges that modern agentic systems rely on context far beyond the immediate user turn. An agent may read tool outputs, retrieved documents, episodic memory from prior sessions, handoff summaries from upstream agents, and structured data from APIs, all within a single reasoning pass. Any of those inputs is a potential injection vector.

The classification matters for enterprise risk programs because ASI06 is not covered by defenses designed for LLM01 (Prompt Injection from OWASP's original LLM Top 10). LLM01 defenses focus on the input boundary: validating and sanitizing what users send. ASI06 attacks bypass that boundary entirely by operating at the data layer, inside content the agent is supposed to analyze, not reject.

How Context Window Poisoning Differs from Prompt Injection

The practical difference matters for security architecture. Prompt injection requires an attacker to reach the input boundary: the chat interface, the API endpoint, the tool call response. Those surfaces typically have monitoring, rate limiting, and some form of input inspection.

Context window poisoning requires only that an attacker controls, or can influence, any content that will enter the agent's context at runtime. That includes:

• A document stored in a shared file system that the agent will process
• A web page that a tool-equipped agent will fetch and summarize
• A log file entry that an AI SOC agent will analyze during an investigation
• A RAG chunk from a knowledge base where a small number of entries have been corrupted

The agent's implicit trust model is the core vulnerability. Agents apply scrutiny to user input. They treat retrieved context as information they have already "decided" to consult. This asymmetry makes context window attacks both more reliable and harder to detect.

Research published by Galileo AI found that in multi-agent deployments, a single poisoned context entry can affect 87% of downstream decision-making within four hours, as downstream agents inherit and act on the corrupted context without re-evaluating its origin.

The Four Attack Patterns Documented in Research

Pattern 1: Document Injection

The AgentPoison framework (arXiv:2407.12784) demonstrated this pattern against autonomous driving agents, medical AI systems (EHRAgent), and QA systems. Attackers use constrained optimization to generate trigger phrases that map poisoned documents into unique embedding clusters, ensuring the malicious document is reliably retrieved from the vector store at inference time. Attack success exceeded 80% at less than 0.1% document poison rate, meaning an attacker can compromise a vector store while contaminating fewer than one document per thousand without triggering anomaly detection on document volume.

Pattern 2: Log Contamination

AI SOC agents, incident response systems, and observability-integrated AI assistants frequently ingest log data as context for their analysis. In practice, this means an attacker who can write to any log stream that the agent monitors can inject instructions that appear as log entries. A common pattern is embedding directives in structured fields: a crafted User-Agent header, a JSON payload in an application log, or a synthetic error message that the agent reads as real infrastructure state.

Pattern 3: Conversation History Manipulation

The MemoryGraft attack (arXiv:2512.16962), tested against GPT-4o as the underlying model in MetaGPT's DataInterpreter, demonstrated how attackers supply benign-seeming artifacts during an early session. Those artifacts get stored in episodic memory. In future semantically similar tasks, the memory system retrieves the poisoned procedure template and the agent executes it as if it were a legitimate past workflow. The attack is a form of "time bomb" poisoning: the malicious instruction is separated from its execution by multiple turns or sessions, making correlation difficult.

The eTAMP framework (arXiv:2604.02623) showed 19.5% to 32.5% cross-session exploitation rates, increasing to 8x higher success when agents are deployed with UI friction that discourages user scrutiny of AI outputs.

Pattern 4: RAG Context Contamination

Retrieval-Augmented Generation is the most widely deployed context injection mechanism in enterprise AI, and it is the most commonly exploited. A Prompt Security proof-of-concept achieved 80% attack success against RAG systems using standard embedding models (sentence-transformers/all-MiniLM-L6-v2). The root cause is that traditional content scanning inspects the query, not the retrieved chunks. By the time poisoned content reaches the agent's reasoning phase, it has passed through retrieval without security inspection.

The Morris-II AI worm (arXiv:2403.02817) demonstrated this at scale: a self-replicating adversarial prompt embedded in a RAG-connected input propagated across interconnected AI applications without requiring further attacker interaction.

Why 200K-Token Context Windows Make This Substantially Worse

Claude 3 and GPT-4.5 deployments now support 200,000-token context windows. Gemini 1.5 Pro supports one million tokens. From an adversarial perspective, this is not a capability improvement for defenders, it is a dramatic expansion of the attack surface.

The "needle-in-haystack" problem in AI security is the inverse of the version tested in benchmark research. In benchmarks, a relevant piece of information is hidden in a large context and researchers measure whether the model can find it. In the security context, a malicious instruction is hidden in a large context and defenders need to find it before the model executes it.

Large context windows create specific advantages for attackers:

First, instruction dilution. Adversarial instructions placed in position 50,000 of a 200,000-token context are surrounded by enough legitimate content that keyword-based scanning produces unacceptable false positive rates if tuned to catch them.

Second, attention exploitation. LLM attention mechanisms process all tokens in the context window regardless of their source or position. A hidden instruction in document 23 of 30 retrieved chunks receives the same attention weight as a legitimate instruction in the system prompt.

Third, context stuffing. Attackers can pre-load the context with noise that increases the surface area for plausible deniability: the malicious instruction is syntactically similar to legitimate content in the surrounding material.

Stateless filters, which evaluate individual requests or documents in isolation, cannot address this class of attack. The malicious content is individually benign; the attack emerges from how the model reasons over the combined context.

Why Current Defenses Fail

Most enterprise AI deployments rely on defenses that were designed for LLM01 (prompt injection at the input boundary). Those defenses share a fundamental limitation: they are stateless.

A stateless filter evaluates an individual message, document, or API response in isolation. It looks for known-malicious patterns, applies heuristics, and either allows or blocks the content. This works well when the attack is contained in a single input.

Context window poisoning is a stateful attack. The malicious instruction accumulates across multiple retrieved chunks, memory entries, and tool outputs. Any individual piece might pass inspection. The attack emerges from the combination, interpreted by the agent's stateful reasoning system.

The 84.30% average attack success rate documented by the Agent Security Bench (arXiv:2410.02644) across 27 attack and defense combinations includes runs where content-layer defenses were active. The attacks succeeded because the defenses were applied at the wrong layer.

Defense Architecture: Six Layers Your Team Needs

Layer 1: Pre-ingestion Scanning

Every document, web page, log entry, or external data source must be scanned before it enters the vector store or agent context. Scanning at this layer catches hidden text (white-on-white, zero-font, CSS-hidden text in HTML), prompt injection markers, and anomalous instruction patterns. OWASP LLM08 specifies this as baseline: verify provenance and scan for adversarial content before embedding.

Layer 2: Spotlighting

Microsoft's Spotlighting technique, published at Microsoft Build 2025, addresses the data-instruction confusion problem at the context level. Untrusted content is wrapped in randomized unique delimiters that signal its untrusted origin to the model. Three modes are available: Delimiting (structural separation), Data marking (tagging each chunk with its trust classification), and Encoding (Base64 or HTML entity encoding of untrusted content to distinguish it from instructions). Spotlighting reduces the probability that embedded instructions are interpreted as authoritative directives from the system prompt.

Layer 3: Information Flow Control

Information Flow Control (IFC), formalized in arXiv:2409.19091, applies integrity labels to context chunks throughout the agent's processing pipeline. Chunks from unverified external sources carry an "untrusted" label. Chunks from internal verified knowledge bases carry a "trusted" label. The IFC layer enforces that untrusted-labeled content cannot influence the agent's planning decisions or tool call parameters without explicit authorization. The architecture preserves functionality: the agent can read, analyze, and summarize untrusted content; it cannot be directed by it.

Layer 4: Trust-Level Tagging in RAG

Every chunk in the vector store should be tagged at write time with its provenance: internal documentation, external web source, user-submitted content, third-party API response, or agent-generated summary. At retrieval time, the trust tag travels with the chunk into the agent's context. The model receives explicit metadata about what kind of source each retrieved chunk represents. This does not require model retraining, it is a prompt engineering and retrieval layer configuration that can be deployed against existing RAG architectures.

Layer 5: Behavioral Drift Detection

The SuperLocalMemory Bayesian trust model (arXiv:2603.02240) demonstrated 72% detection rate for sleeper attacks with 10.6ms median search latency, which is compatible with real-time monitoring. In practice, behavioral drift detection means establishing a policy baseline for each agent, what it is authorized to do, what its typical output patterns look like, and what downstream actions it initiates. Deviations from that baseline trigger investigation: unusual API calls, unexpected data access patterns, output policy violations, or stylistic anomalies in the agent's responses that suggest its context has been manipulated.

Layer 6: Architectural Isolation

The structural control is separating agent memory from shared, writable data stores. An agent that writes to a shared memory system creates a propagation vector: one compromised agent can poison the context of all other agents reading that memory. Local-first memory with read-only snapshots for audit, combined with explicit approval gates for memory writes that cross agent boundaries, eliminates the propagation vector that makes context poisoning attacks scale in multi-agent systems.

CVEs and Real-World Incidents That Confirm the Threat

Context window poisoning is not theoretical. Several production systems have had confirmed exploitations:

CVE-2025-68664 (CVSS 9.3) affected LangChain Core via serialization injection in memory writes, allowing attackers to execute arbitrary code through the agent's context processing pipeline. CVE-2025-32711 (CVSS 9.3) affected Microsoft 365 Copilot: a zero-click prompt injection embedded in a document triggered remote data exfiltration without user interaction. CVE-2025-53773 (CVSS 9.6) affected GitHub Copilot, where malicious instructions in code comments hijacked agent behavior during code review tasks.

The 2024 Slack AI incident demonstrated context contamination in production: RAG poisoning combined with social engineering enabled exfiltration of data from channels the attacker had no direct access to. The channel content was retrieved into the agent's context, the poison activated, and data crossed a permission boundary through the agent's output.

In 2026, a mid-market manufacturing firm experienced a compromise of its vendor-validation agent. The agent approved 3.2 million dollars in fraudulent orders before inventory discrepancies triggered human review. The attack worked by corrupting shared approval state in the agent's context through a series of carefully crafted vendor submissions.

Detection and Incident Response for Context Window Attacks

When an agent behaves anomalously, the investigation must account for context manipulation as a root cause. Standard incident response asks: what instruction caused this behavior? Context window poisoning requires an additional question: what context did the agent have access to when it made this decision?

Logging requirements for agentic AI systems must include the full context sent to the model at each inference call, not only the user message. The retrieved chunks, memory entries, tool outputs, and conversation history all constitute the attack surface. Without logging this context, post-incident forensics cannot reconstruct what the agent was told to do or where the instruction originated.

Detection signals to monitor include: tool calls to domains not in the expected allowlist, data access patterns outside the agent's defined scope, output content that references data sources the user did not request, and agent actions that exceed the authorization level of the triggering request.

For immediate response, the recommended procedure is to disable the affected agent, capture and preserve the full context log from the compromised session, roll back any persistent memory writes made during the session, and audit downstream agents that may have received handoffs from the compromised agent before isolation.

Implementation Checklist for Security Teams

Before deploying an agentic AI system that will process external content:

• Pre-ingestion scanning enabled on all data sources entering the vector store
• Spotlighting or equivalent delimiter technique configured for untrusted content blocks
• Provenance tags assigned to every document chunk at write time
• IFC labels enforced: untrusted content cannot direct tool calls or agent planning
• Context logging enabled at inference time (full context, not just user message)
• Behavioral baseline established and drift monitoring active
• Memory write permissions scoped to least-privilege: no agent writes to shared memory without authorization gate
• Cross-agent propagation paths audited: identify all agents that read memory written by other agents
• Incident response playbook updated to include context dump and forensic analysis steps

Why This Is a First-Mover Window

As of August 2026, no major AI security vendor has published a comprehensive enterprise defense guide specifically for OWASP ASI06. HiddenLayer, Lakera, and Prompt Security have content on prompt injection and general LLM security, but none have addressed the specific architecture of context window poisoning at the depth required for enterprise deployment decisions.

That gap is the reason attack success rates remain above 80% in research conditions. The knowledge exists in academic papers. It has not been translated into operational guidance at a level that security architects can act on.

For teams deploying RAG, multi-agent systems, AI SOC tools, or any agentic workflow that processes external content, this is the current highest-priority gap in the AI security program. The defenses described in this guide are available, implementable with current tooling, and do not require waiting for vendor solutions.

Conclusion

Context window poisoning is a documented, high-success attack class that operates below the visibility of most enterprise AI security programs. OWASP ASI06 formalizes the threat. Researchers have demonstrated it at 80%+ success rates. Production CVEs confirm it has reached real deployments.

The defense architecture is known: pre-ingestion scanning, Spotlighting, Information Flow Control, trust-level tagging, behavioral drift detection, and architectural isolation of agent memory. None of these require new tooling categories. They require deliberate configuration of existing AI infrastructure with security objectives in mind.

If your organization is deploying agentic AI that processes external documents, retrieves from shared knowledge bases, or operates as part of a multi-agent pipeline, assessing your exposure to ASI06 should be on the current sprint. Start with a Securetom scan to identify exposed AI endpoints and context injection surfaces, or book an agentic AI security assessment with our team to map the full attack surface before an adversary does.

Authoritative references:

• OWASP 2026 Agentic AI Top 10
• NIST AI Risk Management Framework
• AgentPoison: arXiv:2407.12784
• Agent Security Bench: arXiv:2410.02644
• Information Flow Control for LLM Agents: arXiv:2409.19091
• Morris-II AI Worm: arXiv:2403.02817

Related BeyondScale resources:

• AI Agent Memory Poisoning Defense Guide
• RAG Security and Data Poisoning Guide
• MCP Security Enterprise Guide