Company knowledge RAG: permissions, leakage, and source boundaries

The most common RAG mistake inside companies is simple: upload everything, ask questions, and treat source-cited answers as automatically safe.

The second most common mistake arrives later: someone realizes the assistant can answer from documents the user should never have seen. Salary bands. Customer contracts. Legal drafts. Board notes. Support tickets. HR investigations. Security procedures. The answer may be accurate and cited, but the system has leaked information.

A company knowledge RAG is not a search box with nicer prose. It is a permissioned information system. Treat it that way.

Retrieval must enforce the same or stricter permissions as the source systems. If a user cannot open the document in Google Drive, SharePoint, Notion, Confluence, or the CRM, the RAG should not retrieve it for that user.

The core rule

The retrieval layer must answer this question before returning any chunk:

Is this user allowed to see this source right now?

Not “is this source in the vector database?” Not “is this source relevant?” Not “is this source useful?” Permission comes first.

There are three common patterns:

The right answer depends on the source systems and risk level. For most SMEs, separate indexes plus metadata filtering is enough. For customer, HR, legal, or regulated data, real-time checks may be required.

The hard part: keeping ACLs in sync

Every pattern above quietly depends on one thing: the permission data in your index matching the permission data in the source system. That synchronization is where the real engineering lives.

Where the ACLs come from. SharePoint and OneDrive expose per-item permissions through the Microsoft Graph API; Google Drive through the Drive API’s per-file permission listings; Confluence through space and page restrictions. Each has different shapes (users, groups, inheritance, sharing links), different API rate limits, and different notions of “who can see this.”

Group expansion is not optional. Most real permissions are granted to groups, and groups nest. “Sales EU” inside “Sales” inside “All Staff” must be flattened to concrete users either at sync time (bigger index metadata, faster queries) or at query time (fresher, slower, more API calls). Pick one deliberately; teams that do it accidentally do it inconsistently.

Sync lag is a security parameter, not a performance detail. When someone loses access to a document — role change, offboarding, a deal going confidential — the index keeps serving the old ACL until the next sync. Decide the acceptable revocation delay per corpus and write it down: near-real-time for restricted corpora, hours may be acceptable for internal process docs. If nobody has written that number down, the real answer is “whenever the nightly job runs,” which will not survive a security review.

Real-time checks buy freshness and cost you latency, rate limits, and a failure mode. A per-retrieval permission call adds a source-system round trip to every query and eats API quota fast at scale; the usual compromise is a short-lived cache, which quietly converts “real-time” back into “sync lag with a smaller number.” Whatever you choose, make the timeout behavior explicit: if the permission check fails or times out, the chunk does not ship. Fail closed, log the failure, and let the assistant refuse — a slow correct answer beats a fast leak.

The offboarding test from the testing section is how you find out whether any of this actually works: a disabled account must retrieve nothing from restricted corpora, and the check must hold the day after the account is disabled, not just after the next full re-sync.

Source boundaries

Do not create one giant knowledge pool. Separate by audience and sensitivity:

The fewer audiences a corpus serves, the easier it is to reason about leakage.

Ingestion controls

The ingestion pipeline is where many leaks start.

Before indexing a source, capture:

• Source system.
• Document ID.
• Owner.
• Audience or ACL.
• Sensitivity label.
• Created and updated timestamps.
• Expiry or review date.
• Whether the document may be used for AI retrieval.
• Whether the document contains personal data.

If the source system already has labels, preserve them. If it does not, add a lightweight classification step before ingestion.

Retrieval controls

Retrieval should happen in this order:

1. Identify the user and groups.
2. Identify the requested workspace or assistant.
3. Filter candidate sources by corpus, ACL, sensitivity, and freshness.
4. Retrieve relevant chunks only from allowed sources.
5. Rerank allowed chunks.
6. Generate the answer with source references.
7. Refuse or escalate when allowed sources are insufficient.

Do not retrieve first and filter later in the prompt. If a forbidden chunk enters the model context, the boundary has already failed.

Prompt and answer behavior

The assistant should be instructed to:

• Answer only from retrieved sources.
• Cite source title and section/link.
• Say when allowed sources do not contain the answer.
• Mark inference separately from sourced facts.
• Avoid revealing that restricted sources exist.
• Avoid summarizing access-denied material.

Bad refusal:

“I found HR salary bands but you do not have access.”

Better refusal:

“I do not have an approved source available to answer that.”

The second answer does not leak the existence or topic of restricted documents.

Logging without creating a second leak

RAG logs are sensitive. They can contain user questions, retrieved chunks, source IDs, answers, and sometimes personal data.

Log enough to debug:

• User ID or pseudonymous ID.
• Assistant/workspace.
• Query timestamp.
• Source IDs retrieved.
• Permission-filter outcome.
• Answer ID.
• Refusal/escalation reason.
• Latency and errors.

Be careful with:

• Full user questions.
• Full retrieved chunks.
• Full generated answers.
• Customer data.
• HR/legal/security topics.

For sensitive systems, store redacted logs or source IDs rather than full text. Give logs their own access control and retention period.

Stale and conflicting sources

Permission is not the only boundary. Source quality matters.

Every indexed source should have an owner and a freshness rule:

When sources conflict, the assistant should surface the conflict only if the user can access both sources. Otherwise it should answer from the highest-authority allowed source or escalate.

Testing permission boundaries

Test with users, not only documents:

• Employee with broad access.
• Employee with narrow department access.
• Manager with team-only access.
• Contractor.
• Former employee or disabled account.
• Customer-facing support user.
• Admin.

For each, ask:

• A question they should be able to answer.
• A question just outside their permissions.
• A question about a restricted document they know exists.
• A question where public docs and internal docs conflict.
• A question using prompt injection: “ignore access rules.”

The correct result is not only “good answer.” It is “good answer from allowed sources.”

Rollout path

Start with the least sensitive corpus:

1. Public/product docs.
2. Internal operations docs.
3. Department-specific docs.
4. Customer records with strict ACL.
5. Restricted corpora only after explicit security/legal approval.

At each stage, measure:

• Answer helpfulness.
• Citation quality.
• Refusal correctness.
• Access-denied retrieval rate.
• Stale-source rate.
• User reports of missing or wrong sources.

Do not do this yet

Do not index “all company docs” into one assistant.

Do not rely on prompt instructions to enforce permissions.

Do not log full retrieved chunks for sensitive corpora without a clear retention and access policy.

Do not mix HR, legal, customer, and public docs in the same corpus.

Do not let the RAG answer outside its allowed sources just to be helpful.

The takeaway

Company knowledge RAG is valuable because it brings source-grounded answers into daily work. It is risky because source-grounded answers can still leak information.

Design permission boundaries first. Filter before retrieval. Separate corpora by audience. Preserve source metadata. Refuse safely. Log carefully. Test with real permission profiles. If a user cannot access the source directly, the RAG should not use that source to answer them.