SharePoint permissions and Copilot oversharing: the cleanup most teams actually need

This article is for teams under about one thousand users who are about to turn Copilot on and do not have Microsoft Purview or SharePoint Advanced Management licences. Most of the published guidance on Copilot oversharing assumes you have a security team and a six-figure governance budget. If that is you, the vendor pieces from Syskit, AvePoint, and ShareGate cover your scenario well. If it is not, this article is the practical cleanup.

The reframe to start with: Copilot does not create oversharing. It makes existing oversharing visible. Documents that were technically accessible but practically invisible become trivially findable through a chat prompt. The risk pattern is not "Copilot leaked something". It is "Copilot surfaced what your permissions said anyone could see, and nobody had ever actually checked".

Why Copilot makes oversharing visible (and painful)

Microsoft 365 Copilot only returns content the asking user has permission to read. That is the security guarantee, and it holds. The problem is that the security guarantee is exactly as strong as your permission model is correct.

In the pre-Copilot world, broad permissions were largely theoretical. A document sitting in a library that "Everyone except external users" could read was, in practice, only seen by people who happened to navigate to that library. Discovery required intent. The document was technically shared with the whole company; functionally it was buried.

Copilot changes the discovery layer. Instead of needing to navigate to the library, a user just asks "what do we know about X?" and Copilot retrieves anything they have permission to read. A document that was practically invisible becomes a citation in a Copilot answer.

The exposure was always there. Copilot just made it real. That is what most security teams are responding to when they ask "is Copilot a data leak risk?" The answer is no, Copilot itself is fine. Your permissions are the question.

The four highest-risk patterns to fix before turning Copilot on

These are the patterns I look for first in any Copilot readiness audit. Each one is fixable in under an hour.

1. "Anyone" sharing links on document libraries

The "Anyone with the link" sharing option in SharePoint creates a URL that bypasses authentication. Anyone with that URL can read the document, including people outside your organisation. In most tenants there are documents that were shared this way years ago for a one-off and never revoked.

Copilot does not retrieve documents shared with "Anyone" links to internal users (the link bypass does not apply within the tenant), but the documents typically also have internal permissions that make them broadly readable, and those Copilot does retrieve. The combination is the risk.

The check: SharePoint Admin Centre, Sharing, look for the report on "Anyone" links. Microsoft also documents the sharing controls in the shareable links reference. Disable Anyone links at the tenant level if you have not already, and audit existing ones.

2. "Everyone except external users" group with broad library access

This is the group SharePoint applies as a default in some templates. It contains every internal user. When a library is shared with this group, every employee can read everything in the library. Often nobody intended that. The default just landed.

The check: SharePoint Admin Centre, Active sites, sort by storage or activity. Open the top twenty most-active sites. Look at site permissions. Look at top-level library permissions. Anywhere you see "Everyone except external users" with edit or read access, ask whether that was deliberate.

3. Sites with permissions broken from the parent that nobody remembers why

Inheritance in SharePoint flows top-down from the site to libraries to folders to items. When inheritance is broken at any level, the unique permissions can drift over time and nobody remembers the original reason.

I see this most often on libraries that were created for a specific project five years ago, given unique permissions, then quietly used as general-purpose libraries. The unique permissions never get reset, and the library ends up with stranger access patterns than the rest of the site.

The check: PowerShell or third-party tooling can enumerate sites and libraries with broken inheritance. Microsoft's permission customisation reference covers the underlying mechanics. For each broken-inheritance library you find, ask the site owner whether the unique permissions still make sense. If they do not remember why, restore inheritance.

4. SharePoint Online migration sites with the migration service account as Site Collection Admin

Tenants that migrated from on-premises SharePoint or from a file share often left the migration service account in place as a Site Collection Admin. That account has full read access to everything. If anyone ever uses Copilot under that identity, the answer set is the entire migrated content.

The check: SharePoint Admin Centre, Active sites, click into sites that were created during the migration window. Site permissions, look for service accounts with admin roles. Remove anything that is not actively needed.

The 60-minute audit you can run today

If you have one hour, this is the audit that produces the most useful output. It does not require Purview, SharePoint Advanced Management, or any third-party tool. It does require admin access to the SharePoint Admin Centre and basic PowerShell.

10 minutes. SharePoint Admin Centre, Sharing settings. Pull the report on "Anyone" links across the tenant. Note any sites where the count is non-trivial.

15 minutes. Active sites report, sort by activity in the last ninety days. Open the top ten by activity. For each, click into Site Permissions and into the top one or two libraries. Look for "Everyone except external users" or anonymous groups with broad access. Note anything unexpected.

15 minutes. Search the tenant for known sensitive content types: contracts, salaries, HR records, financial reports. Use SharePoint Search with the site:contoso.sharepoint.com syntax. Open the top results and check the permissions. If sensitive content is sitting in libraries with broad access, you have your top priority.

10 minutes. OneDrive review. Active sites includes OneDrive accounts. Look for the OneDrive of any departed staff in the last twelve months. Confirm those have been transferred to a manager and locked down, or properly deleted.

10 minutes. End-user reality check. Ask three random users to send you "the most sensitive document you have access to". The answers will be more revealing than any report. If a graduate intern can see the executive compensation spreadsheet, you have found something to fix.

Output of the audit: a short prioritised list of specific permission issues to fix, sorted by sensitivity of content and breadth of exposure. Fix the top three before Copilot rollout. The rest can be background work over the following months.

Restricted Access Control: what it is, and whether you need it

Restricted Access Control (RAC) is a SharePoint feature that lets you restrict access to a site to a specific group, regardless of what other permissions exist. It is documented in detail at Microsoft Learn.

The use case for RAC is sites with content that should only ever be accessed by a defined group, even if other permissions accidentally drift. HR sites with sensitive employee data, executive sites with board materials, finance sites with pre-public results. RAC is the belt-and-braces guarantee that no permission drift can expose the content.

You need RAC if you have business-critical sites where the cost of an exposure is high and the chance of permission drift is real. For most mid-sized tenants, that is two to five sites at most.

You do not need RAC if your sensitive content is already in tightly-permissioned libraries within otherwise-broad sites. RAC adds rigidity. For most content, a clean permission structure is sufficient and easier to maintain.

RAC requires SharePoint Advanced Management licences. For tenants without those licences, the alternative is disciplined permission hygiene plus sensitivity labels for the highest-risk content.

Sensitivity labels: the lightweight version for teams without Purview

Sensitivity labels are part of Microsoft Purview Information Protection. The full deployment requires Purview licensing and a label policy designed by someone who understands compliance. The lightweight version is achievable without that.

The lightweight pattern:

1. Enable sensitivity labels at the tenant level (this works without full Purview).
2. Create three labels: Public, Internal, Confidential.
3. Apply Confidential to your most sensitive sites manually. This sets a flag that prevents external sharing and triggers warnings on overly-broad permissions.
4. Configure Copilot's behaviour around Confidential labels. By default, content with a Confidential label can still be cited by Copilot, but the citation includes the label so users see the sensitivity context.

For tenants serious about restricting Copilot from grounding on certain content, Purview offers the DLP for Copilot policies that block Copilot from including labelled content in responses. That is the full enterprise pattern. The lightweight version above gets you most of the benefit without the licence cost.

The full official guidance is in Microsoft's secure foundation guide for Copilot. For a mid-sized tenant, you will not need most of it. Start with three labels, apply them where it matters, and revisit if you grow.

The "rolling launch" approach (turn Copilot on for one team first)

Most Copilot rollout articles assume tenant-wide enablement on day one. For risk management, you should not. The rolling launch approach is simple and dramatically reduces the chance of a high-profile early surprise.

The pattern:

1. Pick a single team of ten to twenty people in a low-risk function (marketing, internal comms, IT itself). Give them Copilot licences and enable Copilot for their accounts.
2. Run for two weeks. Ask them to use Copilot normally and to flag anything they see that surprised them. "I didn't know I could see this" is the gold-standard signal.
3. Investigate every surprise. Most will be permission drift or duplicate content issues. Fix them.
4. After the first fortnight, expand to a second team. Repeat.
5. After three or four cohorts, you have a tenant where the obvious oversharing patterns have been hunted and fixed by real users running real queries. Tenant-wide rollout from there is much lower risk.

The rolling launch costs you a few weeks of timing. It buys you specific, real-world surprises before they become a board-level incident.

Where to draw the line: what cleanup is good enough vs perfect

Permission cleanup is never finished. The tenant accumulates new permissions every day. The question is when it is good enough to enable Copilot.

The threshold I use:

• The four highest-risk patterns above are addressed
• The top ten most-active sites have been reviewed and any obvious oversharing fixed
• Sensitive content (HR, finance, legal) has been audited and properly permissioned
• The rolling launch has run for at least two cohorts without a Severity 1 surprise

That is good enough. It is not perfect, and it does not need to be. The remaining cleanup happens in flight as the rolling launch continues to surface issues. Trying to perfect permissions before turning Copilot on is how the project never ships.

Frequently asked questions

Why does Copilot make oversharing worse?

Copilot does not make permissions worse. It changes the discovery layer. Documents that were technically accessible but practically invisible become trivially findable through a chat prompt. The exposure existed before; Copilot makes it real and visible.

What's the most dangerous SharePoint permission pattern?

"Anyone with the link" sharing combined with broad internal permissions on the same content. The link gives external access; the internal permissions give Copilot retrieval visibility. The combination is the highest-risk pattern in most tenants.

Do I need Restricted Access Control to use Copilot safely?

No, but it helps for two to five business-critical sites where the cost of permission drift is high. For most mid-sized tenants, RAC is overkill. Disciplined permission hygiene plus sensitivity labels for the highest-risk content gets you most of the benefit without the licence cost.

What's the difference between RAC and sensitivity labels?

RAC enforces who can access a site, regardless of other permissions. Sensitivity labels classify the content itself and trigger behaviour (encryption, sharing restrictions, Copilot DLP). RAC is access control; sensitivity labels are content classification. Use RAC for site-level isolation; use labels for document-level classification.

Do I need SharePoint Premium / SharePoint Advanced Management?

For most tenants under one thousand users, no. The basics covered in this article (cleanup of broad permissions, three sensitivity labels, the rolling launch) are achievable without Premium. Premium becomes worth the spend when you have hundreds of sites, regulated content, or compliance requirements that need automated enforcement at scale.

How do I find the 'Anyone with the link' sharing in my tenant?

SharePoint Admin Centre, Sharing settings. The sharing report shows which sites have Anyone links and how many. You can disable Anyone links at the tenant level (Settings, Sharing, set the slider to "Existing guests" or stricter) and existing links will stop working.

How do I find sites with 'Everyone except external users'?

SharePoint Admin Centre, Active sites, then click into individual sites and check Site Permissions. There is no built-in tenant-wide report for this in the standard admin centre. PowerShell or third-party tools can enumerate it. The pragmatic version is to manually check the top twenty sites by activity.

Can I roll out Copilot to one team first?

Yes. Copilot licensing is per user, so you can enable it for a single team without enabling it tenant-wide. The rolling launch pattern (one team for two weeks, then expand) is the recommended approach for risk management.

How long does a permissions cleanup actually take?

For a mid-sized tenant, the four highest-risk patterns can be addressed in two to four weeks of focused work. A complete cleanup of every permission drift is multi-month and not necessary before Copilot rollout. Get to "good enough" and let the rolling launch surface the remainder.

What happens if a user can suddenly see something via Copilot they couldn't see before?

The user could always see it; Copilot just made it discoverable. The technical access was already there. Investigate the permission that allowed the access in the first place and fix it at the source. Treat the Copilot citation as a useful audit signal, not as the cause.