Context
A retrieved document can contain useful facts and malicious instructions in the same paragraph. If a RAG application lets that paragraph redefine its task or authorize a tool call, the document has crossed a trust boundary. The application must treat retrieved content as evidence to interpret, while authorization remains with the authenticated user and server-controlled policy.
Consider an illustrative support assistant that searches customer documents and can create a ticket. One uploaded document tells the assistant to export other tenants' records before answering. The malicious instruction may look like ordinary prose in the knowledge base. Better prompting helps, but the decisive protection is that the tool cannot perform an unauthorized export regardless of what the model proposes.
Map the actual trust boundaries
OWASP describes indirect prompt injection through external content, RAG poisoning risks, and the need for layered controls around retrieval and agent tools. Its guidance includes access control, scoped capabilities, output handling, and adversarial validation. No single text filter or prompt wording should be presented as a complete prevention guarantee. 123
Draw the path from document ingestion to retrieval, model context, proposed action, and server execution. Identify which fields come from an authenticated session, which come from trusted configuration, and which can be influenced by document authors. Keep these sources distinct in code and review.
Enforce document access before the model sees content
Apply tenant and user authorization in the retrieval layer using server-derived context. A model should not decide which tenant identifier to attach to a search based on a document or an arbitrary tool argument. Verify that search, document fetch, citations, and download endpoints use the same access boundary.
Keep authorization metadata tied to the document lifecycle. A reindexed or copied chunk should not lose its access restrictions. Test a document whose permissions change after ingestion and verify that future retrieval follows the current policy. Retrieval quality and access correctness are separate acceptance criteria.
Keep tool permission independent of model persuasion
Every tool execution should validate the authenticated actor, allowed operation, resource scope, and argument constraints on the server. Treat a model-generated request as a proposal, not as proof of authority. Derive sensitive context such as tenant ownership from the session or another trusted source.
Use separate capabilities for reading information and changing external state when that clarifies the boundary. A support-answering assistant rarely needs unrestricted administrative access. Keep credentials outside the model context and ensure logs or tool errors do not reveal them. A prompt cannot protect a secret that the application unnecessarily exposes as ordinary text.
Make consequential actions reviewable
For actions requiring approval under the product's intended workflow, show the concrete target and proposed change. Bind execution to that reviewed action rather than allowing a later model step to substitute another destination or payload. The confirmation mechanism should be part of the application contract, not an improvised chat phrase.
Do not add human approval to every harmless read just because the system uses AI. Choose controls according to the action's consequence and the user's authorization. The useful boundary is precise: which action can happen automatically, which needs review, and which is never available to this assistant.
Handle output as untrusted application data
Validate structured tool arguments and escape rendered text for its destination. A retrieved document can contain HTML, misleading links, or content that becomes dangerous when copied into another system. Keep citations tied to the actual retrieved source and do not let document text invent a trusted source identity.
If the assistant proposes a command or configuration change, route it through the product's normal review and execution controls. A fluent explanation does not establish that a command is appropriate for the target environment. Preserve the distinction between advice and an authorized mutation.
Test attacks alongside legitimate document use
Build a controlled test set containing normal documents, conflicting instructions, malicious tool requests, and content that tries to change tenant context. Include indirect forms such as quoted instructions or misleading support notes. Keep the test within owned systems and harmless data.
Measure whether unauthorized actions are rejected by server policy even when the model attempts them. Also verify that legitimate answers remain useful and cite the correct documents. A system that rejects every retrieved paragraph may avoid some attacks while failing its actual product purpose.
Observe decisions without collecting excess content
Record the retrieval scope, document references, proposed tool, authorization result, and final action identifier where appropriate. Avoid retaining entire sensitive prompts by default. Use a deliberate debug policy for investigations with restricted access and a defined retention period.
Track denied cross-tenant actions and unexpected tool requests as leads for review, while recognizing that a detector can have false positives. The most useful evidence shows which enforced boundary stopped the action. Do not describe a model refusal alone as proof that every application path is secure.
Keep the boundary stable through product changes
Review new tools, connectors, ingestion sources, and memory features before enabling them. A previously read-only assistant can acquire materially different risks when given write capabilities. Repeat the relevant tests after model or orchestration changes without assuming the same prompt produces identical behaviour forever.
A focused operator exercise: A harmless cross-tenant injection test
Place a controlled document in tenant A's test knowledge base containing an instruction to request a harmless marker from tenant B. Ask an authorized tenant A user a question that retrieves the document. Observe retrieval scope, any proposed tool arguments, and the server's authorization decision without exposing real customer data.
The critical acceptance result is that tenant B's marker cannot be retrieved or acted on through the application boundary, even if the model follows the injected suggestion. Also verify a normal question still produces a useful answer with the correct citation. This tests an enforced permission boundary alongside product utility instead of relying solely on whether the model verbalizes a refusal.
Quick diagnostic map
| Evidence | Review | Acceptance boundary |
|---|---|---|
| Retrieved text | Treat documents as untrusted input | Keep instructions separate from authorization |
| Tool proposal | Validate structured arguments at the server | Bind access to the authenticated tenant |
| Adversarial exercise | Use a harmless cross-tenant request | Verify rejection and audit evidence |
Frequently asked questions
Can a system prompt alone solve indirect prompt injection? No. Keep access and action permissions enforced by the application.
Clouvenix can review RAG retrieval and tool execution together, helping teams preserve useful document assistance while keeping authorization outside the control of retrieved text.
For a scoped review of this workflow, discuss the relevant Clouvenix engineering service.