RAG

Prompt-Injection Containment for Private RAG Systems

Private RAG can retrieve malicious instructions. Contain prompt injection with provenance, isolation, least privilege, validation, and approval gates.

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 sourceInjection opportunityControl focus
User promptDirect instruction overrideSession policy and input signals
Uploaded documentHidden or obfuscated textQuarantine, parsing, provenance
Managed repositoryCompromised or over-permitted contentSource identity and access labels
OCR or imageInstructions invisible in normal text reviewMultimodal inspection and testing
Web or email connectorAttacker-controlled external contentTrust zoning and freshness controls
Tool responseMalicious data returned by an approved APIOutput typing and tool isolation
Agent memoryInjection that persists into later runsWrite 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:

  1. retrieve only from sources authorized for both the user and the agent;
  2. issue a distinct agent identity rather than inheriting an administrator’s session;
  3. grant tools per workflow and per execution stage;
  4. issue short-lived credentials for the specific operation;
  5. restrict egress so encoded output cannot call an attacker-controlled destination;
  6. validate and size-limit model output before another system consumes it;
  7. 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


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.

Frequently asked questions

Does running RAG on-premises prevent prompt injection?

No. On-premises deployment keeps processing within the enterprise boundary, but prompt injection can already exist inside a document, email, ticket, webpage snapshot, OCR result, or tool response. Private deployment improves control over sources, models, logs, and enforcement; it does not make retrieved content trustworthy.

Can a content filter completely eliminate prompt injection?

No single filter is reliable enough to be the security boundary. Attack text can be obfuscated, split across chunks, hidden in images, or phrased like ordinary business instructions. Filters are useful signals, but containment must also limit retrieval scope, separate data from instructions, validate outputs, enforce tool authorization in code, and require approval for high-impact actions.

Should a RAG assistant be allowed to call enterprise tools?

Only when the use case requires it, and only through narrowly scoped functions with deterministic authorization and parameter validation. A read-only knowledge assistant has a smaller blast radius than an agent that can send messages, modify records, or execute code. Treat retrieved content as untrusted even when it came from an internal repository.

How should enterprises test private RAG for indirect prompt injection?

Build a controlled corpus containing visible, hidden, multilingual, encoded, OCR-based, and split instructions. Test whether the system preserves source permissions, labels untrusted content, refuses policy changes, prevents cross-source data access, blocks unauthorized tool calls, and produces a complete trace. Repeat after model, prompt, parser, chunking, retrieval, or tool-policy changes.

Filed under
private RAGon-premises AIAI governancedata sovereigntyenterprise AIAI security
Private RAG & Search

Evaluate your knowledge stack

Find out how a private RAG and retrieval layer would perform on your data — accuracy, latency, governance, and what to fix before you scale.

Read RAG best practices

Keep reading