Copilot Data Exposure: The Governance Failure of Deploying AI Without Permission Remediation

Copilot Readiness: The Permission Cleanup Most Organisations Skip

Microsoft Copilot for Microsoft 365 is the most significant change to how users interact with corporate data since SharePoint Online replaced file servers. It is also, without careful preparation, the most significant data exposure risk most organisations have ever deployed.

The reason is simple and widely misunderstood: Copilot does not have its own permissions. It inherits the permissions of the user who invokes it. Every file, every email, every Teams message that a user can access - Copilot can surface, summarise, and present. The Semantic Index, which powers Copilot's understanding of organisational data, indexes everything the user has access to.

The Oversharing Problem

In a typical Microsoft 365 tenant that has been operational for three or more years, the permission landscape is a disaster. This is not an exaggeration - Microsoft's own readiness documentation acknowledges the problem. Common patterns include:

• SharePoint sites with "Everyone except external users" permissions: This is the default for many auto-created sites. It means every employee in the organisation can access the content. Before Copilot, this was a theoretical risk - users would have to navigate to the site and browse. With Copilot, a simple prompt like "summarise our Q3 financial results" will surface content from any site the user can access, including HR sites, finance sites, and board documentation.

• Orphaned team sites: When a Microsoft Teams team is abandoned but not deleted, its underlying SharePoint site retains its permissions. Former members retain access indefinitely unless the site is explicitly cleaned up. Copilot will index and surface this content.

• Broken inheritance: SharePoint's permission inheritance model means that sub-sites, libraries, and individual files can have unique permissions that diverge from the parent. Years of "share with specific people" actions create a tangled web that no human can audit manually.

• OneDrive oversharing: Users who have shared files from their OneDrive with broad audiences (entire departments, "everyone") have created access paths that persist until explicitly revoked.

The SharePoint Permission Audit

Before enabling Copilot for any user group, conduct a comprehensive SharePoint permission audit. This is not optional, it is the single most important readiness activity.

Step 1: Generate a sharing report

Navigate to the SharePoint admin centre > Reports > Sharing or use the SharePoint Online Management Shell:

Get-SPOSite -Limit All | ForEach-Object {
    Get-SPOSiteGroup -Site $_.Url | Where-Object {
        $_.Users -contains "Everyone except external users" -or
        $_.Users -contains "Everyone"
    }
} | Export-CSV -Path "overshared-sites.csv"

This identifies every site where broad access groups have been granted permissions. The output will be sobering.

Step 2: Review SharePoint Advanced Management (SAM) reports

If licensed for SharePoint Advanced Management (included in Microsoft 365 E5 or as an add-on), use the Data access governance reports in the SharePoint admin centre. These provide:

• Sites shared with "Everyone except external users"
• Sites with sensitivity labels applied (or crucially, without labels)
• Oversharing reports showing sites with the most broadly shared content

Step 3: Remediate the highest-risk sites

Prioritise remediation based on content sensitivity:

1. Finance and HR sites: Remove all broad access groups. Replace with explicit security groups containing only authorised personnel.
2. Leadership and board sites: Restrict to named individuals. Apply "Highly Confidential" sensitivity labels.
3. Project sites: Review membership. Remove users who are no longer project members.
4. Department sites: Ensure access is limited to the department security group.

Semantic Index Scope Control

The Semantic Index is the AI engine that processes and indexes organisational content for Copilot. By default, it indexes all content the user can access. You can control its scope:

Restricted SharePoint Search: In the SharePoint admin centre, enable Restricted SharePoint Search under Settings > Search. Restricted SharePoint Search is a temporary search-scope reduction control, not a security boundary. It narrows search and Copilot discovery to a curated allowed list while permissions are remediated. This is a critical control during the transition period while permissions are being cleaned up.

Site-level exclusion: Individual SharePoint sites can be excluded from Copilot indexing using the SharePoint Management Shell:

Set-SPOSite -Identity "https://tenant.sharepoint.com/sites/HR-Confidential" -RestrictContentOrgWideSearch $true

This prevents Copilot from indexing the site's content regardless of user permissions.

Sensitivity Label Exclusions

Microsoft Purview sensitivity labels provide primary protection intent. However, for strict boundaries, Microsoft's documented pattern primarily utilises Data Loss Prevention (DLP) mapped to the Microsoft 365 Copilot location. While sensitivity labels map protection intent, excluded items may still surface in citations under specific scenarios.

Deploy a label taxonomy that includes:

• Public: General access
• Internal: General access (this is the default label for all new content)
• Confidential: Triggers DLP protections alerting on Copilot usage
• Highly Confidential: Strictly scoped access with robust encryption
• Regulatory: Heavily restricted access, encrypted, strictly bounded by DLP

Configure auto-labelling policies in Purview to detect and label sensitive content patterns (financial data, personal data, health records) to ensure these DLP boundaries hold.

Step-by-Step Readiness Checklist

1. Audit SharePoint permissions using SAM reports and PowerShell. Document all sites with "Everyone" or "Everyone except external users" access.
2. Remediate high-risk sites by replacing broad access with explicit security groups.
3. Enable Restricted SharePoint Search to limit Copilot's index to approved sites during the transition.
4. Deploy default sensitivity labels so that all new content is automatically classified.
5. Configure Copilot exclusions on sensitivity labels for Highly Confidential and Regulatory content.
6. Run a pilot with a small group of users (10-20) in a controlled department. Monitor Copilot interaction logs in the Purview audit log for unexpected data access patterns.
7. Review Copilot audit logs after 2 weeks. Search the unified audit log for CopilotInteraction events. Identify any instances where Copilot surfaced content from sites outside the user's intended scope.
8. Expand gradually by department, adding sites to the Restricted SharePoint Search allowed list as their permissions are verified.
9. Establish ongoing governance: Create a recurring access review in Entra ID Governance for all SharePoint site owners, requiring quarterly validation of site membership and permissions.

The organisations that skip this preparation and enable Copilot tenant-wide on day one will discover, often through an embarrassing incident, that their most sensitive data is now one natural-language prompt away from any employee. The permission cleanup is not optional, it is the foundation of responsible AI deployment.