An HR site shared with "Everyone except external users" five years ago, for a project that closed within the month, sits in most Microsoft 365 tenants without anyone remembering it exists. For a decade that setting did nothing dangerous, because nobody browsing SharePoint manually stumbles onto a folder three clicks from where they'd naturally look for it. Microsoft's FastTrack guidance on limiting Copilot data exposure describes exactly this problem. Content shared with "Everyone", "Everyone except external users" or a broad security group becomes part of Copilot's queryable surface for any licensed user, including one who would never have located those files by hand.
Point a Copilot agent at the same tenant and the gap closes. An agent doesn't browse a site the way a person does. It searches, synthesises and answers in a single prompt, across every site the asker's account can reach, whether or not that site was ever meant to stay reachable this way. That same guidance describes years of SharePoint oversharing combined with Copilot's ability to traverse and synthesise content in one prompt as something that turns unresolved sharing settings into immediate exposure. The exposure already existed. Copilot Studio removed the obscurity that had been protecting it, turning a manual search nobody would have attempted into one sentence anyone could type.
Whose identity the agent uses to answer
The setting that decides most of this outcome is identity, specifically whose identity the agent is using when it goes looking for an answer. Microsoft's documentation on adding SharePoint knowledge to Copilot Studio agents says an agent only surfaces content the specific querying user can access, and it never grants new permissions on its own. The Retrieval API and Search API that power this go further still. Microsoft's API security documentation for Copilot extensibility says both support delegated permissions only, not application permissions, and every call has to carry a real signed-in user's identity in the token. An agent built this way can't see more than the person asking it can already see.
That protection depends on a configuration choice, and the default isn't automatic delegation in every path an agent's tools can take. Tool authentication inside Copilot Studio is set to use end-user credentials by default, but Microsoft's own security blog on Copilot Studio's top ten agent risks, published in February 2026, describes what happens when a maker points an OAuth connection at their own credentials instead. Every user who talks to that agent then acts as the agent's creator. If the creator holds elevated privileges anywhere the agent's tools reach, every user of that agent inherits them for the length of the conversation, regardless of what their own account could actually touch.
Microsoft closed part of that gap in August 2026, when a new governance control reached general availability that lets administrators block agents from authenticating tools with a maker's own credentials at all, according to Microsoft's documentation on Entra agent identities. It pushes tenants toward end-user or governed workload identity models instead of the maker's personal login. That control sits alongside the wider shift toward Entra Agent IDs for every new Copilot Studio agent, covered in more detail in an earlier look at agent identities. It's a real fix, but it's a setting an admin has to turn on and enforce across every environment, not a default that changed underneath agents already running.
Where the SharePoint oversharing already lives
The exposure comes from a short, repeatable list of causes: sites shared with "Everyone except external users", broken permission inheritance where a subfolder quietly stopped following its parent site's rules, anonymous or organisation-wide sharing links nobody ever revoked, and legacy "All Employees" security groups that were convenient once and never cleaned up. None of these are exotic. Most tenants have all four somewhere.
Whatever the true proportion turns out to be in a given estate, none of it was created by an agent. It is the accumulated result of years of site owners choosing the broadest sharing option because it was the fastest one, on the reasonable assumption that almost nobody would go looking.
Microsoft's own guidance on securing and governing a Copilot deployment treats this as the actual starting point, ahead of any feature configuration. That guidance sets out three parts, and remediating oversharing comes first, before setting up guardrails and before meeting regulatory obligations. A companion piece from Microsoft's 365 Copilot blog is blunter about why. A decade of accumulated permission grants becomes an active data exposure risk the moment Copilot activates, and readiness for Copilot is an oversharing remediation project before it's a licensing decision.
The controls that narrow it
None of this is unfixable, but the fixes are specific, and one of them is still partial.
Restricted Content Discovery, part of SharePoint Advanced Management, hides a site's content from Copilot and from organisation-wide search without touching the underlying permissions at all, according to Microsoft's guidance on getting SharePoint ready for Copilot. Once it's turned on for a site, that content stays invisible to Microsoft 365 Search and to agents unless a specific user has already opened a file from that site directly within the past 28 days. It's a narrower, more targeted successor to an older feature called Restricted SharePoint Search, which Microsoft is retiring on 31 January 2027, so any tenant still relying on the old control has a deadline to move off it. Site Access Reviews works alongside it from the other direction, sending site owners a guided email prompting them to look at their own SharePoint groups and individual item permissions and decide what still needs to be that open.
SharePoint Advanced Management also runs data access governance reports that surface exactly which sites are shared with "Everyone" or "Everyone except external users," and Microsoft's FastTrack guidance recommends running that report first against sites known to hold financial, HR, legal or project data, rather than trying to sweep the entire tenant at once. For a site that needs to stay narrow permanently, a restricted access control policy limits Copilot's visibility into that site's content to a named group, independent of whatever the broader SharePoint sharing settings say.
Sensitivity labels help, but only under a specific condition worth checking directly. A label that's purely visual, a header or a watermark with no encryption behind it, does not stop Copilot from reading the file. Microsoft's FastTrack blog is explicit that blocking Copilot requires either encryption with EXTRACT rights denied, or a Purview DLP policy that names the label directly. Microsoft finished rolling out automatic sensitivity label enforcement across Word, Excel, PowerPoint and Outlook by late July 2026, which stops labelled files from being sent to Copilot for content analysis at all. Microsoft's Purview documentation for DLP and Copilot covers more ground than labels alone. It can block sensitive prompts containing information types like credit card, passport or Social Security numbers, and it can stop Copilot from sending anything sensitive out to external web search providers. One control in that same documentation is still preview only, restricting Copilot and Copilot Chat from processing external email entirely. Any DLP change takes up to four hours to reflect in the Copilot experience, so testing a new policy the same afternoon you publish it will show you the old behaviour, not the new one.
Two dashboards pull a lot of this together without a trip through separate admin blades. The Copilot security dashboard sits inside the Microsoft 365 admin center, under Copilot, then Overview, then Security, and surfaces DLP posture and oversharing signals in one place. The Microsoft Security Dashboard for AI, at ai.security.microsoft.com, pulls the same kind of signal from Defender, Entra and Purview together for a cross-product view. Microsoft has said it will fold Copilot oversharing alerts and DLP controls directly into the Microsoft 365 admin center in October 2026, with suggested remediation steps and a metric showing how much sensitive Copilot interaction is actually protected, though that hasn't landed yet.
What to check this week
Start with the SharePoint Advanced Management data access governance report, and don't aim it at the whole tenant on day one. Point it first at sites you already know hold HR, finance, legal or active project data, and look specifically for "Everyone" or "Everyone except external users" in the permissions column. Every hit on that list is a site an agent can already summarise for anyone with a licence, whether or not that was ever the intention.
Then open Copilot Studio and check how each published agent's tools authenticate. Most reviews stop at whether the agent still responds, which is the easier question and the less important one. An OAuth connection running on a maker's personal credentials means every user of that agent uses the maker's access for the length of the conversation. If the maker has elevated privileges anywhere the agent's tools reach, so does everyone who talks to it. The governance control that blocks this outright reached general availability in August 2026, and turning it on is a policy decision, not something that happened automatically to agents already in production.
Last, pull up a handful of sensitivity-labelled files that are supposed to be off limits to Copilot and confirm what's stopping it. A watermark alone does nothing. Check for encryption with EXTRACT denied, or for a Purview DLP policy that names the label directly, because those are the only two things Microsoft's own guidance says will actually block the file.