Copilot oversharing: the seven patterns to fix before rollout

Microsoft 365 Copilot inherits SharePoint's existing permissions rather than adding new ones on top. That means every oversharing pattern that has been quietly accumulating in your tenant for years, EEEU grants, orphaned share links, ownerless sites, broken inheritance, becomes visible the moment Copilot starts proactively surfacing content. These are the seven patterns most Copilot readiness projects have to find and fix, in the order they most often cause the "how did the model see that?" moment.

Why oversharing is a Copilot problem specifically

For most of SharePoint's history, oversharing existed but was not especially noticeable. Users rarely stumbled onto content they had access to but did not know about. Files were reachable only by navigation, search, or direct link, all of which required knowing the content existed in the first place.

Copilot changes that. When a user asks a question, Copilot searches the tenant's entire content graph for anything relevant that the user is permitted to see, then surfaces it in the answer. The user does not have to navigate anywhere or know a document exists. Copilot proactively brings it to them.

That is a feature, not a bug. But it means content that had ambient access, access nobody knew about or that was granted years ago and forgotten, now shows up in every relevant answer for every user who holds that ambient grant. Salary spreadsheets accidentally shared with "Everyone Except External Users" become discoverable via a casual question about staff. Board minutes with an orphaned "Anyone with the link" grant become quotable in an AI-generated summary. Copilot does not create the risk. It exposes it.

Fixing the pre-existing oversharing before rollout is what determines whether Copilot is remembered as an upgrade or a mistake.

Pattern 1: "Everyone Except External Users" grants

What it is. The single most common oversharing pattern in enterprise Microsoft 365 tenants. Somebody, often during a bulk migration or in the early days of the tenant, granted "Everyone Except External Users" (EEEU) as a shortcut for "any colleague". The intent was reasonable: broad internal access, no external leakage. In practice, EEEU is now a blanket tenant-wide broadcast for whichever sites, libraries or folders still carry it.

Why Copilot makes it visible. Copilot treats an EEEU grant as "all internal users can see this". If a folder marked EEEU contains, say, sensitive HR case notes that were dropped there in 2023 without the original owner realising the folder was EEEU, Copilot will surface those notes in an answer for anyone in the tenant who asks a relevant question.

How to find it. SharePoint Advanced Management (SAM) has a Data Access Governance report that specifically identifies sites with EEEU grants and sites with sensitive content combined with broad access. This is the single most valuable report for Copilot readiness. Without SAM, PowerShell against Microsoft Graph works but is far slower.

How to fix it. Replace EEEU grants with either specific security groups (matched to who actually needs the content) or with more granular site-level permissions. For sites where the EEEU grant is genuinely correct (a company-wide news site, for example), leave it in place and confirm the content is genuinely appropriate for tenant-wide access.

How to prevent regression. Turn on SharePoint's default sharing settings to prevent new EEEU grants except with admin approval, and add EEEU grant creation to your standard tenant governance review.

Pattern 2: Long-lived "Anyone with the link" sharing links

What it is. Somebody shared a document externally three years ago. They set the link to "Anyone with the link" so they did not have to manage recipient permissions. The link went out to a contractor, ended up in an email thread, was pasted into a Slack channel, and is now indexed somewhere on the open web. The link is still active. The document is still linked.

Why Copilot makes it visible. The link itself is not the issue for Copilot; the underlying permission grant is. "Anyone with the link" creates a Sharing Link object attached to the document, which affects the document's overall permission surface. If the site also has broad sharing enabled, the document is effectively open.

How to find it. SAM's oversharing report enumerates sharing links by age, type and target. Filter to "Anyone" links older than six months as a first pass. For a more thorough audit, the Microsoft 365 compliance centre has a sharing links report that covers the same ground.

How to fix it. Expire or revoke old "Anyone" links. Set a tenant-wide policy that new "Anyone" links expire automatically (30, 60 or 90 days, depending on your risk appetite). Where possible, replace with named-user sharing.

How to prevent regression. Disable "Anyone" sharing at the tenant level for most sites. Enable it only for the specific sites where external collaboration genuinely justifies it, with mandatory expiry on every link created.

Pattern 3: Ownerless sites

What it is. A team site was created in 2020 for a project. The project ended. The site owner left the organisation. The site is still there. The content is still there. Nobody is authorised to make decisions about it. Because the site was created via a Microsoft 365 group, and because groups without owners still exist, the content remains indexed and reachable by whichever users originally had access.

Why Copilot makes it visible. The content of an ownerless site remains in the search index. Copilot will retrieve from it. The compounding problem is that when Copilot surfaces content from an ownerless site and somebody realises the content should not be surfaced, there is nobody to escalate to, no owner to authorise remediation, and no natural way to make a decision about the site's future.

How to find it. The Microsoft 365 admin centre has an "ownerless groups" report. SAM extends this with site-specific detail: last activity, content sensitivity, member count.

How to fix it. Assign new owners where possible, using the group's members list to find the most likely candidate. For sites where no member remains or nobody accepts ownership, archive the content (Microsoft 365 Archive is designed for exactly this) and remove the site from the search index.

How to prevent regression. Enable Microsoft 365 group expiration policies so groups without recent activity are reviewed. Require every new SharePoint site to have at least two owners. Include ownerless-site remediation in the quarterly tenant governance review.

Pattern 4: Broken permission inheritance

What it is. SharePoint permissions cascade from site to library to folder to item by default. That default is called inheritance. Somebody with edit rights on a library decided a specific folder needed different permissions, maybe stricter, maybe looser, and broke inheritance for that folder. Six months later, nobody remembers why. Two years later, the site owner is trying to manage permissions at the site level and cannot understand why some folders behave differently.

Why Copilot makes it visible. Broken inheritance creates permission islands that are opaque to the people managing the site. A folder with looser permissions than its parent library will surface content in Copilot answers to users the library owner did not realise had access. A folder with stricter permissions than its parent will hide content from users the owner expected to see it, leading to confusing "the model cannot find our document" complaints.

How to find it. SAM's site permissions report flags libraries and folders with broken inheritance. PowerShell against SharePoint can enumerate broken inheritance across all sites. Neither is fast at scale, so start with the highest-value sites: finance, HR, legal, executive team.

How to fix it. For each broken-inheritance instance, decide whether the exception is still needed. If yes, document it in the site's governance notes or in your tenant governance system. If no, restore inheritance.

How to prevent regression. Restrict who can break inheritance to site owners and admins. Make broken inheritance visible in the site governance review. Educate power users on why inheritance matters.

Pattern 5: Overly permissive security groups

What it is. "All Employees" security group. "All Staff". "Everyone in Manchester". Groups that were created to make life easier and are now applied to permissions everywhere. Because they are groups rather than EEEU, they do not show up on EEEU-specific reports, but functionally they can be just as broad.

Why Copilot makes it visible. Broad security groups grant access to everyone in the group. If the group has 3,000 members and the sensitive folder was granted to the group without the granter realising the group was that big, Copilot will surface the folder's content to any of those 3,000 people who ask a related question.

How to find it. Enumerate the largest security groups in the tenant. Cross-reference against site permission grants. SAM's data access governance report will show sites with grants to large groups. Manual review of the top 20 groups by member count catches most of the risk.

How to fix it. For each large group used in a permission grant, review whether all members genuinely need the access. If not, either narrow the group or replace with a more specific group.

How to prevent regression. Prefer role-based access (using groups scoped to a specific role or team) over broad "all staff" groups. Review group membership as part of joiner-mover-leaver processes.

Pattern 6: Dormant external guest accounts

What it is. A contractor was added as a guest in 2022 for a specific project. They were granted access to a team site. The project ended. Nobody removed them. Their guest account is still active. They still have access.

Why Copilot makes it visible. Guest accounts are subject to the same permission model as internal users, so a guest with permission to a site will still have their access respected. Guests typically do not have Copilot licenses, so they cannot ask Copilot questions themselves, but dormant guests are a strong signal of broader governance drift. If guests are not being cleaned up, other stale permissions probably are not either.

How to find it. The Microsoft Entra admin centre's Access Reviews feature can enumerate guests, when they were added, and when they last signed in. SAM has a guest report specifically for SharePoint access.

How to fix it. Deactivate guests who have not signed in for 90 days (or whatever your governance policy dictates). Review guests with high-privilege access every quarter.

How to prevent regression. Use Entra Access Reviews on a scheduled basis. Set guest account expiry at creation time where possible. Include guest cleanup in the tenant governance review.

Pattern 7: Direct user-to-user grants that outlive their reason

What it is. Alice needed a specific document from Bob for a project. Bob shared the document directly with Alice using SharePoint's "Grant Access" feature or a named-recipient sharing link. Alice moved to a different team. The direct grant is still there.

Why Copilot makes it visible. Direct user-to-user grants are the hardest permission type to audit at scale because they are not visible in group membership reports and do not show up in EEEU reports. They accumulate silently. Copilot will surface content granted this way to whichever user still holds the grant, in perpetuity.

How to find it. SAM's item-level permissions report enumerates direct grants. PowerShell against SharePoint can do the same but is slow. Focus on sites containing sensitive content first: finance, HR, legal, executive.

How to fix it. For each direct grant, decide whether it is still needed. If yes, replace with a group-based grant (add the user to an appropriate role group instead of granting them directly). If no, revoke.

How to prevent regression. Discourage direct grants in favour of group-based access. Include direct-grant enumeration in the tenant governance review. Educate users on when to request access via a group and when direct is appropriate (rarely).

How to run the audit

A practical sequence for a mature tenant:

1. License SharePoint Advanced Management if you do not already. It is part of Microsoft 365 E5 Compliance or available as a standalone add-on. Without SAM, most of the work described above is much slower.
2. Turn on the SAM Content Management Assessment. This is the entry point that pulls together sensitivity, sharing, permissions and ownership signals into one view.
3. Address patterns in order of blast radius. EEEU grants (Pattern 1) and orphaned sharing links (Pattern 2) affect the most sites and are the most common cause of visible oversharing in Copilot answers. Do these first.
4. Use Restricted SharePoint Search as a holding mechanism. While remediation is in progress, restrict Copilot to a curated list of already-audited sites so the blast radius stays small.
5. Run a pilot on the fixed subset. A small group of Copilot users running real queries is the most reliable test of whether the remediation has taken. Watch for oversharing complaints, not just quality complaints.
6. Expand once patterns are handled. Only expand Copilot's search scope beyond the audited subset when the audited subset produces clean results at pilot scale.

Timeline for the seven patterns in a mature tenant: typically four to eight weeks of concentrated work, depending on tenant size and existing governance maturity. Ongoing governance is what stops the patterns from coming back.

Frequently asked questions

Does Copilot bypass SharePoint permissions?

No. Copilot only surfaces content the requesting user is permitted to read. The problem this guide addresses is pre-existing overshares: content a user technically has permission to read, but was never expected to see. Copilot proactively surfaces such content in a way that navigation and search rarely did.

Is oversharing the same thing as data leakage?

No. Data leakage is content escaping outside its intended audience, typically externally. Oversharing is content being reachable to a broader internal audience than intended. They overlap when overshared internal content ends up in the hands of someone who then leaks it externally, but the initial pattern is internal-only.

Do we need SharePoint Advanced Management to fix these patterns?

The patterns can be found and fixed with PowerShell against Microsoft Graph, but it is far slower and much less complete. For any tenant above a few hundred users, SAM is close to essential.

How long should we expect a remediation project to take?

For a mature tenant with visible sprawl: four to eight weeks of concentrated work, plus ongoing governance to prevent regression. Smaller tenants or those with strong existing governance may be faster.

What if we do not have time for a full remediation before the Copilot rollout deadline?

Restricted SharePoint Search is the right holding mechanism. Restrict Copilot to a small curated set of already-audited sites, run the pilot there, and expand as remediation progresses.

Where does file-server content fit into oversharing?

If content is still on a file server, it is not visible to Copilot at all, so it cannot cause an oversharing incident directly. But most organisations that still run file servers plan to migrate before enabling Copilot. That is what the Copilot readiness with content on a file server guide covers, linked below.

Related resources

• Microsoft 365 Copilot data readiness
• Copilot readiness when your content is still on a file server
• Zero-access architecture in Cloud Drive Mapper
• Seven questions to ask any third-party Microsoft 365 tool
• Security & Trust

← Back to Solutions