Audit Stale SharePoint Permissions Before a Copilot Rollout

Official documentation checked October 14, 2026.

A former user’s name in SharePoint is not, by itself, proof of active access or a Copilot data leak. SharePoint can retain cached identity records after an account is deleted. A useful audit separates those records from actual permissions, then corrects verified excessive access with the site owner’s approval.

1. Separate stale identities from current access

Organizational Copilot uses information the signed-in user is permitted to access. The concern is excessive permissions held by real users, not an assumption that Copilot authenticates as an unresolved account. Microsoft’s governance guidance prioritizes overshared sites, broad audiences, sharing links, and ownership.

Microsoft explains that SharePoint’s UserInfo list can retain a deleted user’s details. It also documents identity mismatches when an account is recreated with the same name but a different ID. Its profile-removal procedure is for specified synchronization or ID-mismatch cases under support guidance, not a blanket permission-cleanup script.

2. Inventory a reviewed set of sites with the real cmdlet

Use Get-SPOUser, not Get-SPOSiteUser. The documented prerequisites include SharePoint administrator rights and site collection administrator access to the queried site. The default limit is 500; use -Limit All to avoid silently truncating the account list. See the cmdlet reference.

This example inventories one approved site. Replace the sample tenant and site, use an authorized session, and save the report in a restricted location. It does not change permissions:

Connect-SPOService -Url 'https://contoso-admin.sharepoint.com'
$siteUrl = 'https://contoso.sharepoint.com/sites/finance'
Get-SPOUser -Site $siteUrl -Limit All -ErrorAction Stop |
    Select-Object @{Name='SiteUrl';Expression={$siteUrl}},
                  LoginName, DisplayName, Email, IsSiteAdmin |
    Export-Csv -LiteralPath '.\finance-site-accounts.csv' -NoTypeInformation -NoClobber -ErrorAction Stop

Retain the site URL with each row when reviewing more sites. Record failures as unassessed sites, not empty or clean results. This account inventory is not a complete report of document-level roles, unique permissions, group memberships, or sharing links.

3. Resolve each suspect principal before classifying it

For each candidate, record the exact SharePoint login/claims identifier, principal type, directory object ID where applicable, and business owner. Distinguish an internal user, guest, Microsoft Entra group, and local SharePoint group. Guests may have tenant-specific UPNs; a security group may have no mail address; a local SharePoint group is not an Entra group.

An empty lookup by email or UPN does not establish that a principal is orphaned. Confirm the correct tenant, query permissions, object type, and deletion or recreation history. A disabled account is not a deleted account. Ask the identity administrator to resolve uncertainty rather than feed unmatched strings into a removal loop.

4. Remove only the verified access path

With the owner, inspect the site’s groups and the affected file or folder’s Manage access details. Review direct grants, inherited access, directory-group membership, and sharing links separately. Remove access at the responsible source; removing one link does not cancel a separate group grant. Microsoft’s sharing guidance distinguishes links, direct access, and inherited access.

For an approved removal from one specific SharePoint group, Remove-SPOUser -Site <site-url> -LoginName <verified-login> -Group <exact-sharepoint-group-name> is documented. Omitting -Group removes the principal from all groups at that site; it is not equivalent to a single-group change. The current Remove-SPOUser reference does not list -WhatIf or -Confirm, so do not assume a preview or confirmation prompt protects a bulk command.

Capture the existing access, affected users, approval, and restoration plan before any change. Do not remove an entire valid directory group merely because a stale identity reappears. Do not change DenyAddAndCustomizePages: that controls custom script, not permission inheritance, and enabling scripts introduces a separate security concern.

5. Verify scope and keep the remaining audit visible

Recheck the exact permission source and test representative allowed and denied access using approved test accounts. Confirm that legitimate collaborators still have the intended access. A name disappearing from an account inventory alone is not sufficient evidence, and an empty Copilot answer is not an access-control test.

Track reviewed sites, unresolved identities, unique-permission areas, sharing links, and any OneDrive scope separately. Where licensed and available, use SharePoint Advanced Management access reviews and governance reports to prioritize broader oversharing. Purview retention or deletion policies are not an automatic substitute for access removal when an employee leaves. Complete the organization’s offboarding and ongoing permission-review process before declaring the rollout’s access risks resolved.