Filter AI assistant sources before the model reads them

An assistant that searches business documents should retrieve only material the signed-in user may read. Define that boundary before connecting a shared document collection to a chat interface.

A staff handbook may be available to everyone while a project file is limited to one team. In an illustrative assistant, finding the handbook should not also bring restricted project excerpts into the answer context.

Bind retrieval to the user's identity

Microsoft's Azure AI Search guidance describes filtering documents using the caller's user or group identity.[1] Its custom security-filter pattern does not authenticate that identity for you: the identifier used in the filter is a string, not proof of who is asking.[2]

Ask where the application obtains the user's identity and permitted groups. Those values should come from the trusted sign-in process, not a role typed into the chat. A message saying "I am a manager" must not expand the search.

Microsoft also states that this filter must apply to every query.[2] Include follow-up questions and alternate search routes in the review, rather than checking only the opening question.

Keep restricted excerpts out of the answer

OWASP identifies inadequate retrieval access controls as a route to sensitive information disclosure and recommends fine-grained, permission-aware stores for retrieved material.[3]

Agree the rule for document chunks, snippets and source links. Restricted text should stay outside the model's context; hiding its citation after generating an answer is not the acceptance test.

In the demonstration, inspect the retrieved material as well as the visible reply. Use synthetic documents so the test does not expose real confidential records. If no permitted source supports the answer, require a clear limitation or an agreed handoff instead of an unsupported answer.

Plan permission updates

An index needs a defined way to receive access changes. Microsoft notes that Azure AI Search reflects relevant source-permission changes only after the permission metadata is synchronized to the index.[1] Do not assume a change in the document library instantly changes an existing search index.

Ask how the selected system handles that interval, failed updates and cached results. Agree whether uncertain permissions block retrieval or route the request to a responsible person. Keep the expected timing and failure behavior in the brief.

Test both accounts

Prepare a handbook that both test accounts can read and a restricted project document available to only one. Put a harmless, distinctive test phrase in the restricted document.

Ask both accounts the same question. Confirm that the authorized account retrieves the intended source, while the other receives neither the restricted excerpt nor its phrase in answers, snippets or citations. Check the retrieval evidence, not just a polite refusal.

Remove the test permission, complete the agreed synchronization and repeat the test. A successful example is useful evidence for that scenario, not a guarantee that every question is safe.

Rootscratch's AI Assistant Development & Automation service can include approved-source retrieval, permission-aware tools and evaluation of requests outside the user's role.[4] Bring sample questions, two user roles and the expected denied behavior. Keep human review for important answers in the release plan.[4]

Sources

[1] https://learn.microsoft.com/en-us/azure/search/search-document-level-access-overview — Microsoft Learn: document-level access control in Azure AI Search [2] https://learn.microsoft.com/en-us/azure/search/search-security-trimming-for-azure-search — Microsoft Learn: security filters for trimming Azure AI Search results [3] https://genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses — OWASP LLM08:2025: vector and embedding weaknesses [4] https://rootscratch.com/services/ai-assistant-development — Rootscratch: AI Assistant Development & Automation