Context Poisoning: How Bad Context Breaks AI Agents

What is context poisoning in AI?

According to an MIT report, 95% of enterprise AI pilots deliver zero measurable ROI. And as in several previous scenarios, the usual suspects got the blame: the wrong model choice, poor prompt design, and insufficient training data. But a growing body of evidence points to a different root cause. Agents perform poorly when the information filling their context window is incorrect or outdated. This forms the basis of context poisoning.

Context poisoning is where the context an AI agent relies on — definitions, lineage, governance rules, and retrieved documents — is inaccurate, and the agent treats it as the ground truth. This results in confident actions from the agent, but incorrect and inconsistent outcomes.

There are two types of context poisoning: adversarial poisoning, in which an attacker deliberately manipulates context, and accidental poisoning, in which legitimate metadata decays through neglect. Most coverage focuses on the first. But in enterprise AI systems and agentic workflows, the second is far more common.

What are the types of context poisoning?

The security community has extensively documented adversarial context poisoning. The enterprise context engineering community is just starting to understand the accidental kind.

Adversarial context poisoning

Adversarial poisoning is deliberate. An external or internal attacker manipulates the context an agent consumes to alter its behavior. OWASP now ranks context poisoning (also known as memory poisoning) as a top agentic risk for 2026.

The main attack vectors:

• Prompt injection: Malicious instructions embedded directly in user input that override the agent’s system prompt
• Indirect injection via retrieved documents: A vendor PDF or web page contains hidden instructions that the agent ingests as legitimate context during retrieval
• Tool description poisoning: In MCP-connected systems, a tool’s metadata contains invisible directives that alter agent behavior without the tool ever being executed
• Memory poisoning: Malicious content injected into an agent’s long-term memory persists across sessions, corrupting future decisions weeks or months later

These are real, well-documented threats worth defending against. But they share a common trait: the outputs are often detectably wrong.

Accidental context poisoning

Accidental poisoning is quieter and more pervasive. The context is legitimate and non-malicious. It is just wrong.

A business glossary where the definition of “ARR” has not been updated since finance changed the calculation methodology last quarter. A data lineage path that still references a column renamed three months ago. A metric that Snowflake calculates one way and Tableau calculates another, with no canonical source of truth.

Context poisoning does not happen because of an attacker, but because of metadata that nobody maintains.

Why is accidental context poisoning harder to catch?

Adversarial poisoning breaks things visibly. An agent that starts exfiltrating data or messing with internal company policy triggers alarms, and the security team immediately gets to work. Accidental poisoning does something worse: it produces outputs that look right.

The agent sounds confident. It cites real tables and columns. It applies recognizable business logic. The quarterly revenue number it returns is specific and precise. It is just calculated using last quarter’s definition, or pulling from the wrong upstream source, or missing a product category that was added two months ago. The answer is close enough to pass review. That is what makes it dangerous.

Smarter models amplify the problem. Better reasoning applied to a stale glossary does not produce errors. It produces sophisticated analysis built on outdated information. The more capable the model, the more convincingly wrong the output.

What are the four sources of accidental context poisoning in an enterprise?

Accidental poisoning does not come from a single source. It enters through four systemic gaps in how enterprises manage context.

Schema changes are not propagated to the context layer

Data engineering renames customer_type to account_tier in Snowflake. The business glossary still references customer_type. The semantic model built on that glossary still maps to the old column name.

• What breaks: The agent queries a field that no longer exists, or silently maps to a different column, or starts hallucinating and makes up its own data
• Why it persists: Schema changes are tested at the pipeline level, not at the context layer. The migration passes. But the glossary stays stale.
• How often does it happen: Every major schema change that does not trigger a context review

Business logic changes were not captured

Finance redefines “ARR” to exclude one-time implementation fees. Marketing launches a new product category. The fiscal year shifts from calendar to April-start. The business context layer still reflects last quarter’s logic.

• What breaks: The AI analyst reports ARR using the old calculation. The number looks right, but it does not align with how ARR is currently calculated.
• Why it persists: Business logic changes happen in meetings, emails, and policy documents. They rarely trigger a glossary update.
• How often does it happen: Every quarter in fast-moving enterprises

Ownership gaps

A definition was last certified by an analyst who left the company 18 months ago. Nobody inherited ownership. Nobody is responsible for reviewing whether it is still accurate.

• What breaks: The definition drifts silently. No one is accountable for catching the staleness.
• Why it persists: Ownership is assigned at creation, not maintained as a living responsibility.
• How often does it happen: During employee transitions in an enterprise setup

Cross-system inconsistency

Snowflake and Tableau calculate “customer health score” differently. The CRM defines “active customer” by login recency. The billing system defines it by payment status. A single renewal decision requires context from six or more systems, each with its own partial truth.

• What breaks: The agent pulls from different sources for different queries and returns internally contradictory answers
• Why it persists: Each system was built with its own definitions. No shared semantic layer enforces canonical meaning.
• How often does it happen: For every query that spans more than one system of record

How do you detect context poisoning before it reaches your agents?

The key to detecting accidental context poisoning is constant monitoring of the internal elements that make up your organization’s context layer. Here are four signals that indicate the onset of accidental context poisoning:

• Schema version staleness: How long since each schema definition was validated against its upstream source? A definition validated six months ago against a table that changed last week is a poisoned context.
• Glossary definition age: When was each business term last reviewed by its owner? Definitions untouched for 6+ months in a fast-moving enterprise are at high risk.
• Lineage completeness: Are there breaks in the lineage path between the source system and the context the agent consumes? Every gap is an undetected opportunity for poisoning.
• Ownership freshness: Does every definition have an active owner? The moment ownership lapses, your unowned definitions start to drift.

Research suggests that context drift, the upstream cause of accidental poisoning, contributes to approximately 65% of enterprise AI agent failures.

How does Atlan help prevent context poisoning?

Preventing context poisoning requires a system that continuously monitors every element feeding your agents. Schema mappings, glossary definitions, lineage paths, and ownership records can all go stale between audits, and agents will not know the difference.

Atlan is built to serve as an enterprise context layer for AI. It provides automated drift detection across each of those elements, so your agents run on current definitions rather than stale ones.

• Active metadata platform: Context is continuously enriched from usage patterns, lineage signals, and data quality checks — not static documentation that decays the moment it is written
• Context drift detection: Automated freshness scoring across schema, glossary, lineage, and ownership signals catches staleness before it reaches agents
• Context Repos: Versioned, policy-embedded units of context that agents consume via MCP or API, with built-in invalidation when upstream definitions change
• Context Studio: The workspace where teams bootstrap, test, and continuously improve the context layer that agents rely on

Wrapping up

The adversarial version of context poisoning gets the headlines: prompt injections, malicious payloads, OWASP risk classifications. In enterprises, the more common failure is accidental context poisoning — quieter and often undetected. Stale definitions, unowned glossary terms, and metrics that different systems calculate differently produce outputs that look right, pass review, and inform decisions nobody can walk back. Smarter models make that harder to detect, while producing confident and incorrect outcomes.

The fix is not a more capable model or a larger context window. More context surface area does not reduce poisoning risk. It expands it. The answer is a context layer that is governed, continuously monitored, and owned by someone, so staleness gets caught before it reaches a query, not after it has already informed a decision.

FAQs about context poisoning

1. Is context poisoning the same as prompt injection?

Prompt injection is a form of adversarial context poisoning in which malicious instructions are embedded in user input to override an agent’s behavior. Context poisoning is a broader concept that also encompasses accidental poisoning due to stale, inconsistent, or ungoverned metadata. In enterprise environments, the accidental kind is more common and often harder to detect because the outputs appear plausible rather than obviously wrong.

2. Can you prevent context poisoning with better prompts?

Prompt engineering can add validation instructions, asking the agent to check sources or flag uncertainty. But it cannot fix the upstream context. If the business glossary feeding the agent defines “ARR” using last quarter’s methodology, no prompt will correct that. The poisoning happens at the metadata layer, before the prompt is ever constructed. Prevention requires governing the context itself.

3. How common is accidental context poisoning in an enterprise?

Research indicates that context drift contributes to approximately 65% of enterprise AI agent failures. Every enterprise with multiple systems defining the same business concepts has some degree of cross-system inconsistency. The question is not whether accidental poisoning exists in your organization — it is whether you are detecting it before it reaches your agents.

4. What is context drift detection?

Context drift detection is the practice of continuously monitoring the metadata layer for staleness, inconsistency, and ownership gaps. It tracks four signals: schema version staleness, glossary definition age, lineage completeness, and ownership freshness. Unlike model drift monitoring, which watches for statistical shifts in model outputs, context drift detection operates upstream, catching problems in the definitions and relationships that feed the model before any inference runs.

5. Does a larger context window reduce the risk of context poisoning?

No. A larger context window increases the surface area for poisoning. More context means more opportunities for stale, conflicting, or ungoverned information to enter the agent’s reasoning. The fix is not a bigger window but a more governed one.