Context Poisoning

What Context Poisoning Means in an AI Agent

Context poisoning is dangerous because it targets the material an agent relies on to decide what to do next. Unlike code injection, the malicious payload can be ordinary text, retrieved documents, instructions, or notes that shift the agent’s assumptions, priorities, or tool selection before it acts.

For practitioners, the key point is that the attack surface is not limited to prompts. Any channel that feeds an agent during reasoning, including memory, retrieval, and intermediate context, can become a control point for influence if provenance, isolation, and write rules are weak.

How Poisoned Context Changes Agent Behaviour

Poisoned context works by altering the agent’s interpretation of the task rather than breaking the system directly. The injected material may tell the agent to ignore prior instructions, prefer a malicious tool path, change confidence about a source, or treat unsafe content as trusted background.

This matters most when an agent chains multiple steps. A small change early in the context can cascade into a different retrieval result, a different action plan, or a different external call, which makes the compromise harder to spot than a single obvious malicious command.

Context poisoning also becomes more powerful when the agent reuses context across turns, sessions, or shared memory stores. That persistence means one successful insertion can influence later behaviour long after the original source has disappeared from view.

Where the Risk Comes From

The risk is highest when agents accept untrusted inputs into long-lived memory, retrieval indexes, shared workspaces, or tool-generated notes without strong provenance checks. In those conditions, the system may treat attacker-controlled text as if it were operational knowledge.

The problem is not just theft or corruption of data, but trust inversion. A compromised delivery path can turn low-privilege content into a high-impact behavioural input, especially when the agent has tool access, delegated authority, or the ability to act on behalf of a user or workflow.

When that happens, the practical consequence is behavioural drift, not just content contamination. The agent may expose data, issue unintended actions, or create follow-on decisions that look legitimate because they were produced by the agent’s own reasoning loop.

How to Reduce Exposure and Verify Integrity

Defence starts with treating agent inputs as security-sensitive, not merely informative. Limit who can write to memory or retrieval sources, separate trusted system instructions from untrusted content, and keep provenance visible so the agent can distinguish policy, evidence, and user-supplied material.

Teams should also validate the places where context is assembled. If an agent reads from shared memory, document stores, vector stores, or generated summaries, those sources need the same scrutiny as other trust-boundary crossings because poisoned context often enters through normal business content rather than a classic payload.

For deeper defensive patterns, the AI Agent Memory Poisoning Guide explains how poisoned memory persists and how detection, rollback, and hardening reduce exposure. The companion AI Agent Memory Security Guide focuses on isolation, write controls, and retention discipline for agent memory. For a broader view of the pattern, see the OWASP Agentic Top 10 ASI06 Guide.

Detection and Practitioner Guidance

Context poisoning is often detected by behaviour changes before it is detected by content review. Sudden tool switching, unexpected refusal to follow standing instructions, unusual source preference, or repeated divergence from normal agent outputs can all indicate that the agent has absorbed hostile context.

Why practitioners should care: the defender often sees only the final action, not the poisoned input that caused it. That makes logging, retrieval traceability, and memory review essential for post-incident analysis and for separating prompt failure from compromised context.

Practitioner takeaway: treat every persistent or retrievable context store as a governed trust boundary, and assume that anything the agent can read may eventually influence action unless you constrain it deliberately.

Related resources from NHI Mgmt Group

• Why do context poisoning attacks matter if the model itself is secure?
• How should organisations govern context poisoning in agentic development tools?
• How should security teams stop context window poisoning in AI coding assistants?
• What breaks when context poisoning is not controlled?