RAG Prompt Injection Through Documents: A Practical Security Boundary

A document is evidence, not an instruction

Document-grounded assistants often receive files that were written for people: policies, tickets, manuals, emails and uploaded PDFs. Some of those files can contain text such as “ignore previous rules”, “reveal the hidden prompt” or “send this record to an external address”. That text is data from an untrusted source. It must not become an instruction merely because retrieval selected it.

This matters before generation. If an ingestion job preserves untrusted text beside system rules, or a prompt template gives retrieved passages the same authority as application policy, the model may follow a document's request instead of the product's intended workflow. A filter that looks for a few hostile phrases is useful as a signal, but it is not a security boundary.

The broad implementation and procurement scope belongs to RAG systems and /ai-specialist-armenia. This narrower guide describes a reviewable engineering boundary for one failure class; it does not certify an assistant as secure.

Define the trust contract before retrieval

Use an explicit contract for every stage. The application owns policy, tools and allowed actions. A user owns their request only within the current authorization boundary. A document owns neither permissions nor instructions, even when it is a current, trusted business source.

Store this contract next to a request receipt: caller role, collection and revision, retrieval query, returned locators, classifier signals, tool decision and final route. It gives a reviewer something better than a vague report that a “prompt filter ran”.

A small architecture with separate boundaries

DOC-GUARD-7 is a public synthetic architecture example. It has four decisions rather than one oversized prompt:

1. Ingestion preserves the source, owner, revision, access label and a content-risk signal. It does not execute embedded instructions.
2. Retrieval applies tenant and role filters before ranking. It returns locators and provenance, not authority.
3. An answer composer labels passages as untrusted evidence and keeps application policy outside the document payload.
4. An action gate validates structured intent against an allowlist, authorization and a human-review route before any consequential operation.

request -> authorize -> retrieve permitted locators -> inspect risk signal
        -> compose answer from untrusted evidence -> validate output intent
        -> answer | clarify | deny | human review

This separation is useful even when a document is benign. It lets the team ask a precise question: did the unsafe behavior arise from data lifecycle, access filtering, prompt composition, model output or an action integration? RAG access control covers the authorization boundary in more detail, while RAG citations and traceability explains why locators need to survive the answer.

Failure modes worth testing

Test an assistant with synthetic documents that resemble the source shapes it accepts. Do not put customer records or secret prompts in a public fixture. A useful test suite includes at least these routes:

Measure outcomes by route and consequence, not by a single “injection resistance” score. Record whether the document was retrieved, whether its instruction-like text reached the model, whether output asked for a tool, whether the gate denied it, and whether a reviewer could reproduce the result. The OWASP LLM Prompt Injection Prevention Cheat Sheet and NIST AI RMF Generative AI Profile were consulted on 2026-09-18 as guidance, not as a guarantee or a fixed implementation recipe.

Keep actions outside model authority

The critical mistake is allowing generated text to call a tool with whatever arguments it supplied. Instead, make the model produce a constrained proposal such as needs_human_review, cite_locator or draft_reply. The application then validates the proposal against a typed schema, caller entitlement, destination allowlist, rate limit and, where needed, an explicit human approval.

if riskSignal === "instruction_like" then route = "review";
if proposal.action not in allowedActions then route = "deny";
if proposal.references are not permittedCurrentLocators then route = "no_answer";
if consequence === "external_write" then require humanApproval;

The checks are deliberately independent. A benign-looking answer can still target the wrong tenant; a source can be current but not relevant; a model can format valid JSON for an action that no user is entitled to request. Fail closed for protected data and side effects, while keeping a usable clarification path for ordinary uncertainty.

Turn tests into a release gate

Run DOC-GUARD-7 when changing ingestion, chunking, retrieval filters, model, prompt template, tools or authorization integration. Keep a versioned set of synthetic adversarial documents, the source snapshot, expected routes and a receipt for each run. A missed access denial, unexpected tool proposal or uncited high-consequence answer should hold release until an owner classifies the cause and records the correction or accepted exception.

The point is not to promise that prompt injection has been solved. It is to make a document's power observable and bounded: it may supply cited evidence, but it cannot rewrite policy, expand access or trigger an action by itself. For a controlled architecture review, start with RAG systems or /ai-specialist-armenia.