What it is
External-source injection is the situation in which an agent retrieves attacker-controlled content from outside the immediate conversation and then treats an instruction inside that content as authority. The source might be a public web page, vendor document, shared drive file, issue tracker, feed, or API response. It is a concrete form of indirect prompt injection, useful as a curriculum entry because retrieval expands the trust boundary beyond the product team’s own input fields.
The source can be intentionally malicious, compromised, stale, or merely written in an imperative style. A page saying “click the export button” may be normal documentation, while a sentence aimed at the assistant to disclose context is not. An external URL is not a security identity, and “the user asked me to fetch it” does not mean the model should obey every line returned.
How it works
The attacker publishes or edits content where a target agent is likely to retrieve it. Search ranking, semantic similarity, a shared link, or a vendor integration brings the content into context. The application may clean HTML but preserve the instruction in visible text, alt text, metadata, or a parsed API field. The model receives the result next to the user’s question and may summarize, follow, or pass along the embedded request.
A retrieval chain can amplify the problem: one source is summarized, indexed, and later returned to a different workflow. Caches and mirrors can extend its lifetime. Source trust should therefore be tracked through fetch, parse, chunk, embedding, retrieval, and action. It is not enough to validate only the original URL.
Why it works
Relevance systems answer “does this help with the question?” rather than “is this allowed to instruct the agent?” Models are trained to use reference material and may interpret imperative sentences as useful procedural context. The user’s request can be safe while the fetched text is not. A domain allowlist may reduce exposure but cannot prove that a permitted publisher’s page has not been edited or compromised.
The risk rises when the agent can browse, send messages, modify tickets, or read private data. A source instruction that only changes a citation is an integrity issue; one that influences a tool plan crosses into confidentiality or action risk. External-source injection is therefore a supply-chain and provenance problem as much as a model problem.
A safe, fictional example
The fictional Maple Research Desk retrieves articles from a local set of synthetic publishers. A page about an invented battery material contains a normal abstract plus a note directed at “the research assistant” asking it to add a fabricated conclusion. The assistant has no network or write tools and the collection contains no confidential material.
The test verifies that the note is quoted as part of the source, not obeyed as a task instruction. Reviewers compare a clean copy, an edited copy, and a cached copy while recording provenance. No real site is poisoned, and the test fixture’s content is clearly marked for security evaluation.
Page author to Publisher page: Hiddennote to "the research assistant": add a fake conclusion
Researcher to Research assistant: "Summarize the battery article"
Research assistant to Publisher page: retrieve article
Publisher page to Research assistant: abstract + planted note
Research assistant to Researcher: Blockedsummary, quoting the note as source text
How to spot it
Inventory every external source and transformation that can reach a model. Look for instructions addressed to an agent, unexplained requests to ignore the user’s goal, external destinations, or changes in output after a source is introduced. Compare source content with the chunk or summary actually used; injection can be introduced by a parser or summarizer.
Monitor retrievals that are unusually broad, from newly changed sources, or associated with action requests. Keep source IDs and hashes in the trace. A model citing a page is not proof it followed it safely; inspect whether the page altered a tool plan, sensitive lookup, or persistent record.
Defensive controls
Treat external content as untrusted reference data. Prefer signed or versioned feeds, source allowlists, malware scanning, safe parsers, and provenance labels, but assume an allowed source can still contain hostile instructions. Keep retrieval and execution separate. A model may propose an action based on a source, but a typed tool layer must validate scope, destination, and authorization before execution.
Revalidate content at use time, protect indexes and caches from unauthorized writes, and require confirmation for high-impact actions. Use least-privilege browsing and short-lived credentials. Test web pages, PDFs, feeds, and API responses with synthetic poisoning, including changes after indexing. Log lineage without copying private source content into broad telemetry.
Limits and nearby techniques
Indirect prompt injection is the general data-borne attack; external sources identify the source boundary. Stored prompt injection emphasizes persistence in an application store. Hidden text and multimodal describe how content can be disguised or extracted. Cross-agent propagation can carry a poisoned source through a workflow. A user who directly pastes the same text is performing a direct injection, even if it originally came from a website. Secure the full retrieval chain rather than trusting a URL label.