Grounding a Copilot Studio agent on SharePoint mostly works the way people hope. Set up correctly, the agent checks the permissions of whoever is asking a question, not the person who built it, and only shows what that person could already see in SharePoint. The mechanism is fine. The risk is in what people change without realising.
At a glance: a correctly configured SharePoint knowledge source checks the querying user's own permissions, not the maker's. Uploaded files skip that check entirely, permissions don't travel with an upload. Connectors can be switched to run on the maker's credentials instead of the user's, which removes per-user checking there too. Test as a low-privilege user, not as yourself, and audit SharePoint site permissions before you scope an agent to them, not after.
How grounding resolves permissions
When you point a Copilot Studio agent at a SharePoint site or document library using the native SharePoint knowledge source, and the agent is set to authenticate its users, the agent runs its search as that specific person. Ask it a question through Teams or the Copilot Studio web chat and it queries SharePoint using your own delegated permissions, the same ones that decide what turns up when you search SharePoint directly. If you can't see a document today, the agent can't either. That setup needs an Entra ID app registration carrying the Sites.Read.All and Files.Read.All scopes, and the agent's authentication set to something other than "no authentication." Turn authentication off and the agent stops retrieving from SharePoint altogether. It fails closed. Which of Copilot Studio's three authentication modes actually gets you there, and what each one needs to set up, is covered in the authentication options post.
Where people assume wrong is a different knowledge source entirely: file upload. If you or a colleague uploads a document straight into the agent instead of linking to it on SharePoint, permissions don't travel with the file. Once it's uploaded, it sits in the agent's own store and is available to anyone who can talk to the agent, full stop, regardless of who could see the original file in SharePoint. I've seen a "SharePoint agent" that was really half SharePoint-linked knowledge and half uploaded PDFs someone grabbed off a restricted site because the crawl was taking too long. The linked half behaves. The uploaded half doesn't, and both look identical in the chat window.
Oversharing was already there. The agent just makes it findable
Most "leaks" are SharePoint permissions that were already too broad, now searchable in plain English.
The usual culprits are boring. A site set to give everyone in the organisation edit or read access by default. Permission inheritance broken years ago when someone moved a folder. A share that went to "everyone except external users" rather than a named group. All of it predates the agent, sitting there since the site was set up, protected only by the fact that nobody typed a search query broad enough to surface an HR pay-scale spreadsheet by accident. An agent will, if asked the right question.
So the oversharing audit belongs at the front of the project. If your tenant has never had a permissions review, assume there's at least one site somewhere that's more open than anyone intended. Microsoft ships tooling for exactly this under SharePoint Advanced Management: an oversharing baseline report and a site access review that asks site owners to confirm or fix broad sharing settings at scale, rather than someone manually checking a few hundred sites one at a time. Run that pass, or at minimum spot check the sites you're about to ground the agent on, before you publish anything.
Scope the knowledge source to a library
The fastest way to keep an agent's blast radius small is to not point it at more than it needs. A Copilot Studio SharePoint knowledge source can be scoped to a specific document library or even a single folder, rather than a whole site, and you can add several separate SharePoint URLs to one knowledge source, up to the per-agent caps Microsoft enforces. Point it at the curated policy library, not the whole intranet.
Same rule as a new hire's laptop: give them what the job needs, rather than the keys to every site with the permission system as the only backstop. A second layer of restriction is cheap, and one layer of defence is one misconfigured group away from a bad afternoon.
This matters even more if the site itself is broad. Scoping the knowledge source to "Policies" or "Client Onboarding" rather than the whole team site means that even if that site later picks up an overshared folder, the agent was never pointed at it in the first place. That gives you a second gate in front of the permission check, which still does its own job. A tightly scoped library also keeps you well clear of SharePoint's own list and library ceilings, which is one less thing to debug if the agent's answers start feeling incomplete.
Query as a low-privilege user
The mistake I see most: someone builds the agent, tests it logged in as themselves, decides it's working, and ships it. If you're the maker, you're very likely also a site owner, an admin, or someone with broader access than the receptionist or the junior account manager who's about to use this thing every day. Testing as yourself proves the agent works, and proves nothing about whether it leaks.
Test with an account that has ordinary staff-level access, a real low-privilege test user rather than a guess at what one might see. Ask it the awkward questions on purpose: what's in the redundancy policy, what did the last restructure memo say, what's this client's contract value. If the test account gets an answer it shouldn't, that's the agent correctly reflecting a SharePoint permission that's wrong, and now you know to fix the permission, not the agent.
Two things skew a test result. New or changed SharePoint content doesn't reach the agent instantly, indexing runs asynchronously, so give it time before deciding a document genuinely isn't showing up. And permission changes work the same way in reverse. Tightening access on a folder doesn't guarantee the agent's index reflects that the moment you save the change. If you've just revoked someone's access to prove a fix works, retest a little later rather than immediately, and don't treat an instant clean result as final.
Grounding solves what the agent knows. It does not solve what the agent should do with it, which is a separate problem with a separate place to write it down.
The same permission model applies to Microsoft 365 Copilot seats: what Copilot can and cannot see in your files.
What to check before an agent goes near HR or finance
If the plan is to eventually let this agent answer questions that touch HR, payroll or finance content, tighten the process before you get there, not after someone notices.
- Run a site access review first. Don't ground an agent on a site you haven't looked at in over a year. Fix what the review finds before you connect the agent to it.
- Check every connector and flow, as well as the knowledge source. Copilot Studio's authentication for connectors defaults to end-user credentials, which behave the same way as SharePoint, permission-checked per person. It can be switched to maker-provided credentials instead, where the agent acts with your access for every single user who talks to it. Copilot Studio's built-in security scan flags that switch when it happens, and an admin can block maker-provided credentials outright for the whole environment. Do that for anything touching sensitive content.
- Keep uploaded files out of sensitive scopes entirely. If it needs permission checking, it needs to be a SharePoint link, not an upload.
- Roll it out to a small group first. A pilot with five or six people from different roles will surface a permission gap faster than a week of you testing alone.
- Decide who owns it. An agent with no owner is the same as a SharePoint site with no owner: it drifts, and nobody notices until it's already gone wrong.
This is the same discipline you'd apply to any SharePoint site holding sensitive content. The agent is what makes skipping it expensive.
If you're about to build one of these
Getting the permissions right doesn't automatically get you good answers, either. That's a separate failure mode, and I've written up how I traced a Copilot Studio agent's confident wrong answers back to how the source content was structured rather than the security model. If you want a second pair of eyes on the setup before it goes live, that's a free 30-minute call. If you want the permissions audited and the scoping done right the first time, that's what a paid Workflow Review is for. And if Copilot Studio and Power Platform agents generally are new territory for your firm, that's the lane I work in day to day.