Permission-aware RAG: your chatbot should not know more than its user

A salesperson asks the internal assistant: “Which discount rules apply to hotel customers?” Retrieval finds three highly relevant documents. Two are ordinary sales guidelines. The third is a management file containing purchasing margins and special commercial terms.

From a semantic-search perspective, that third file is excellent. From an access-control perspective, it should not exist for this user.

That is where basic RAG architecture can fail. Retrieval finds the most relevant chunks and hands them to the model. If permission checking happens only after generation — or not at all — the sensitive content has already entered model context.

Permission-aware RAG applies a simple rule: the assistant can retrieve only material the current user is already authorised to access. Semantic relevance is then calculated inside that permitted set.

RAG permissions separate relevance from authorisation

Zero-trust architecture rejects the idea that access is safe merely because a user or system is “inside”. Access decisions depend on identity, resource and policy. That maps cleanly to document retrieval.

Every RAG query really has two questions: which content is relevant, and which content is eligible for this caller?

Eligibility may come from existing groups, roles, ACLs or document security attributes. The implementation varies by stack, but the ordering matters. Filter to authorised content before context reaches the model, then rank by semantic relevance.

identity- and resource-aware access decisions are central to zero-trust architecture.

Recommendation: do not ask the LLM to decide whether a confidential chunk already placed in its context is “probably okay to use”. Enforce access before retrieval output is handed to generation.

Shared indexes can flatten the permissions you already had

SMEs often build the first internal chatbot quickly: export SharePoint, Drive, Notion or a file share, create embeddings and demo search. The quality can look impressive while the original security model has quietly disappeared.

A hotel may have public breakfast information, shift plans, guest complaints, supplier prices and management reports in the same document environment. A global vector search for “breakfast cost” could retrieve an internal costing sheet rather than the guest-facing price.

Migration is another failure point. The source system has inherited folder permissions, but the export process strips ACL metadata before chunks enter the vector database. The new retrieval layer becomes flatter than the system it copied.

Caches matter too. A manager receives an authorised answer; the application caches the entire result globally; a salesperson later receives language influenced by that same cached context.

So the security objective is broader than “protect the original file”. Preserve the authorization boundary across indexing, retrieval, caching and answer tracing.

A six-step permission-aware RAG flow

A first version can be compact if the logic is explicit.

1. Classify the corpus. Public, internal, team-only, confidential or highly restricted.
2. Preserve ACL metadata during indexing. Documents or chunks need an association with allowed roles, groups or principals.
3. Pass authenticated user context. “I am the CEO” in a prompt is not identity; session or identity-provider data is.
4. Filter before semantic ranking. Only authorised chunks are candidates.
5. Log the source and access decision. During investigation you should be able to reconstruct what was retrieved and under which user context.
6. Run denial tests deliberately. A non-HR user should ask for salaries, reviews or margins and receive no restricted retrieval.

A small company may need only three groups — all staff, sales, management. “Inside our company” should never become the universal access level.

Exceptions: information can be sensitive even when no single file is forbidden

Access control is not always binary at file level. A model can infer something sensitive by combining several documents that the user is allowed to see.

A salesperson might legitimately see individual supplier prices and order volumes. Enough cross-document analysis could reveal a margin management considers confidential even if no single “margin.xlsx” file was retrieved.

No ACL system perfectly solves this class of inference. For particularly sensitive knowledge, separate corpora, answer policies or dedicated assistants can be simpler than one universal bot.

Human handover is also needed when access is permitted but interpretation carries business or legal consequence. Showing an HR policy source is different from deciding how to handle a specific dismissal. The assistant can retrieve; an HR professional or adviser may need to own the decision.

The minimum pilot should test refusals, not only impressive answers

Choose two user groups and two document classes. For example, sales and management, with normal product material plus one confidential margin document.

Create ten ordinary questions and ten denial tests. The denial tests should include indirect wording, combinations of terms and a prompt that falsely claims elevated authority. Inspect retrieval logs, not only the final text. A safe-looking refusal is not enough if restricted chunks were still placed into context.

Measure unauthorised retrieval rate, false-denial rate for authorised users, answers with traceable source, time for an ACL change to propagate into retrieval, handovers caused by unclear access, and coverage of sensitive document classes by denial tests.

A strong demo answers difficult questions. A strong internal assistant also says, correctly and without leaking clues: “I do not have an authorised source for that in your current access context.”

The practical conclusion is that permission-aware RAG is not an enterprise-only feature. The moment an SME has documents that some employees may see and others may not, the AI retrieval layer must respect that same distinction. Otherwise the company creates a second access path beside its document system and forgets to lock the door.

Indirect prompt injection is a content risk. Machine identities establish on whose behalf retrieval happens. The controls need each other.

Sources

• NIST SP 800-207
• NIST SP 800-207A
• NIST — AI Risk Management Framework

---