How do you design RAG over SharePoint that respects users' permissions?
Answer out loud or in your head first, then compare.
Answer
First I establish which documents and kinds of permissions have to be handled. I can use search that enforces access at the source, or build my own index that updates both content and permissions. I compare the available options, the update delay and the maintenance cost.
With my own index, each chunk points to its document and version. I also store the information needed to restrict reading. The backend establishes the user's identity and admits only permitted material before sending it to the model. If revoking access must take effect immediately, a periodic import alone isn't enough.
I test a change of group membership, a file deletion and an attempt to read someone else's result from the cache. I don't promise full permission parity just because I used Graph or a ready-made connector. First I check the supported scenarios.
Why it matters: Combines the basics of RAG, login and updates into one scenario.
Possible follow-ups: Does the app's access to a site mean every employee has the right to all its files?
How did it go? Be honest — “Not yet” puts the question on your review list.
Start with
- D-P15 · What is idempotency? — Backend, data and system design
- G-P01 · What is RAG? — RAG and retrieval
- H-P01 · How does an AI agent differ from a plain model call? — Agents and workflows
Practise in code
- An assistant with a new requirement — guided self-review
Further reading
- Azure AI Search: Document-level access control(opens in a new tab)Docs; accessed 22.10.2026. Security filters, native ACLs and preview features; syncing permissions needs an explicit mechanism.
- Microsoft ISE: Propagating SharePoint Document Permissions(opens in a new tab)30.04.2026. An example of materialising ACLs and Sites.Selected; check the scope for your environment.