Permission aware retrieval
Search results must respect the person asking
A knowledge assistant needs the same access boundaries as the documents behind it. Here is how to place those checks without making the model responsible for security.
In this article
Start with a document the reader cannot open
Imagine a firm with separate workspaces for two clients. An employee can open the first client's files but not the second client's contract. They ask an internal assistant whether either client receives a particular discount. The second contract contains the clearest answer. A search system that ranks only by relevance will probably select it.
The problem begins when that contract enters the assistant's context, which is the material sent to the model with the question. Hiding the citation afterwards does not undo the disclosure. Neither does instructing the model to avoid confidential information. The application must decide which material is available before it asks the model to use it.
This is a useful starting test for an architecture discussion. Draw the path taken by a forbidden document. Find the component that stops it. If the answer is a sentence in the prompt, the boundary is in the wrong place.
Keep identity and relevance separate
Authentication establishes who made the request. Authorisation establishes what that person can access. Search ranking establishes which of the accessible documents best answers the question. These are separate jobs, even if one service performs several of them.
A practical design starts with an application gateway. It verifies the session, resolves the organisation and current group memberships, and supplies those values to the search layer. The browser sends the question. It does not choose its own list of allowed groups.
The index stores access metadata beside each passage. A passage might carry a document identifier, a document version, an organisation identifier and the groups allowed to read it. All passages from a restricted document must carry the restriction. A missing permission field should exclude the passage until ingestion is corrected.
- Application gatewayVerify the session and resolve current access
- Restricted searchSelect passages within the permitted document set
- Answer serviceUse only those passages and their source identifiers
- Source viewerCheck access again when the citation is opened
Choose the boundary your team can operate
A shared index with mandatory filters is often a workable starting point. It avoids a separate index for every team, but every search path must apply the filter. That includes suggestions, exports, follow-up questions and any administrative search interface exposed to ordinary users.
Separate indexes can make some boundaries easier to understand. They also create more configuration, migrations and operational work. An index per organisation may fit a product with a modest number of large customers. It is less attractive when thousands of small tenants need frequent schema changes. Neither approach removes the need to check the caller at the application boundary.
Microsoft's security-filter documentation is useful here because it distinguishes a filter value from an authenticated identity. A group identifier in a query is just data. Your application remains responsible for deciding which values the caller is allowed to use.
Account for changes after the first answer
Access can change while a conversation remains open. A cached answer can contain text that was permitted yesterday and forbidden today. Design the cache around a stated revocation requirement, meaning the maximum time an access removal may take to become effective. A short expiry can reduce exposure, but it is not the same as immediate invalidation.
For sensitive material, recheck access before serving stored passages or answers. Keep enough provenance to identify the document versions used. If the application cannot establish current access, it should withhold the affected material and explain that the source is unavailable.
A useful review ends with evidence from two accounts, not a polished demo from an administrator. Ask the same question as an allowed user and a denied user, remove a permission, then repeat it in an existing conversation. Inspect the material sent to the model as well as the answer shown on screen.
Primary sources
Microsoft Learn: security filters in Azure AI SearchOWASP: authorisation guidanceReferences checked 11 September 2026.