If Copilot exposes oversharing rather than creating leaks, then the highest-value security work you can do before a rollout happens in SharePoint and OneDrive — not in the AI settings. Here’s the practical sequence I use to find and reduce that exposure.

Step 1: See the exposure with DSPM

Start in Microsoft Purview Data Security Posture Management. Its oversharing objective and data-risk assessments give you a prioritized view of where sensitive content sits behind broad access — and where Copilot interactions are most likely to surface something they shouldn’t. This is your map; don’t start remediating blind.

Step 2: Quantify access with Data Access Governance

SharePoint Advanced Management includes Data Access Governance (DAG) reports that show which sites have the broadest access — “everyone except external users” links, sharing sprawl, and sites with the most permissioned users.

A practical note from the field: the first organization-wide DAG snapshot can take up to several days to generate, while later runs are quicker. Kick it off early so it’s ready when you need it. If you live in PowerShell, Start-SPODataAccessGovernanceInsight produces both org-wide and per-user permission snapshots — invaluable when you need to prove, with evidence, why a user can ask Copilot a surprising question.

Step 3: Prioritize the hotspots

You won’t fix everything before launch, so triage. I start with the predictable high-sensitivity zones:

  • HR, Finance, Legal, and Executive sites
  • M&A / project rooms
  • Anything with heavy external sharing

Fix the crown-jewel exposure first; schedule the long tail.

Step 4: Reduce discoverability while you review

You often can’t re-permission a large estate overnight — but you can stop that content from being discoverable in the meantime. Microsoft gives you two complementary levers:

  • Restricted Content Discovery (RCD) — a per-site switch that removes a site’s content from org-wide search and Copilot, without changing permissions. Ideal for a specific over-exposed site under review.
  • Restricted SharePoint Search (RSS) — a tenant-wide, temporary allow-list mode: only explicitly approved sites are searchable/groundable while you get your house in order.

The critical distinction, and one I stress in every workshop: these change discoverability, not permissions. They buy you time; they are not a substitute for fixing access. Microsoft is explicit that Restricted SharePoint Search is a short-term measure, not a permanent design.

Conceptually, enabling RCD on a single site is as simple as:

Set-SPOSite -Identity https://contoso.sharepoint.com/sites/MandA `
  -RestrictContentOrgWideSearch $true

Test it in a pilot tenant first, and document what you changed.

Step 5: Classify before you scale

Discoverability controls are blunt. The durable fix is sensitivity labels and encryption, applied to the content that matters. Labels are also what let you constrain Copilot precisely at runtime (via Purview DLP) later — so classification isn’t a parallel track, it’s a prerequisite.

Step 6: Prove it with a before/after test

Close the loop with evidence. Seed a synthetic confidential document, give a low-privilege pilot account inappropriate access, and ask Copilot to find it — before remediation. Then remediate permissions/discoverability and ask again. When the second answer comes back empty, you have a demonstration that lands with any audit or risk committee far better than a screenshot of a settings page.

The point

Oversharing remediation is unglamorous, and it’s the single biggest lever on a safe Copilot rollout. Do it methodically — discover, quantify, prioritize, suppress discoverability, classify, verify — and you’ve removed most of the risk before you’ve enabled a single sensitive prompt control.

This is one of the labs I run in my AI-security workshop. If you’d like to walk your own environment through it, let’s talk — or start with the full secure Copilot launch playbook.