Somewhere in your tenant there’s a “company-wide” site from 2019, and somebody dropped a salary review spreadsheet into it “just for a minute.” It’s been shared with everyone in the company ever since. Nobody noticed because nobody went looking.
Microsoft 365 Copilot goes looking. Ask it “summarize compensation across the team” and it will happily find that file, because Copilot only ever returns what the asking user could already open. The permission was always wrong. Copilot just made it easy to stumble onto.
Copilot is a magnifier, not a filter.
The leak was already there
Turning Copilot on doesn’t change a single permission. If a user can find a file through SharePoint search today, Copilot can summarize it tomorrow, in plain language, in front of someone who didn’t know the file existed.
So the work isn’t locking Copilot down. The work is finding content that was overshared years ago and quietly fixing it. That cleanup is the project. The rest of this post is how to do it.
Step 1, Find the oversharing
You can’t fix what you can’t see. The reports you need live in the SharePoint admin center, under Reports → Data access governance, and they’re part of SharePoint Advanced Management (SAM), now bundled with Microsoft 365 Copilot licensing. If you’re paying for Copilot, you already have these.
Start with the Content Management Assessment, a guided Copilot-readiness hub that’s designed to be your “start here.” From there, work the Data access governance reports:
- The site permissions baseline report, a tenant-wide picture of how sites are shared.
- The “Everyone except external users” (EEEU) report, sites shared with the whole org. This is where the 2019 salary sheet shows up.
- The sharing links activity reports, “Anyone” links and “People in the organization” links that are floating around.
SharePoint admin center
The EEEU report is where overshared sites surface. It only covers the last 28 days and the top 100 sites, so treat it as a rolling snapshot.
One catch worth knowing up front: the EEEU and sharing-links reports only cover the last 28 days and the top 100 sites. That’s a rolling snapshot, not a full inventory. A single audit pass won’t catch everything, which is why this becomes a recurring job rather than a one-time task.
Step 2, Fix the worst sites
Most of what the reports surface is fine. The company handbook should be company-wide. The events calendar should be open. Your job is triage: separate the intentional sharing from the HR drafts, comp planning, and exec slides that should never have been org-wide.
Once you’ve picked the sites that need fixing, two per-site controls do real work:
- Restricted Access Control (RAC) locks a site so only members of a specific Entra security group can open it. That’s a true deny boundary, regardless of any stray sharing links.
- Restricted Content Discovery (RCD) flags a high-risk site so it won’t appear in Copilot, agents, or org-wide search, while leaving permissions untouched. It’s the cleanest per-site safety valve for a handful of sensitive sites.
This is where the timeline gets honest. For a 1,000-user tenant, budget a few weeks, not an afternoon. Microsoft frames data-governance remediation as a 4–8 week phase and ships its assessment tooling on a 30-day rerun cycle because the work is iterative. You fix, you re-scan, you find more.
Step 3, Label sensitive content (the right way)
Sensitivity labels belong in your plan, but it’s worth being precise about what they do.
Applying a label to a site or container does not label the files inside it. Labeling your top sites is good hygiene, but it is not, on its own, a Copilot control.
And a label only stops Copilot when it encrypts the file. A marking-only label (just a “Confidential” header or watermark with no encryption) does not stop Copilot from reading or summarizing that document.
Step 4, Pilot before you go wide
There is no version of “turn it on for everyone on day one” that ends well. Roll Copilot out to a small group first. Pick a mix of roles (sales, ops, HR, exec) so you see different access patterns, and watch it for about a month before expanding. A 50–200 user pilot over 30 days is the practical sweet spot; Microsoft’s own guidance says “small group, phased” without committing to numbers, so treat the specifics as a sensible default rather than gospel.
What you’re watching for: people asking Copilot for things and getting answers from sites they shouldn’t see. The pilot catches the missed-permission cases your reports didn’t.
Microsoft 365 Copilot
During the pilot, every surprising citation is a permissions bug you just found early.
While the pilot runs, you can also use Restricted SharePoint Search (RSS) as a short-term holding measure. RSS puts an allow-list of up to 100 SharePoint sites in front of org-wide search and Copilot. Useful, but know its limits.
What gates Copilot, and what doesn’t
01 Does a 'Confidential' sensitivity label stop Copilot reading a file?
02 If I label a SharePoint site, are the files inside it protected from Copilot?
03 Does Restricted SharePoint Search hide overshared content from Copilot?
04 What actually fences a single high-risk site off from Copilot?
Tell users what to expect
A short note to your pilot group does a lot of work. Tell people Copilot can summarize and draft from content they already have access to, and that it cannot see content they have no permission on (assuming permissions are correct). Then tell them to report anything that surfaces unexpected content. Your users are the last line of defense for the missed-permission cases the reports never caught.
Copilot pays off when permissions are clean. The deciding work happens before you flip the switch.