Your agent may read the document. Can the employee asking? Microsoft's SharePoint pattern answers per user
A Microsoft reference design keeps a Foundry hosted agent on its own identity for inference and runs SharePoint retrieval as the signed-in user. Its two-user test belongs in every RAG rollout.
Listen to this article · 5 min
AI-generated narration of the full article.
A finance analyst, an HR partner and a project manager ask an internal agent the same question. In SharePoint, each of them can open a different set of documents. The agent, running on its own identity, can open whatever it was granted. Whose permissions decide the answer?
In too many enterprise RAG systems, the honest answer is the agent’s. Retrieval runs under a service identity, so the employee receives an answer built from documents they could never have opened themselves. No prompt fixes this, and Microsoft says so plainly in a reference architecture published on October 12: “Changing the model or the prompt can’t fix this. The architecture has to carry the user’s identity all the way to SharePoint.”
Two identities in one request
The pattern splits the request in two. A hosted agent in Foundry Agent Service “keeps using its own identity for model inference, while retrieval runs with the signed-in user’s identity.” Three pieces carry the user’s identity end to end:
- the Foundry toolbox in the agent sends a per-request call ID with each tool call, so Foundry knows which user the call belongs to;
- a UserEntraToken connection passes that user’s Microsoft Entra ID token to a Foundry IQ knowledge base on Azure AI Search, an On-Behalf-Of passthrough;
- a remote SharePoint knowledge source queries SharePoint live through the Microsoft 365 Copilot Retrieval API as that user, scoped to chosen sites. “Nothing is copied into an index.”
| Step | Runs as | Why |
|---|---|---|
| Model inference | The agent | Uses the agent's own model access |
| Tool call routing | The agent, tagged with the user's call ID | Links each call to one user |
| Knowledge base query | The user | Entra token passed on behalf of the user |
| SharePoint retrieval | The user | SharePoint applies its own permission trimming |
The design matters as much for what it removes as for what it adds. There is no separate index to secure, no copy of document permissions to keep in sync, and no service account that can read every site. SharePoint stays the authority on who can open what, which is where that decision belongs.
The pitfalls are the useful part
Microsoft’s write-up is most valuable where it describes what went wrong in testing:
- A managed identity on the connection fails. Retrieval then runs as the agent, SharePoint has no user to check, and the request is rejected.
- A custom MCP client can merge users. A hand-built client that attached only the agent’s credential dropped the per-request call ID; in Microsoft’s testing with another OAuth tool, “every user ended up running as whoever had consented first.” That is a cross-user data exposure produced by an integration detail, not by the model.
- Every user needs a role on the search service, because each user’s own token now reaches Azure AI Search. Assign it to a group, or retrieval fails for people who can reach the agent.
- A custom On-Behalf-Of proxy can work, but then the team owns its hosting, secrets, token validation and patching.
The second pitfall deserves a place in every security review of an agent that calls tools on behalf of users. Identity propagation is not a property of the protocol; it is a property of the client that implements it. The same lesson runs through our analysis of why enterprise MCP starts with identity and of the three identities every agent carries.
Limits before you plan around it
This is a reference implementation, not a new product. Remote SharePoint knowledge sources in Foundry IQ were in preview when it was written. End users need a Microsoft 365 Copilot license, a reader role on the search service and agent access, and the search service must be in a region that supports agentic retrieval, in the same Entra tenant as Microsoft 365. Microsoft positions Work IQ, which also retrieves as the user, for agents that need a person’s broader Microsoft 365 context; this pattern is for agents meant to stay inside defined SharePoint sites.
The test to keep
Microsoft’s closing advice is the one to copy into your release checklist: “A good answer doesn’t prove the right permissions were used.” Pick one document that only one of two test users can open. User A should get an answer with a citation; user B should be told the sources do not contain the answer. Run it in separate conversations and repeat it after every permission change. The agent’s instructions help here too: tell it to say when the tools return nothing relevant rather than guess, so a permission boundary shows up as “I don’t know” instead of an invented answer.
A RAG system that passes this test is enforcing the enterprise’s permissions. One that has never run it is assuming so.