The injection of misleading, malicious, or outdated external content into an AI assistant’s working context. In practice, the model may treat that content as trusted reference material and reproduce insecure code, bad instructions, or unsafe decisions without recognising the source is untrusted.
Expanded Definition
External context poisoning is a prompt-adjacent and retrieval-adjacent failure mode where an AI assistant ingests untrusted outside material and uses it as if it were authoritative context. The poisoned content may arrive through web search, RAG pipelines, pasted documentation, tickets, code comments, issue trackers, browser tools, or agent memory. Unlike ordinary misinformation, the risk is operational: the assistant can turn external text into executable guidance, policy advice, or tool actions.
Usage in the industry is still evolving. Some teams treat this as a subset of prompt injection, while others reserve the term for any compromise of the model’s external reference context. For NHI security, the concern is especially acute when agents consume token-based auth flows, infrastructure runbooks, or secrets-handling instructions from outside sources. That makes source trust, retrieval filtering, and provenance checks as important as model accuracy. The most common misapplication is assuming retrieved content is safe simply because it came from a document store or search result, which occurs when provenance and freshness are not validated before the model reasons over it.
For governance context, see NIST Cybersecurity Framework 2.0 and NIST guidance on controlling information sources as part of secure AI operations.
Examples and Use Cases
Implementing protections against external context poisoning rigorously often introduces latency and workflow friction, requiring organisations to weigh answer quality and automation speed against source validation and review overhead.
- An agent summarises an internet forum post that includes outdated API-key rotation steps and then recommends an insecure remediation path.
- A retrieval pipeline surfaces a malicious issue comment that mimics internal runbook language, causing the assistant to trust a false incident procedure.
- A support agent ingests vendor documentation copied into a ticket and repeats deprecated authentication advice for a service account.
- An automation agent reads a poisoned knowledge-base page and generates code that weakens secret handling or logging controls.
- A procurement workflow assistant consumes third-party guidance that misstates identity federation requirements and approves an unsafe integration design.
These patterns map closely to the broader NHI risk landscape described in Ultimate Guide to NHIs, especially where secrets, service accounts, and machine credentials are involved. External context poisoning differs from ordinary hallucination because the model is not inventing content in isolation; it is inheriting misleading context from a source that should have been treated as untrusted. In practice, teams reduce exposure by constraining retrieval scope, tagging approved sources, and requiring human review for sensitive tool actions.
Why It Matters in NHI Security
External context poisoning can turn a harmless-looking assistant into a distribution channel for bad identity and secrets decisions. In NHI environments, that means poisoned guidance can lead to over-permissioned service accounts, unsafe token handling, or invalid rotation steps that prolong exposure. The operational risk is amplified because NHIs often act at machine speed and across multiple systems, so one contaminated instruction can cascade into a broad control failure. NHI Mgmt Group’s research shows that 79% of organisations have experienced secrets leaks, with 77% causing tangible damage, which makes source integrity a practical security issue rather than a theoretical model concern.
Defences usually combine provenance filtering, allowlisted retrieval sources, content freshness checks, and output constraints tied to privilege boundaries. Alignment with the NIST Cybersecurity Framework 2.0 helps organisations treat external context as a controllable asset, not a free-form input. Organisations typically encounter the consequence only after an assistant has repeated a harmful instruction or triggered an unsafe action, at which point external context poisoning becomes operationally unavoidable to address.
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 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Agentic AI guidance covers prompt and context injection into tool-using assistants. | |
| OWASP Non-Human Identity Top 10 | NHI-09 | Context poisoning can drive unsafe handling of secrets and machine credentials. |
| NIST CSF 2.0 | PR.DS-1 | Data integrity controls apply to external content consumed by AI workflows. |
Protect retrieval inputs with provenance checks, source allowlists, and integrity monitoring.
