Private RAG is often introduced as the safe alternative to sending enterprise documents to a public chatbot. It solves an important boundary problem: documents, embeddings, prompts, and model execution can remain inside the organization. It does not solve the trust problem inside those documents.
A supplier PDF can contain white-on-white instructions. A support ticket can request another customer’s record. OCR can recover text a reviewer missed. When that content is retrieved, the model receives both enterprise and document instructions as tokens. OWASP classifies this as indirect prompt injection and notes that RAG and fine-tuning do not fully mitigate it.
The safe design objective is therefore not “detect every malicious sentence.” It is prevent untrusted content from acquiring authority.
Map every route by which content becomes context
Threat modeling should start before the vector index. Inventory each path into the model:
| Context source | Injection opportunity | Control focus |
|---|---|---|
| User prompt | Direct instruction override | Session policy and input signals |
| Uploaded document | Hidden or obfuscated text | Quarantine, parsing, provenance |
| Managed repository | Compromised or over-permitted content | Source identity and access labels |
| OCR or image | Instructions invisible in normal text review | Multimodal inspection and testing |
| Web or email connector | Attacker-controlled external content | Trust zoning and freshness controls |
| Tool response | Malicious data returned by an approved API | Output typing and tool isolation |
| Agent memory | Injection that persists into later runs | Write policy, scope, expiry, review |
An internal source is not automatically trusted. Shared repositories can contain external or customer-controlled content. Record the source, object identifier, owner, classification, author, ingestion time, parser version, and permission labels for each chunk.
The secure document-ingestion architecture explains the quarantine, classification, extraction, and provenance controls that make this possible.
Preserve the distinction between instruction and evidence
Do not concatenate system policy, user intent, retrieved passages, memory, and tool output into an undifferentiated prompt. Use the model runtime’s structured roles where available, delimit each retrieved item, label its origin, and state that retrieved content is evidence rather than an instruction source.
This reduces ambiguity but is not authorization. A model can still follow malicious text despite delimiters. Enforce consequential rules outside the model:
- the application decides which collection the user may query;
- the retriever applies document-level and chunk-level permissions;
- a policy service decides which tools are available;
- deterministic code validates tool names, parameters, destinations, and data scope;
- target systems re-authorize the caller;
- an approval service controls high-impact actions.
Never place secrets in the system prompt and assume the prompt is hidden. OWASP’s guidance on system-prompt leakage emphasizes that prompts should not carry credentials or substitute for session management and authorization.
Reduce what an injected instruction can reach
Containment begins with architecture. Separate read-only question answering from action-taking agents. If a workflow only needs to summarize a policy, it should have no messaging, database-write, shell, or browser tool. If it must update a case, expose a narrow function such as add_case_note(case_id, text) instead of a general database interface.
Apply least privilege at several boundaries:
- retrieve only from sources authorized for both the user and the agent;
- issue a distinct agent identity rather than inheriting an administrator’s session;
- grant tools per workflow and per execution stage;
- issue short-lived credentials for the specific operation;
- restrict egress so encoded output cannot call an attacker-controlled destination;
- validate and size-limit model output before another system consumes it;
- require human approval for irreversible, financial, legal, safety, or privilege-changing actions.
Permission-aware retrieval is essential because a successful injection should not be able to expand the corpus. The permission-aware private RAG guide covers how source access controls should survive chunking and indexing.
Treat detection as one layer, not the decision-maker
Scanners can find instruction-like phrases, suspicious encodings, invisible Unicode, repetition, or known attack templates. Secondary models and relevance checks provide more signals, but false negatives and false positives remain.
Use detection outcomes to reduce authority: exclude a suspicious chunk, switch to read-only mode, lower tool scope, require approval, or route the event for review. Do not ask the same model that may be manipulated to make the final decision about whether it is manipulated.
Monitor runtime behavior as well as text. Unexpected tool selection, requests for unrelated records, attempts to reveal system instructions, unusual encoding, new external destinations, repeated policy failures, and memory writes after untrusted retrieval are strong signals. Connect them to a trace containing retrieved chunk IDs, model version, tool arguments, and authorization results.
When an action does proceed, use idempotency and compensating operations so a repeated or manipulated call has bounded consequences. That design is detailed in transaction-safe AI agents.
Build an adversarial RAG acceptance suite
Test the complete pipeline, not only a chat prompt. Seed a non-production collection with attack cases:
- visible instructions that claim to override policy;
- white-on-white, tiny, rotated, and OCR-only text;
- instructions split across chunks or documents;
- multilingual and encoded variants;
- content requesting another user’s documents;
- content that constructs a prohibited tool argument;
- tool output that attempts to redirect the next step;
- poisoned memory intended to affect a later session.
For every case, assert the security outcome: access filters hold, the model treats the content as data, restricted tools remain unavailable, arguments fail closed, high-impact actions require approval, memory is not silently contaminated, and the trace identifies the source.
Repeat the suite when the model, system prompt, embedding model, reranker, parser, OCR engine, chunking strategy, connector, memory policy, or tool schema changes. A defense measured against one model version is not a permanent property of the platform.
Containment with VDF AI
VDF AI keeps document ingestion, vector storage, model execution, tool orchestration, and audit evidence within the customer’s chosen environment. VDF AI Agents scopes tools and knowledge sources by role and records prompt, retrieval, tool-call, and output events. VDF AI Networks adds per-node tool permissions, approval gates, content-safety policies, and a trace across multi-step workflows.
Those controls support containment, but the enterprise must still classify sources, preserve permissions, define allowed operations, build adversarial tests, and decide where human review is mandatory. Private RAG is safest when retrieved content can inform a decision without ever becoming the authority that approves it.
Sources and further reading
- OWASP LLM01:2025 Prompt Injection
- OWASP LLM06:2025 Excessive Agency
- NIST AI 600-1: Generative Artificial Intelligence Profile
- Secure document ingestion for private RAG
Need to test a private RAG workflow against indirect prompt injection? Book a VDF AI architecture review to assess source trust, retrieval permissions, agent authority, and approval boundaries.