Copilot Grants No New Access. It Just Makes Years of SharePoint Sprawl Searchable.

Sarah works in marketing. She has never opened a finance application, never sat in a compensation review, and never been handed a payroll file. She can also read the salary workbook for the entire company, and she has been able to for two years.

Nobody made a mistake on the day that became true. No account was breached. The access arrived one reasonable decision at a time, and it sat there unnoticed until an AI assistant made it trivial to find.

How a marketing hire ends up one prompt away from payroll#

The path is worth tracing, because it repeats in almost every tenant:

1. 2021. A finance budget site is created. The salary workbook lives inside it. Five people from finance are given access individually. Everything about this is correct.
2. 2022. Budget season arrives and department heads need to upload their numbers. Instead of sharing a single folder, someone shares the entire site with a group called Department Leads. The group now reaches the whole document library, salary workbook included.
3. 2023. Department Leads changes membership the way every group does. New members inherit access to the finance site silently. Nobody is notified that they just gained the ability to read compensation data.
4. 2024. Sarah moves into a role that puts her in Department Leads. She now has access to the salary workbook and has no idea.

Then Sarah asks Copilot a question about budget or compensation. Copilot checks what she can open, finds the workbook, answers, and cites it.

The same thing happens through third-party assistants connected to Microsoft 365. If a tool inherits a user's Microsoft 365 permissions, it inherits this problem too.

Copilot respects permissions, and that is exactly the problem#

Copilot indexes and answers from content the user can already reach across SharePoint, OneDrive, Teams, and Exchange. Ask it to read a colleague's mailbox and it will not. Ask about payroll when you are not a member of the HR site and nothing comes back.

Ask about last year's compensation changes when you inherited access to the finance site, though, and there is no obstacle at all. The document is in scope, so it gets sourced and cited.

This is why permission auditing is the first layer of data protection rather than a later one. Sensitivity labels and DLP policies matter, and they work far better on top of an access model that someone has actually looked at. Entra roles and group assignments deserve the same treatment for the same reason.

Start with the built-in report if you already have the license#

Open the SharePoint admin center and go to Reports, then Data access governance. Two reports there do useful work.

Site permissions across your organization is a snapshot across SharePoint and OneDrive. It returns files and items with unique permissions, meaning inheritance was broken by a sharing link on a document or folder, along with total permissioned users, guest user permissions, external participants, and groups. It exports cleanly.

Treat it as a bird's eye view. It tells you which sites deserve attention and stops short of telling you why.

Site permissions for users goes a level deeper. Create a report for SharePoint or OneDrive, name it, and add the users you want to inspect. Microsoft documents the report in full in the data access governance reference (opens in new tab).

Two constraints as of September 2026. You add users individually, up to 100 per run, which rules out inspecting a large tenant in one pass. And generation takes a few hours, so start it and come back rather than watching the status.

Per user, the output gives you:

• Direct access to items, the count of files and folders shared with that user directly
• Indirect access to items, the count reachable through group membership
• Site shared, a yes or no on whether the entire site is shared with them
• Site privacy level, sharing level, and primary admin

That fourth row is where the interesting findings live. A user with zero direct and zero indirect item access can still show the whole site shared with them, which is how an MSP account or a former project member ends up sitting on the finance site.

Where the report runs out: it never names the group or the permission level that granted the access, and the detailed download arrives as a zip containing one CSV per user rather than a single combined file. For spot checks on named users it holds up well. For a tenant-wide picture it does not.

Go tenant-wide with PowerShell when the report runs out#

The gap the built-in report leaves is the one worth closing with a script. The walkthrough in the video above runs a PnP PowerShell audit that loops every site in the tenant and writes a single combined export.

What you need before running anything like it:

• An account with SharePoint Administrator rights at minimum, or Global Administrator
• PowerShell 7 or later
• The PnP PowerShell module
• Your tenant name and SharePoint admin URL
• An app registration in the target tenant with the permissions to read site and permission data, plus a client certificate

The certificate is what makes the connection headless, so the same audit can run as a scheduled job across the tenants you manage rather than as an interactive session you have to babysit.

The run produces two exports. The first is a permissions inventory covering every site, and the columns that earn their place are:

• Type, distinguishing a group owner from a group member from a direct assignment
• Granted through, showing whether the user is a member, an owner, a visitor, or holds direct permissions from a legacy classic site

Those two columns answer the question the built-in report leaves hanging. When Oliver Queen turns up with full control on a project site, you can see immediately that it came from a direct assignment rather than group membership, which tells you how to fix it.

The second export covers site configuration: sharing capabilities, site type, default link sharing permissions, default link types, and the last content modified date across the whole site. That last column doubles as an inactivity signal.

Five cleanup actions worth running on every tenant#

1. Strip the legacy Everyone except external users claim from sensitive sites#

This claim attached itself to sites created in the classic era and effectively means anyone in the organization can read the site. Filter your export for it.

The combination that matters is a site carrying this claim and set to public. Copilot can index that site and return its contents to any employee who asks. On a finance or HR site, remove the claim and set the site to private. On an all-company site created for exactly this purpose, leave it alone.

2. Clear stale guest access#

Filter for external users. You will typically find three flavors: guests who arrived through group membership, guests assigned directly, and guests from projects that ended years ago. Classic sites are the usual home for the directly assigned ones. Work through what the business still needs and remove the rest.

3. Replace direct permissions with group membership#

Filter the type column for individual users holding direct permissions. Full control assigned straight to a person is a lifecycle problem waiting to happen. When that person changes departments or leaves, nothing about their group membership reflects it, and nobody has a reason to look.

Owners and members of groups can be managed. One-off grants cannot.

4. Hunt for group assignments that do not belong#

Every site has its own owners and members groups. Anything else assigned to a site is worth a second look, particularly on sensitive sites.

This is the Department Leads problem from the opening, visible in a spreadsheet. A group whose name has nothing to do with the site it can reach is the single highest-yield anomaly in the export.

5. Fix public group visibility and over-permissive sharing defaults#

In the site configuration export, look for groups set to public that should be private, and sharing capability set to allow new and existing guests where internal only is the right answer. A finance site set to public with guest sharing enabled is a finding on its own, before anyone looks at a single permission.

Use the last activity date in the same export to flag sites nobody has touched in months. Those are candidates for retirement on a policy (opens in new tab) rather than another round of permission tuning.

Where permission auditing stops and data classification starts#

Two of these findings you can resolve alone. The rest need the business, because you are reading site names and guessing at sensitivity.

Expect to hear that nobody knows where a given site came from. It is the most common answer on these calls, and it is honest. When the business cannot tell you what lives in a site, permission auditing has reached its limit and the next layer is finding the sensitive data itself, which is what a DLP simulation is for.

The takeaway holds either way. Copilot is only as secure as the access model underneath it. Clean permissions turn it into a genuinely useful way for employees to work with what the organization knows. Stale permissions turn it into a remarkably efficient way to discover access nobody remembered granting.