How to Build Permission-Aware RAG Without Data Leaks

The safe order is simple to describe: authenticate the requester, resolve their current roles and relationships, restrict search to objects they may read, retrieve and rank within that boundary, verify permission again when fetching the source, then assemble the smallest useful context. The model should never see a passage that the user could not open directly.

Do not search the entire vector index and remove forbidden results after generation. Do not put confidential passages in the prompt and rely on a system message that says not to reveal them. Prompt instructions are not an authorization mechanism. A model can quote, paraphrase, summarize, infer from, or be manipulated into exposing any context it receives.

For low-risk material, metadata filters in one shared index may be enough. For strict tenant or regulatory boundaries, separate indexes, storage accounts, encryption keys, or processing environments may be justified. The design should follow the consequence of a boundary failure, not the convenience of a particular vector database.

Permission-aware RAG has more than one failure mode. A metadata bug can mix tenants. A group change can leave stale access in a cache. A broad semantic query can surface a document whose title looked harmless but whose body is restricted. A generated citation can reveal a confidential filename or customer identity even when the answer omits the underlying sentence.

Attackers can also query repeatedly and learn from what the system returns. The CopyBreakRAG paper demonstrates a black-box attack that adapts queries using model feedback to extract chunks from a RAG knowledge base. Its experiments do not mean every deployment will leak at the reported rate, but they show why ordinary conversational limits are a weak boundary for a private corpus.

The NIST Generative AI Profile treats unauthorized use, disclosure, and de-anonymization of sensitive information as data-privacy risks. It also frames risk across the full AI lifecycle. For RAG, that lifecycle includes ingestion, embeddings, indexes, caches, prompts, outputs, logs, exports, backups, and deletion. Protecting only the chat endpoint leaves several copies of the same evidence outside the boundary.

Write the threat model in terms of principals, objects, actions, and consequences. Who can ask? Which documents, sections, claims, or cases can they read? Can they search without viewing? Can they cite, download, share, or export? What must happen when a person's team, case assignment, consent, or employment changes?

A chunk inherits meaning from its source and should usually inherit its security boundary too. Store a stable source ID beside every chunk, embedding, summary, and extracted entity. Attach the tenant, classification, owner, relevant groups, jurisdiction, retention status, and policy version needed to make an authorization decision. Derived artifacts need lineage to every source that influenced them.

Avoid copying a flat list of user IDs into millions of chunks when access depends on changing relationships. A relationship-based model can express rules such as ‘the assigned adjuster may read this claim’ or ‘members of this research project may read its sources’. The Zanzibar paper describes a shared authorization system that stores and evaluates access-control relationships while preserving consistency as permissions and objects change. Most teams do not need Google's scale, but the separation between authorization logic and search logic is useful.

Deny by default when metadata is missing, malformed, or too old. An unlabeled chunk should enter quarantine, not a general collection. If a summary combines one public and one restricted source, the summary should receive the stricter effective permission unless the system can prove that its public claims are independent.

The control must cover non-text artifacts too. Tables, OCR output, images, extracted entities, graph edges, generated summaries, and conversation memories can all carry restricted facts. Securing the PDF while placing its extracted claims in a broadly readable graph simply moves the leak.

At request time, authenticate the user and resolve a trusted principal from the session. Never accept a tenant ID, group name, or role merely because the chat message or client payload supplied it. Ask the authorization service which objects or partitions are eligible for that principal and action.

Apply that boundary inside retrieval. Some stores can pre-filter vector search by tenant and access metadata. Others work better with separate namespaces or indexes. If a system retrieves globally and filters afterward, forbidden chunks have already influenced ranking infrastructure, traces, and possibly caches. Post-filtering also produces thin result sets, because the global top candidates may all be discarded. Retrieve enough permitted evidence rather than choosing from an impermissible shortlist.

Recheck authorization when loading the full source or parent section. Child-to-parent expansion is a common leak: a permitted chunk points to a parent document that contains restricted neighbouring material. The same problem appears when graph traversal follows a permitted entity into a confidential case or when a citation link bypasses the application and exposes the raw object.

Keep retrieval and generation interfaces narrow. Pass the model only the passages, locators, and task instructions needed for the answer. Do not include hidden metadata, unrelated chat history, access-control lists, or signed storage URLs. The OWASP guidance on sensitive information disclosure recommends least-privilege access and restricted data sources, while warning that prompt restrictions can be bypassed.

Authorization protects confidentiality; source controls protect integrity. Decide which people and systems may add, replace, classify, and delete knowledge. Validate file types and parsers, preserve the submitting identity, scan for hidden or executable content, and keep untrusted uploads separate until review rules pass.

This matters because retrieved text can carry instructions as well as facts. The OWASP vector and embedding weaknesses guidance identifies cross-context leakage, weak access controls, embedding inversion, and poisoned data as risks around RAG stores. It recommends permission-aware stores, logical separation, source validation, classification, and retrieval logging.

The PoisonedRAG study shows that a few crafted texts can steer answers to selected questions in its experimental setting. That is an integrity attack, not primarily a permission failure. Yet the defences meet at ingestion: restrict who can write, record provenance, detect unexpected source changes, and make high-impact answers prefer reviewed sources.

Do not treat all retrieved text as trusted instructions. Separate system instructions from evidence, label retrieved material as untrusted content, and prevent it from selecting tools or changing the authorization scope. Content scanning can reduce obvious attacks, but no filter proves a document safe. Source authority and constrained capabilities matter more than a long blacklist of suspicious phrases.

A correct retrieval decision can still leak through a shared cache. Cache keys should include the effective authorization scope or point only to public material. Prefer caching document IDs and recomputing permission over caching complete prompts or answers across users. When membership changes, invalidate results that depended on the old relationship.

Logs need their own data-minimization policy. Record the requester, policy decision, source IDs, retrieval ranks, model version, and result status where useful, but avoid copying full confidential passages into general observability tools. Security teams need enough detail to investigate without creating a second, less protected knowledge base.

Citations should resolve through the same authorization layer as search. A signed URL copied into an answer may outlive the session or be forwarded to someone else. Show a stable application link, then check access when it is opened. Redact document titles and snippets if their existence is sensitive.

Deletion is a distributed operation. Remove the source, chunks, embeddings, derived summaries, graph facts, caches, and queued exports according to the applicable retention policy. Backups and immutable audit records may follow different rules, which should be explicit. The broader NIST SP 800-53 control catalog is useful here because access control sits beside audit, identification, system integrity, media protection, and privacy controls rather than replacing them.

Build tests around the boundary, not only answer quality. For each sensitive source, pair a user who may read it with a similar user who may not. Ask direct questions, paraphrases, partial identifiers, summaries, comparisons, and follow-ups. The permitted user should receive grounded evidence; the denied user should not learn the fact, title, citation, existence, or access pattern unless policy explicitly allows that disclosure.

Exercise state changes. Remove a user from a group, transfer a case, change a document classification, revoke consent, and delete a source while sessions and caches remain warm. Measure how long each index, cache, graph, and replica takes to reflect the change. A policy that becomes correct tomorrow is not correct for a revocation needed now.

Add adversarial and operational cases: repeated extraction queries, prompt injection inside uploaded documents, poisoned near-duplicates, malformed metadata, tenant-name collisions, failed authorization services, stale tokens, parent expansion, and citations opened in another account. Rate-limit unusual enumeration, but do not mistake rate limits for access control.

Evaluate retrieval quality inside the permitted corpus. Fine-grained filters can lower recall when metadata is incomplete or candidate pools become small. That is a product problem to solve with better indexing and permission data, not a reason to search forbidden material. Track false denials separately from leaks; the two failures have different costs.

The goal is not to claim that the vector database is secure. It is to produce a traceable proof that this user, under this current policy, could access every source that shaped this answer. If you have a real knowledge workflow where document permissions, derived summaries, and changing team membership no longer line up, share the failing path at sahil@granveo.com.