Rodrigo Jorge · Prepared October 23, 2026, at 9:51 a.m. Brasília time (UTC-3). Publication time to be confirmed.
Someone asks the internal assistant why a client ended its contract. Search finds a report restricted to the executive team. The assistant provides a summary without linking to the file.
In this hypothetical scenario, hiding the reference does not prevent disclosure. The content has already crossed the access boundary.
As a CISO, I would start with the query that supplied the answer: whose authorization did it use? An account that can index every document does not determine what each user is allowed to receive. If the integration uses that account to retrieve any passage and asks the model to hide the restricted ones, content selection already depends on an instruction to the model.
RAG, or retrieval-augmented generation, needs to carry permissions along with the content. A passage's relevance tells us whether it helps answer the question. It does not tell us whether that person is entitled to receive it.
The filter does not authenticate anyone
The Azure AI Search documentation describes a security filter pattern that includes or excludes documents by matching user or group identifiers. Microsoft itself emphasizes that, in this pattern, the identifier is a string used in the filter, not authentication or authorization performed by the filter. The filter needs to be applied to every query.
For an integration using this pattern, I propose deriving identity and group membership from an authenticated context, constructing the restriction in the service, and preventing the user or model from replacing it with arbitrary parameters. Unauthorized content should stay out of the context sent to the model. This is an architectural proposal to verify, not a guarantee that comes with the product name.
Permissions also need to be copied. In its query-time access control feature, currently marked as preview, Microsoft documents that ACL updates depend on the ingestion method. Changing a permission at the source does not mean every index already reflects the change. This observation is not a recommendation to adopt the preview feature.
The team needs to know what happens to indexed passages, caches, and conversation history when access changes. A new search filter does not erase an answer already delivered.
View the diagram: authorization before model context. A proposed workflow, with no metrics or incident data.
I would evaluate this integration with two test users and synthetic documents. One user can read the document; the other cannot. Both ask the same question. The evidence should show which passages were retrieved for each identity, as well as the final answer. Then revoke the first user's access and repeat the test through the defined permission update path.
The absence of the secret from the final answer is not enough if the restricted passage entered the context. Testing only the main query is not enough either: if users can also retrieve content through titles, citations, or exports, those paths need to enforce the same authorization.
Before authorizing this workflow, I would require evidence that search preserves each identity's read permissions and that permission changes have a defined handling process. If the integration does not know whose access applies, it does not yet know which documents it can deliver.
References
- Microsoft: Security filters for trimming results in Azure AI Search, accessed October 23, 2026.
- Microsoft: Query-time ACL and RBAC enforcement in Azure AI Search (preview), accessed October 23, 2026. Limitations and permission updates by ingestion method.