RAG creates a new permission path
A user may be allowed to search one document repository but not another, view a case but not its restricted attachments, or access a policy only in a particular region. Copying all of that content into one vector index can flatten the source system's distinctions. Similarity search then becomes an unintended way around the original authorization model.
The safe question is not merely whether a document may be indexed. It is whether this subject, in this context, may use this passage for this request. That decision must be made before the passage becomes model context. Filtering an answer after generation is too late: the restricted content has already influenced the model and may be exposed indirectly.
Treat ingestion and query as separate controlled pipelines
Secure RAG has at least two pipelines with different risks. The ingestion pipeline discovers, parses, classifies, chunks, embeds, and indexes content. The query pipeline authenticates the subject, interprets the request, retrieves permitted evidence, builds context, generates an answer, and returns citations.
At ingestion, preserve enough metadata to make a later access decision: source identity, owner, classification, tenant or domain, source permissions or a reference to them, version, effective date, and the exact location represented by each chunk. If source permissions can change, decide how revocation reaches the index. A nightly rebuild may be unacceptable for an access change that must take effect immediately.
At query time, establish the user and purpose independently of the prompt text. Retrieve with an enforceable entitlement filter, not an instruction asking the model to ignore restricted results. Recheck the selected evidence at the source boundary when the risk justifies it, especially where the index's permission view can be stale.
Define an evidence contract
A RAG system needs an explicit contract for what counts as an acceptable answer. Without one, teams tend to evaluate fluency while leaving evidence quality implicit. The contract should state:
- which source classes are authoritative for the question;
- how current the evidence must be and how superseded versions are treated;
- whether important claims require one source or corroboration;
- how conflicting sources are disclosed rather than silently blended;
- when the system must abstain because evidence is missing, restricted, stale, or ambiguous;
- which citation must accompany a claim and where that citation may take the user.
The contract gives retrieval, prompting, output checks, and evaluation the same target. It also creates a safe failure mode. An answer such as ‘I do not have enough permitted evidence to answer that’ may be the correct production outcome, even when the model could produce a plausible response from general knowledge.
Lineage must survive chunking and citation
Every retrieved chunk should retain a durable relationship to its source, version, location, and access policy. A citation is useful only when it resolves to the evidence the user is permitted to inspect. Linking to a document landing page that the user cannot open—or to a document whose relevant passage has changed—does not provide meaningful traceability.
Keep model context and user-visible citation separate but connected. The model may receive a normalized passage with a stable evidence identifier. The application can resolve that identifier to a safe title and authorized destination after generation. This reduces the chance that generated URLs or source labels are accepted as truth.
Lineage also supports incident analysis. If a harmful instruction was embedded in a document, an operator should be able to identify which indexed version entered the request, which other answers used it, and how to quarantine it without rebuilding unrelated content.
Retrieved content remains untrusted input
Authorization answers who may access content; it does not make the content safe as an instruction. Documents, web pages, tickets, and messages can contain malicious or accidental text that tries to redirect the model. The orchestration layer should distinguish system instructions from retrieved evidence and prevent retrieved text from expanding tool permissions or changing policy.
- Label and delimit evidence so its role is unambiguous.
- Do not place secrets, credentials, or unrestricted tool results into model context.
- Keep tool authority outside retrieved instructions and outside the model's sole control.
- Record which chunks influenced the response and flag unusual or high-risk sources.
- Use output handling appropriate to the destination; a safe chat answer may still be unsafe as HTML, SQL, or an action parameter.
For systems that can take action, these controls belong inside a broader bounded-autonomy architecture. Retrieval must inform a decision without being able to grant itself authority.
Evaluate retrieval separately from the answer
A polished answer can conceal poor retrieval, and correct evidence can be turned into a poor answer. Measure the stages separately. Build a test set with expected sources, access contexts, ambiguous questions, superseded documents, conflicts, and cases where abstention is required.
- Retrieval: did the system find the relevant permitted evidence and exclude restricted or irrelevant evidence?
- Grounding: are material claims supported by the selected passages?
- Citation: does each reference resolve to the correct authorized source location?
- Abstention: does the system stop when evidence is insufficient or policy prevents access?
- Robustness: do hostile or misleading passages fail to change authority, policy, or tool behaviour?
- Operations: can the team trace a result, remove a bad source, and understand latency and cost?
Run these checks when the embedding model, chunking strategy, index, access filter, prompt, generation model, or source set changes materially. RAG is a data and authorization system as much as it is a model pattern.
Questions for a secure RAG review
- Can we show the identity and entitlements used for every retrieval?
- Can an access revocation take effect within the required time?
- Does each chunk retain source, version, classification, and policy lineage?
- Can restricted evidence enter context and then be hidden only at the output stage?
- Can a citation take the user somewhere they are not authorized to access?
- What happens when sources conflict, are stale, or do not support an answer?
- Can retrieved text alter instructions, tools, permissions, or downstream actions?
- Do evaluations cover retrieval, grounding, authorization, citation, and abstention separately?
These questions fit within the broader enterprise AI architecture framework. They turn ‘we use RAG’ into a design that an architecture, security, and data owner can review together.