An AI search answers an internal question with a relevant quotation. Technically impressive, but was the person asking allowed to read that document? This is a decisive test of whether a RAG solution is fit for business use.
RAG combines search with a language model.
Retrieval-augmented generation adds relevant source information to a request. Documents are prepared and made searchable; selected passages then provide context for the language model. The model can use that context to produce an answer with source references.
This is useful when the right information is current and authorised for the user. It becomes risky when a shared index returns documents without effective access restrictions. Signing in to a chat interface does not grant permission to read every document it can find.
Access control must apply before information reaches the model.
The application obtains the user’s identity through a trusted sign-in process. Search limits results and excerpts to the authorised scope. Only that permitted context reaches the language model. The index, its administrative access and its connection to the source also need appropriate controls.
A prompt telling the model not to reveal confidential information is too late to serve as the sole access control. Unauthorised data would already have been processed. Hiding a quotation afterwards does not fix that data path either.
Smaller information paths matter too.
- Result titles
- A title about a planned personnel decision may itself be confidential. Permissions filtering needs to cover more than the full document text.
- Caches
- An answer generated for user A must not be reused for user B without checking. Cache design needs to account for identity, tenant and relevant permissions.
- Source links
- Clickable evidence must still require authorised retrieval of the original. A private download link must not create general access.
- Logs
- Queries, excerpts and error details may contain business secrets. Limit who can inspect them and how long they remain stored.
Permissions can change faster than an index.
Someone moves departments, a project ends or a share is revoked. Source content and search permissions need to match again. The architecture therefore needs a documented update process and an appropriate response time.
Revocation is a particularly important test: after a permission change, ask a previously permitted question again using the same account. Also check whether older caches, previews or stored answers still provide access. Document the outcome; a successful import job alone is not enough.
Product features are not interchangeable building blocks.
Some search services support native document-level controls; others require explicitly enforced filters and a separate synchronisation process. Current Azure AI Search documentation, for example, distinguishes security filters from additional integrated methods, some labelled as preview. API and version details belong in the architecture decision.
Whatever the tool, acceptance tests should demonstrate which source a test identity may see and which it does not receive. Define those boundaries before interpreting an incidental model answer.
A testable pilot combines value and protection.
DAXS can start with a clearly scoped knowledge repository: named source owners, current documents, test accounts, clear answer criteria and traceable negative tests. Expand only when search, permissions and source references work together.
The Company knowledge & RAG guide explains ingestion and queries as a whole. AI security covers oversharing, identities and agent permissions in more depth.
Sources: Microsoft: Document-Level Access Control · OWASP: Vector and Embedding Weaknesses. The diagram illustrates a possible architecture without customer data.
