Data source poisoning happens when an AI agent receives manipulated or malicious external content that alters its reasoning or output. In MCP environments, the risk is not only in code flaws but also in what data the server connects to and returns, especially when source validation and trust boundaries are weak.
Expanded Definition
Data source poisoning is the manipulation of external content, retrieval data, or upstream signals so an AI system reasons from false, skewed, or adversary-shaped input. In agentic and retrieval-augmented environments, the weakness is often not the model itself but the trust placed in the data path that feeds it.
It differs from prompt injection in scope: prompt injection targets the instructions the model sees, while data source poisoning corrupts the evidence, context, or reference material the system treats as trustworthy. In MCP-based workflows, that boundary matters because the server can widen or narrow what the agent can see, and poisoned sources can quietly shape decisions even when code is unchanged. The industry is still evolving on terminology, so usage may overlap with terms like retrieval poisoning, corpus poisoning, or source tampering. The practical boundary is whether the malicious influence enters through data the system relies on rather than through model weights or direct prompt text.
Examples and Use Cases
Data source poisoning appears wherever an AI agent consumes external content with limited validation or provenance checks. The exact mechanism varies, but the pattern is the same: the system trusts input that should have been treated as untrusted.
- An internal assistant retrieves policy text from a shared knowledge base, but a poisoned page changes the meaning of an approval rule.
- A customer-support agent reads product documentation from a synced repository and follows a maliciously altered support article.
- An MCP server connects the agent to a third-party data source, and the returned records include deceptive or manipulated fields that steer the agent’s output.
- A search-backed workflow ingests public web pages, and an attacker plants content designed to bias summaries, recommendations, or triage decisions.
- A procurement or finance agent relies on upstream records, and poisoned source data causes a false confidence in prices, vendors, or authorizations.
The tradeoff is convenience versus trust. The broader the data ingestion surface, the easier it is to keep agents useful, but the harder it is to preserve provenance, freshness, and integrity. For NHI-heavy environments, the OWASP Non-Human Identity Top 10 is a useful reference when the poisoned source depends on machine credentials, service access, or delegated trust.
Security Implications
When data source poisoning succeeds, the system may produce confident but incorrect outputs, route actions toward the wrong target, or propagate falsehoods into downstream workflows. The risk is especially serious when agents can act on retrieved content without a human re-checking provenance or context.
Failure mechanism: poisoned data exploits weak source validation, overbroad trust in retrieval pipelines, or insufficient segregation between authoritative and non-authoritative content. In practice, the agent treats manipulated content as evidence, then extends that error into decisions, summaries, ticketing, access requests, or automated actions.
Impact: organisations can see corrupted recommendations, misrouted approvals, incorrect operational decisions, and persistent contamination across shared knowledge systems. In NHI-centric workflows, the blast radius can extend through service accounts and API keys that fetch the poisoned content in the first place, amplifying exposure over time. NHIMG reports that 79% of organisations have experienced secrets leaks, with 77% of those incidents resulting in tangible damage, which is a useful reminder that trust failures around machine-accessed content often become business-impacting events.
Domain and Governance Relevance
In agentic AI and NHI governance, data source poisoning is a trust-boundary problem. The key question is not only whether the model is accurate, but whether the data it reads is governed with enough provenance, ownership, and review to deserve that trust.
This matters most when non-human identities retrieve, transform, or redistribute content at scale. If a service account, API key, or MCP-backed connector can access a poisoned source, the resulting error can look like a normal system response and evade casual review. That makes source inventory, connector governance, and content provenance part of machine-identity assurance, not just AI hygiene. The issue also shapes incident response: teams need to trace which agent, connector, or workload consumed the manipulated source and what decisions it influenced.
For NHI Management Group, the practical lesson is that trust in machine-readable content must be governed with the same seriousness as trust in machine credentials.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | LLM-01 — Prompt Injection | Data poisoning and poisoned context often shape agent output through trusted inputs. |
| LLM-03 — Data Poisoning | Directly addresses corrupted training or retrieval data that misleads AI systems. | |
| Recommendation — Validate retrieved content and isolate untrusted inputs before the agent uses them. Verify data provenance and integrity for every source the agent consumes. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Discovery and Inventory | Source poisoning is harder to govern when connectors and machine identities are untracked. |
| NHI-02 — Secrets and Credential Management | Poisoned sources are often fetched through API keys, tokens, or service accounts. | |
| Recommendation — Inventory every machine identity and data connector that can reach trusted content. Protect retrieval credentials so poisoned sources cannot be reached through excessive access. | ||
| CIS Controls v8 | 13 — Data Protection | Data integrity and source trust are central to preventing manipulated content from spreading. |
| Recommendation — Classify and protect authoritative data sources with integrity checks and access controls. | ||
| MITRE ATT&CK | T1565.001 — Stored Data Manipulation | Poisoning a source is a form of manipulating stored content to influence downstream use. |
| Recommendation — Hunt for unauthorized edits to knowledge bases, repositories, and other trusted stores. | ||
