What should teams do about indirect prompt injection in RAG systems?

Why This Matters for Security Teams

indirect prompt injection in retrieval-augmented generation is not a model-quality issue alone. It is an authorization problem created when untrusted text from documents, tickets, web pages, or knowledge bases can influence agent behavior. In RAG systems, the model may faithfully retrieve the right context and still follow a malicious instruction hidden inside that context. That is why guidance from the OWASP Agentic AI Top 10 increasingly treats prompt injection as a control failure, not just a content-safety concern.

For NHI and agentic AI governance, the risk is broader than a single bad answer. A compromised retrieval path can steer tool use, exfiltrate secrets, or trigger unsafe actions through an otherwise legitimate workflow. NHI Mgmt Group notes that 97% of NHIs carry excessive privileges, which is exactly the condition that turns a poisoned retrieval into a real incident. The practical lesson is simple: retrieved content must be treated as hostile until proven otherwise, especially when agents have execution authority. In practice, many security teams encounter prompt injection only after an agent has already searched, summarized, or acted on the poisoned content.

How It Works in Practice

The core defense is to separate information retrieval from instruction execution. A RAG pipeline should not assume that every retrieved passage is safe just because it came from an approved source. Instead, the system should classify content, inspect it for instruction-like patterns, and constrain what the model can do with it. That usually means combining document provenance, content filtering, and scoped tool permissions.

Current guidance suggests a layered approach:

• Limit retrieval to trusted sources and enforce provenance metadata so the system knows where content came from.
• Strip or flag instruction-like language in retrieved passages, especially commands aimed at the model, tool calls, credential requests, or policy overrides.
• Use separate system instructions that explicitly tell the model to ignore embedded instructions inside retrieved content.
• Constrain tools with least privilege, so even a successful injection cannot reach secrets, admin APIs, or destructive actions.
• Apply runtime policy checks before every tool call, rather than assuming the model’s prior context is safe.

This is where agentic governance overlaps with NHI control. If a retrieval path can cause the model to request secrets or act on behalf of a service identity, then the workload identity and permission model matter as much as the prompt layer. NHI Mgmt Group’s Ultimate Guide to Non-Human Identities underscores how often excessive privilege and poor visibility widen blast radius. The practical outcome is that teams should pair retrieval hardening with short-lived credentials, narrow tool scopes, and logging that captures which retrieved items influenced which actions. These controls tend to break down when the agent can chain multiple tools across loosely governed systems because the attack path moves faster than human review.

Common Variations and Edge Cases

Tighter retrieval filtering often increases false positives, so teams have to balance safety against recall and answer quality. There is no universal standard for exactly how much content inspection is enough, and current guidance suggests tuning controls to the risk of the workload rather than applying one fixed threshold everywhere.

Edge cases matter most in high-autonomy environments. For example, a customer-support agent that only drafts responses may tolerate stricter filtering than a workflow agent that can open tickets, query internal systems, or trigger changes. Hybrid setups are also tricky: if content passes through embeddings, chunking, and re-ranking before generation, the original malicious instruction may be obscured but still influential. That is why OWASP’s agentic application guidance and NHIMG’s NHI governance research both point toward runtime controls, not only pre-ingestion hygiene.

Another common failure mode is overtrusting internal data. Indirect prompt injection often hides inside documents that are “approved” by business owners but not security-reviewed for machine interpretation. Best practice is evolving toward content labeling, higher-risk handling for external or user-generated sources, and explicit denial of tool access when the retrieval confidence is low. In practice, these controls matter most when the system must operate on mixed-trust corpora with broad tool reach and minimal human oversight.

Related resources from NHI Mgmt Group

• How should security teams test for visual prompt injection in multimodal AI systems?
• How should security teams reduce indirect prompt injection risk in AI systems?
• What do teams get wrong about indirect prompt injection?
• What do teams get wrong about similarity scores and prompt rules in RAG systems?