Closing an Azure OpenAI assistant's retrieval gap didn't take a new identity platform. It took one filter and a narrower assistant.

The useful part

Egiziago Cioffi is the IT and Enterprise Architect and CEO of SynSphere Italia, a Microsoft partner based in Milan. He wrote the indexing job, configured the Azure OpenAI retrieval pipeline, connected it to SharePoint, and watched it pass every evaluation his team ran. His Azure OpenAI email assistant auto-resolves about 60% of inbound customer email, Cioffi told VentureBeat in written responses to our interview questions.

How it works

• The assistant returned SharePoint content the requesting user could not have opened in SharePoint on their own.
• The SharePoint ACL preview can now ingest site-group metadata via the spg: prefix in the 2026-05-01-preview API.
• However, only Entra-backed principals are documented as reliably enforced at query time.
• Azure OpenAI On Your Data, for example, supports document-level access via Azure AI Search security filters, but Microsoft's own documentation states that if the perm...
• The evaluation scores were clean, and the unit tests passed.

What to take from it

Cioffi ran a low-privilege account against the same questions a high-privilege account had already put to the assistant. Cioffi's retrieval logs are the evidence for this specific production failure. The preview runs through the REST API and preview SDKs and does not cover all agent deployment paths.

Details worth keeping

None of them asked the question that mattered. The logs told a different story than the evaluation scores. In many production RAG deployments, the agent answers with the indexer's permissions, not the requester's Azure AI Search has shipped native document-level ACL trimming via Entra-based tokens since preview in May 2025, and SharePoint ACL sync followed in a later preview.