Why Copilot makes old mistakes visible
Before Copilot, an overshared folder was mostly harmless because nobody found it. The salary spreadsheet in a team site that "everyone except external users" can read sat there for years. Copilot searches across everything the user has access to and summarises it on request. A question like "what are the salaries in the sales team?" turns a forgotten permission into an answer.
So Copilot readiness is mostly not about Copilot. It is about the permissions and sharing settings that have grown in SharePoint, OneDrive and Teams, and about deciding which of them are intended.
Step 1: read the tenant-wide sharing settings
Start with the defaults, because they shape every new link people create. With the SharePoint Online Management Shell:
Connect-SPOService -Url "https://example-admin.sharepoint.com"
Get-SPOTenant | Select-Object SharingCapability, DefaultSharingLinkType, DefaultLinkPermission,
RequireAnonymousLinksExpireInDays, FileAnonymousLinkType, FolderAnonymousLinkType, ShowEveryoneExceptExternalUsersClaim
DefaultSharingLinkType: if it isAnonymousAccess("Anyone with the link"), every share starts as a public link.Direct(specific people) orInternalare safer defaults.DefaultLinkPermission:Viewis the safer default; people can still choose edit.RequireAnonymousLinksExpireInDays: if anyone links are allowed at all, give them an expiry.
# Safer defaults for new links (existing links are not changed)
Set-SPOTenant -DefaultSharingLinkType Direct -DefaultLinkPermission View
Set-SPOTenant -RequireAnonymousLinksExpireInDays 30
Changing the default does not touch existing links, so it is low risk. Announce it anyway: people notice when the share dialog behaves differently.
Step 2: find the broadly shared places
Sites that allow anonymous sharing
Get-SPOSite -Limit All -IncludePersonalSite $false |
Where-Object { $_.SharingCapability -eq "ExternalUserAndGuestSharing" } |
Select-Object Url, Title, SharingCapability, Owner | Sort-Object Url
Public Microsoft 365 groups and teams
A public team's files are readable by everyone in the organisation. That is fine for a canteen menu, not for HR.
Connect-MgGraph -Scopes "Group.Read.All"
Get-MgGroup -Filter "groupTypes/any(c:c eq 'Unified')" -All -Property DisplayName, Visibility, Mail, CreatedDateTime |
Where-Object { $_.Visibility -eq "Public" } |
Select-Object DisplayName, Mail, CreatedDateTime | Sort-Object DisplayName
"Everyone except external users" and anyone links
Permissions granted to "Everyone except external users" and existing anyone links are hard to enumerate reliably with a few lines of PowerShell across a large tenant. SharePoint Advanced Management, which Microsoft includes with Microsoft 365 Copilot licences, provides data access governance reports for exactly this: sites with the most sharing links, anyone links and "everyone" permissions. Use them as the work list, sorted by how sensitive the content is.
Step 3: decide per site, not per file
Do not try to fix permissions file by file. Sort the findings into three groups:
| Finding | Typical example | Action |
|---|---|---|
| Intended and harmless | Intranet news, templates, canteen menu | Keep, document |
| Intended, but too broad | Project site readable by the whole company | Owner reduces access to members; private team |
| Not intended | HR, finance, management, legal content broadly shared | Remove broad permissions now; restrict from Copilot until cleaned |
For sites that cannot be cleaned in time, Restricted Content Discovery removes a site from organisation-wide search and Copilot without changing its permissions:
Set-SPOSite -Identity "https://example.sharepoint.com/sites/finance" -RestrictContentOrgWideSearch $true
This is a stopgap, not a fix: people who can open the site still can. Treat each use as a ticket with an owner and a date.
Step 4: labels where they add something
Sensitivity labels with encryption limit who can open a document, wherever it ends up, and Copilot respects them. They are powerful and they create friction. Introduce them in an order people can follow: first a small set of labels with clear names, default labels for a few sensitive sites, then encryption for the content that truly needs it. Labelling everything on day one usually ends with everyone choosing "General".
Step 5: pilot with the right people
Start Copilot with a pilot group that includes IT, a few power users and someone from HR or finance who knows where the sensitive content lives. Ask them to try to find things they should not see. That is the most effective oversharing test there is. Where a works council or staff representation is involved, bring them in before the pilot: usage reports, prompts and the Copilot dashboard raise questions about employee monitoring that are better answered early.
Common mistakes
- Treating Copilot readiness as a licence project instead of a permissions project
- Fixing file by file instead of site by site, with site owners
- Using restricted search as the permanent answer
- Rolling out labels to everyone at once
- Forgetting OneDrive: personal folders shared with "everyone" years ago
Checklist
- Tenant sharing defaults read and documented; default link set to specific people or internal, view
- Anyone links restricted or given an expiry
- Sites with external and anonymous sharing listed and confirmed by owners
- Public teams and groups reviewed; sensitive ones made private
- Data access governance reports used as the work list
- Sensitive sites cleaned, or temporarily excluded with an owner and a date
- Small label set defined; default labels for sensitive sites
- Pilot group including people who know where sensitive data lives
- Employee representatives involved before the pilot