Indirect prompt injection happens when malicious instructions are hidden inside content that a retrieval-augmented generation or agent system pulls in from an external source, such as a web page, a PDF, an email, or a shared document, rather than being typed directly by the user attacking the system. Because the model treats retrieved content as context to reason over, it can be tricked into following instructions buried in that content, for example a webpage containing hidden text instructing the model to exfiltrate data or take an unauthorized action the next time an agent visits it. This is more dangerous than direct prompt injection because the attacker never interacts with the target system; they only need to plant content somewhere the AI system will eventually retrieve, making it a supply-chain-style risk for any agent that browses the web or reads shared files. Defenses include treating all retrieved content as untrusted data rather than instructions, stripping suspicious formatting before it reaches the model, tagging content with its source and trust level, and restricting what actions an agent can take automatically based on retrieved content rather than a verified user's own input. Output and action confirmation for sensitive steps adds a further check. Nanobase AI designs RAG and agent pipelines with this untrusted-content boundary built in from the start.
The attacker never touches your input box
Indirect prompt injection inverts the usual threat model. In direct injection, the attacker is the user typing into the system. In indirect injection, the attacker plants malicious instructions inside content that a RAG pipeline or agent will later retrieve and feed to the model, such as a web page, a shared document, an email, or a support ticket, and the legitimate user simply triggers a workflow that happens to pull in that poisoned content. This makes indirect injection harder to defend against with input filtering alone, since the malicious text never passes through the application's normal input validation path at all.
Where poisoned content typically enters
| Retrieval source | How an attacker plants the payload |
|---|---|
| Public web pages fetched by a browsing-enabled agent | Hidden text, white-on-white or off-screen, containing instructions for the model |
| Shared documents ingested into a RAG knowledge base | A document uploaded to a shared drive containing embedded instructions |
| Incoming emails processed by an email-handling agent | An email body crafted to instruct the agent to forward, delete, or exfiltrate data |
| Third-party API responses consumed by a tool-using agent | A compromised or malicious API returning instruction-laden text as if it were data |
| Customer-submitted support tickets later summarized by an LLM | A ticket body designed to manipulate the summarization or routing step |
Any point where content from outside the application's direct control reaches the model's context window is a potential indirect injection vector. Every external content source feeding an LLM's context, not just user input, has to be treated as a potential attack surface.
Defenses specific to retrieval and agent architectures
- Treat all retrieved content as untrusted by default, applying the same delimiter-and-instruction pattern used for direct injection, explicitly telling the model that retrieved text is data to summarize or reference, not instructions to follow.
- Scan ingested documents for injection patterns at ingestion time, before they enter a vector database, rather than only at query time.
- Apply strict least-privilege tool permissions to any agent that can act on retrieved content, so a successful injection cannot escalate into an unauthorized action like sending data externally.
- Require explicit confirmation for consequential actions, such as sending an email or modifying a record, that an agent proposes to take based on retrieved content.
- Monitor and log agent tool calls, flagging unusual sequences, like an agent that was asked to summarize a document but attempts to call an email-sending tool.
The tool-permission layer matters more for indirect injection than for direct injection, because the attacker's goal in agent systems is usually to trigger an unauthorized action, not just to produce a bad text response.
Why RAG knowledge bases need ingestion-time hygiene
A RAG system is only as trustworthy as the documents it indexes, and organizations frequently underestimate how much content in a shared knowledge base originated outside their direct control, including vendor documents, customer submissions, or scraped web content. Running an injection-pattern scan during ingestion, before content is embedded and stored, catches a meaningful share of attempts before they ever reach a live query, and re-scanning periodically catches content that was benign at ingestion time but has since been edited by someone with write access to the source. A RAG knowledge base is only as trustworthy as its least-scrutinized contributor, which makes ingestion-time scanning a necessary control, not an optional one.
Frequently asked questions
Is indirect prompt injection more dangerous than direct injection?
It is generally considered higher risk in agent systems because the compromise vector bypasses normal user-input scrutiny and because agents with tool access can turn a successful injection into a real-world action, such as data exfiltration, rather than just an unwanted response.
Can output filtering alone stop indirect injection?
No. Output filtering catches some downstream signs of a successful injection, like a response containing content that shouldn't be disclosed, but it does not prevent the injection from occurring or from triggering an unauthorized tool call before any output is even generated.
Does this apply to internal-only RAG systems, or just public-facing ones?
It applies to both. An internal knowledge base fed by employee-uploaded documents or shared drives carries the same risk if any contributor, intentionally or through a compromised account, can add a document containing injected instructions.
How does this relate to the broader OWASP LLM security guidance?
Indirect prompt injection is explicitly called out as a top risk category in the OWASP Top 10 for LLM applications, which also covers related risks like insecure output handling and excessive agency that compound the impact of a successful injection.
How Nanobase AI helps
Nanobase AI builds RAG and agent architectures with ingestion-time content scanning, least-privilege tool permissions, and action-confirmation steps designed specifically to contain indirect prompt injection. This is part of our AI security and compliance work, closely tied to our experience with MCP server integrations that connect LLM agents to real enterprise systems and data.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.