Someone in your org has already asked when they’re getting Copilot. Probably someone senior. And the pressure to just flip the switch is real, because the demo is genuinely impressive and everyone wants the productivity story. So let me save you the incident report by telling you the one thing the demo won’t:

That sentence is the whole article, but it’s worth unpacking, because understanding why it’s true tells you exactly what to fix before you deploy.

Here’s the mechanism people miss. Copilot doesn’t get its own god-mode access to your tenant. Every prompt runs in the security context of the user asking it. Copilot can only surface content the user could already find on their own through search or a shared link. It grants no new access. Not a single permission.

Which sounds reassuring until you say the second half out loud. The problem is that most users already have access to far more than anyone realises, and until now the only thing protecting that content was that nobody bothered to look. The overshared HR folder, the finance workbook on a site with “Everyone except external users” slapped on it, the strategy deck in a Team that was set to org-wide back in 2021 and never fixed. All of it was technically reachable. It was just buried under the friction of people having to dig manually.

Copilot removes the friction. “Summarise what we know about the upcoming restructure” is now a fully-indexed, natural-language, instant search across everything that a user can technically touch. The access was always there. The oversight was accidental obscurity. Copilot is the tool that ends the obscurity, cheerfully, for every employee at once.

So the job before you deploy is not to lock Copilot down. Copilot is behaving correctly. The job is to fix the permission and labelling reality it’s about to expose. Good news: this is entirely a Microsoft-stack exercise, and the tools are already in the box. Three layers, in order.

You cannot fix what you cannot see, and the scale of oversharing in a mature tenant is genuinely hard to eyeball. This is what SharePoint Advanced Management is for, and Microsoft now includes it with M365 Copilot licensing, so check your tenant, but you very likely already have it.

The reports that matter live under Data Access Governance. Start with these:

The Everyone Except External Users (EEEU) report finds the sites where content was shared with essentially the entire organisation. This is the single highest-value report you’ll run, because EEEU is the classic accidental org-wide share, and it’s exactly the content Copilot will happily surface to anyone who asks the right question.

The sharing links reports show you the sites generating the most “Anyone” links and org-wide links. The site permissions baseline gives you a snapshot of where your permission structure needs immediate attention. And the Content Management Assessment Hub rolls a lot of this into a Copilot-readiness view with remediation recommendations, which you’re meant to re-run roughly every 30 days to track progress.

Run these first. Do not skip to the exciting labelling stuff. Layer 1 tells you the size of the problem, and it is almost always bigger than the team guessed. Better you find the finance folder than an employee finds it through a Copilot prompt in week one.

Once you can see the oversharing, you triage it. You are not going to perfectly re-permission a decade of SharePoint sprawl before your go-live date, and you don’t need to. You need to shrink what Copilot can reach to what’s actually safe, and buy time to fix the rest properly.

The standout control here is Restricted Content Discovery (RCD). Flip it on for a high-risk site, and that site stops appearing in Copilot, agent experiences, and org-wide search, while leaving the existing permissions completely untouched. Nobody who legitimately uses the site loses access. It simply stops being discoverable through the AI and search layer. This is your emergency brake for the sensitive sites you’ve found but can’t fully remediate yet. Apply it to the worst offenders from your Layer 1 reports, and you’ve contained the scariest exposure in an afternoon.

Alongside RCD, tighten the taps so the problem stops growing. Restricted Access Control locks a site so only members of a specified Entra security group or M365 group can reach it, regardless of old links or inherited permissions. Adjust your default sharing settings in the SharePoint admin centre so new shares aren’t org-wide by default and links carry sensible expiry. And use the site lifecycle policies, inactive-site detection, ownership minimums, and site attestation, to deal with the ownerless, forgotten sites that are a huge share of the risk. Archiving genuinely dead sites keeps their stale content out of Copilot results entirely.

Layer 2 is the difference between a go-live where Copilot can only see reasonably-governed content and one where it’s a search engine pointed at your entire mess. RCD alone justifies the whole exercise.

Layers 1 and 2 handle the site-level blast radius. Layer 3 handles the individual documents and the genuinely sensitive content that needs protection no matter where it lives. This is where Microsoft Purview sensitivity labels and DLP come in, and this is the part that keeps working long after go-live.

The foundation is a sensitivity label taxonomy that people actually use. Keep it small and legible: something like Public, Internal, Confidential, Highly Confidential. Users can apply labels, or you can apply them automatically based on content (auto-labelling on sensitive information types like card numbers or national ID numbers) or by default. Whatever you can auto-apply is worth more than what you rely on users to remember.

Then Purview DLP enforces it, and there’s now a DLP policy location specifically for M365 Copilot and Copilot Chat. The headline capability is generally available: a DLP rule with a “sensitivity label” condition can exclude labelled content from Copilot processing entirely. Label a document Highly Confidential, point a Copilot DLP policy at that label, and Copilot will not use that item’s content in its summaries or grounding. The item can still show as a citation, but the content behind it stays shut. That’s exactly the behaviour you want for the crown-jewel material: it exists, people with rights can open it directly, but the AI won’t read it aloud in a summary.

The Copilot DLP location does more than label exclusion. It can block external web search as a grounding source when a prompt contains sensitive information types, keeping Copilot on approved internal data. It can block responses to sensitive prompts outright (in preview at time of writing). And it can exclude external emails from grounding. Build the label exclusion first; it’s the GA workhorse, and layer the rest on as they suit you.

A few real-world details that will save you a support ticket. Copilot DLP policy changes can take up to about four hours to take effect, so don’t test thirty seconds after saving and panic. You can’t combine a sensitive-information-type condition and a sensitivity-label condition in the same rule, so split them into separate rules in the same policy. Selecting the Copilot location disables the other locations in that policy, so it’s a dedicated policy. And DLP can’t scan files a user uploads directly into a prompt, only the typed prompt text, so uploads are a gap you cover with user training and label-at-source, not DLP. Knowing these up front is the difference between a smooth rollout and three days of “why isn’t this working.”

Put together, the pre-flight looks like this. Run the SharePoint Advanced Management Data Access Governance reports and size the problem, starting with EEEU. Triage the results: Restricted Content Discovery on the worst sites right now, then work the backlog of proper re-permissioning behind that safety net. Tighten default sharing and clean up ownerless sites so the problem stops growing. Stand up a small sensitivity label taxonomy, auto-apply as much as you can, and enforce the sensitive labels with a dedicated Purview DLP policy on the Copilot location. Then pilot with a small group, watch what surfaces, and expand.

I won’t pretend this is a Friday-afternoon job. On a real tenant, this is a few weeks of work, and the re-permissioning tail can run longer. But here’s the reframe that makes it an easy sell to whoever’s pushing for the switch: none of this is wasted effort you’re doing for Copilot. Overshared sites, org-wide links, unlabeled sensitive data, and forgotten ownerless sites were all risks the day before anyone said the word Copilot. You were carrying that exposure regardless. Copilot is just the forcing function that finally gets it fixed, and RCD plus a Copilot DLP policy means you get to fix it without blocking the rollout everyone wants.

Which lands us back where we started, because it’s the same lesson every time: AI doesn’t change the fundamentals. It removes your excuses for skipping them. Copilot didn’t create your oversharing. It just set a very public deadline for cleaning it up.

Do the three layers, and you can switch it on without holding your breath.

---

Get ready for Copilot with SharePoint Advanced Management]