Agent Context Poisoning: Detection and Controls
Agent context poisoning is the manipulation of data an AI agent ingests at runtime, through retrieval, tool outputs, persisted memory, or inter-agent messages, to alter its behavior or trigger unauthorized actions. It differs from single-turn prompt injection because it targets the assembled context an agent builds across a session rather than a single user-to-model instruction, and it can persist across sessions when written into memory or vector stores. Mitigation relies on trust segregation of context sources, provenance tracking, least-privilege tool access, and runtime policy checks between agent reasoning and tool execution.
Trust boundaries across the agent pipeline
Content entering an agent's context carries different levels of trust depending on its origin. Treating all of it uniformly is the underlying design gap that context poisoning exploits.
- 1
System instructions
Highest trust; defined by the deploying organization and should not be overridden by lower-trust content.
- 2
User input
Direct user-supplied instructions; subject to standard prompt injection defenses.
- 3
Retrieved content
Documents, search results, or RAG corpus entries; the most documented vector for indirect injection per OWASP and MITRE ATLAS.
- 4
Tool and inter-agent output
Function call results and agent-to-agent messages; structurally similar to retrieved content but often less scrutinized since it is machine-generated.
Where context poisoning enters the agent pipeline
These four sources correspond to the trust boundaries above and are the practical points where manipulated content is introduced into an agent's working context.
Retrieval (RAG)
Malicious content inserted into documents or vector stores later pulled into context.
Tool output
Function or API responses treated as trusted context after a tool call.
Persisted memory
Injected content written into long-term memory, surviving across sessions.
Multi-agent messaging
Instructions propagated between agents without integrity checks.
Definition and distinction from prompt injection
Prompt injection, as defined in OWASP's Top 10 for LLM Applications, is typically framed as direct (user-supplied instructions) or indirect (instructions embedded in external content the model processes). Agent context poisoning is best understood as a structural extension of indirect prompt injection into the full agent execution pipeline. Rather than a single malicious instruction in one prompt, context poisoning involves manipulated data entering any of the sources an agent assembles into its working context: retrieved documents, tool call results, stored memory, or messages from other agents.
The distinction matters operationally. A single-turn jailbreak defense that inspects the initial user prompt will not catch a poisoned document retrieved three steps into an agent's task, or a manipulated tool response that alters the agent's next action. Context poisoning requires controls at every point where content enters the context window, not just at the initial input boundary.
Why this matters for agentic systems specifically
Agents differ from single-turn chat interactions in two ways that expand the attack surface. First, they ingest content from multiple sources across a session (search results, documents, API responses, memory records) and generally treat all of it as part of a uniformly trusted context window. Second, they take actions based on that context, including tool and function calls, which OWASP categorizes under insecure plugin design and excessive agency.
When poisoned context influences an agent's reasoning, the consequence is not limited to a bad text response. It can result in an unauthorized tool invocation, data exfiltration through a crafted output, or a persisted instruction that affects future sessions. MITRE ATLAS catalogs this pattern under adversarial techniques including prompt injection and retrieval-store poisoning, treating it as a supply-chain style risk against the data feeding the model rather than a purely conversational exploit.
Detection signals
No single authoritative standard currently defines detection methods specifically for agent context poisoning; guidance is synthesized from provenance and traceability principles in NIST's Generative AI Profile, indirect injection detection in OWASP, and adversarial technique tracking in MITRE ATLAS. In practice, the strongest detection signals available today center on provenance and anomaly patterns rather than content-level classification alone.
- Provenance tracking: tagging each piece of context with its source and trust level at ingestion, allowing downstream systems to flag content that lacks expected attribution or originates from an unverified source.
- Anomaly detection at the context-assembly layer: logging what sources contributed to a given agent turn, helping identify unexpected inputs, such as a tool response containing content that resembles an instruction rather than data.
- Integrity checks on memory and vector stores: including versioning, which can reveal unauthorized modification consistent with poisoning attempts that persist across sessions.
Combine signals; do not rely on filtering alone
These signals work best in combination, since content-based filtering alone is explicitly acknowledged by OWASP as an imperfect control.
Runtime controls that limit impact once detected
Detection reduces uncertainty, but enforcement is what limits damage. The following controls, drawn from OWASP, NIST, and CISA/NSA joint guidance, apply directly to agentic systems: trust segregation of context sources, provenance tracking carried through to the reasoning step, least-privilege tool access scoped to what a given task actually requires, and runtime policy checks inserted between agent reasoning and tool execution rather than only at input time.
Governance context and tradeoffs
There is currently no dedicated regulatory standard addressing agent context poisoning as its own category. Existing guidance, including OWASP's LLM Top 10, NIST's AI Risk Management Framework Generative AI Profile, NIST SP 800-218A, and CISA/NSA joint guidance on deploying AI systems securely, treats it as a subset of prompt injection and AI supply-chain risk. OWASP's guidance is widely referenced in enterprise security assessments but functions as industry consensus rather than a compliance mandate.
Organizations building governance programs around this risk should expect to map controls to existing frameworks (provenance and traceability under NIST AI RMF, zero-trust access under CISA/NSA guidance) rather than a single agent-specific standard. A practical tradeoff is that stricter trust segregation and approval gating reduce agent autonomy and speed; teams need to calibrate control strength against the actual blast radius of each tool or memory store an agent can reach.
Common questions
Is agent context poisoning the same as prompt injection?
It is related but distinct. Prompt injection, as defined by OWASP, covers direct and indirect manipulation of model input. Context poisoning extends this across an agent's full pipeline, including retrieval, tool output, memory, and multi-agent messages, rather than a single prompt.
Can context poisoning persist across sessions?
Yes, when malicious content is written into long-term memory or a vector store, it can be retrieved and acted on repeatedly across future sessions, unlike single-turn prompt injection which typically affects only the current interaction.
What is the most documented vector for context poisoning today?
Indirect prompt injection through retrieved documents in RAG systems is the most formally documented vector in OWASP and MITRE ATLAS taxonomies. Tool-output and multi-agent vectors are structurally similar but less formally standardized.
Does input filtering alone solve this problem?
No. OWASP explicitly notes that content filtering is an imperfect control. Effective mitigation combines provenance tracking, trust segregation, least-privilege tool access, and runtime policy checks before tool execution.
Reduce the blast radius of poisoned agent context
Trussed AI provides runtime governance for AI agents, including policy enforcement, least-privilege tool permissions, and audit logging to constrain what compromised context can actually do.
Explore Runtime Governance