Building Permission-Aware Enterprise AI Search
A reference RAG case study showing how document permissions, source freshness, citations and evaluation shape enterprise AI search.
On this page +
This BRIVOX reference case study examines an internal knowledge assistant for a representative organization. It describes a proposed architecture and verification plan, not a client delivery or a claim of achieved accuracy.
The knowledge problem#
Employees need answers from operating procedures, product notes and internal guidance. Some documents are shared across the company; others belong to specific teams. Documents change, permissions change and sometimes the available evidence does not answer the question.
The goal is to help an authorized employee find a supported answer without turning the search index into a new route to restricted information.
Make access part of retrieval#
The proposed pipeline associates each document and derived chunk with its source identity, revision and access metadata. The server resolves the requesting user's current permissions before retrieving eligible material.
Permission filtering must happen before restricted text is sent to a model. Asking the model to hide unauthorized information after it has received that information is an inadequate access boundary. Citation links also need normal authorization when opened.
Choose how permission changes propagate. A sensitive revocation may require immediate exclusion while the index is refreshed. Define a fail-closed policy for uncertain access state rather than silently using stale permissions.
Keep evidence and instructions separate#
Retrieved text may contain mistakes or hostile instructions. Treat it as source material, not as permission to call tools, reveal other documents or change application rules. OWASP's prompt injection guidance explains why prompt wording alone cannot establish that separation.
Keep the first version focused on read-only answers. If later versions perform actions, give each action its own server-enforced policy and approval requirements.
Make uncertainty visible#
An answer should link to the supporting source and identify when evidence is missing or conflicting. A citation must support the claim attached to it; the presence of a link does not automatically make an answer correct.
For example, if two approved procedures disagree about an escalation owner, the assistant should surface that conflict rather than select one arbitrarily. Assign document owners so the underlying problem can be corrected.
Proposed evaluation set#
- A straightforward question answered by a current approved document.
- The same question asked by a user without access to that document.
- A source containing an instruction to ignore the application's rules.
- An obsolete document and its current replacement.
- Two sources with contradictory operational guidance.
- A question that the indexed material does not answer.
Assess supported claims, citation correctness, access enforcement and appropriate abstention separately. Add latency and cost measurements for the intended workload. Set release thresholds with the business owner; this article does not report evaluation scores.
Operational handover#
Document ingestion failures, permission-sync delays and source deletions need visible ownership. Keep diagnostic logs useful while avoiding unnecessary copies of confidential prompts and source passages. Provide a way to disable an unsafe source and roll back retrieval changes.
A scoped pilot should name its document owners, approved audience, evaluation set and human escalation route. These are concrete discussion points for BRIVOX's AI development service and application security review.
