Copilot for M365: Prepare Your Tenant Before Deployment
Microsoft 365 Copilot surfaces information users already have permission to access. That sentence is both the product's core value proposition and its most important security constraint. A well-governed tenant means Copilot finds the right answers. A poorly governed one means it finds things it shouldn't — and serves them to users who shouldn't see them.
Most Copilot deployments that run into data exposure problems were not caused by a Copilot misconfiguration. They were caused by permission and governance debt that was already there before Copilot was turned on. Copilot just made it visible.
This article covers the three areas that matter most before you flip the switch: permissions and oversharing in SharePoint, sensitivity labels, and DLP policies for Copilot. It uses Microsoft's recommended Pilot → Deploy → Operate framework as the structural backbone, but the focus is on the specific technical steps — not the change management narrative.
The deployment framework: Pilot → Deploy → Operate
Microsoft's recommended approach is a three-phase model. The phases are not strictly sequential — organisations with strong existing governance can skip the pilot — but the sequence reflects the order in which risks compound.
This article focuses on the work that belongs in Phase 1 and the first half of Phase 2 — the steps that must be done before Copilot is in the hands of most users.
Oversharing: find it before Copilot does
Oversharing in Microsoft 365 tenants is almost never intentional. It accumulates over time through a combination of default sharing settings, convenience decisions ("share with everyone"), and permission sprawl on SharePoint sites that never went through proper lifecycle management. Common patterns according to Microsoft's own documentation include:
- Sites where Everyone except external users (EEEU) has been granted access — often set once and forgotten
- Files and folders shared via "Anyone with the link" links with no expiry
- Sites with broken permission inheritance — individual items permissioned differently from the parent
- Sites with no active owner, which drift toward over-permissioning over time
- Inactive sites whose content still surfaces in search and Copilot responses
Step 1 — Run the Data Access Governance reports in SharePoint Admin Center
SharePoint Advanced Management (included with your Copilot licence) provides permission state reports that show oversharing patterns across the tenant. Start here.
Step 2 — Remediate with SharePoint Advanced Management controls
Once you have identified overshared sites, SAM gives you three remediation options depending on urgency and scope:
Restricted SharePoint Search — the safety net, not the solution
If your tenant has not been through a permissions audit and you need to deploy Copilot on a timeline, Restricted SharePoint Search (RSS) gives you a way to proceed safely. It lets you maintain an allowed list of up to 100 reviewed and approved SharePoint sites. Copilot chat and organisation-wide search are limited to those sites until the list is expanded.
Microsoft.Online.SharePoint.PowerShell module version 16.0.24322 or later. Enable-SPORestrictedSearch, Get-SPORestrictedSearchStatus, Add-SPORestrictedSearchAllowedList, and Get-SPORestrictedSearchAllowedList are not available in older versions. Install or update before running:
Install-Module Microsoft.Online.SharePoint.PowerShell -Scope CurrentUser -ForceUpdate-Module Microsoft.Online.SharePoint.PowerShell -ForceGet-Module Microsoft.Online.SharePoint.PowerShell -ListAvailable | Select-Object Version
# Requires: Microsoft.Online.SharePoint.PowerShell v16.0.24322+
# Install: Install-Module Microsoft.Online.SharePoint.PowerShell -Scope CurrentUser -Force
# Update: Update-Module Microsoft.Online.SharePoint.PowerShell -Force
# Check: Get-Module Microsoft.Online.SharePoint.PowerShell -ListAvailable | Select-Object Version
# Connect — use -ModernAuth if standard auth fails
Connect-SPOService -Url "https://contoso-admin.sharepoint.com" -ModernAuth $true
# Enable Restricted SharePoint Search
Enable-SPORestrictedSearch
# Verify current state
Get-SPORestrictedSearchStatus
# Add approved sites to the allowed list (up to 100 sites)
# Replace with your actual site URLs
Add-SPORestrictedSearchAllowedList `
-SiteUrls @(
"https://contoso.sharepoint.com/sites/IT",
"https://contoso.sharepoint.com/sites/Marketing",
"https://contoso.sharepoint.com/sites/HR-Public"
)
# View the current allowed list
Get-SPORestrictedSearchAllowedList
# When permissions are remediated across the tenant, disable RSS:
# Disable-SPORestrictedSearch
# Notify Copilot users and your IT team before disabling —
# responses will broaden to the full tenant permission setSensitivity labels: the guardrails that actually work
Copilot checks sensitivity labels at the point of content retrieval. If a document is labelled with encryption and the current user does not have the EXTRACT usage right, Copilot cannot summarise it for that user — even if they have View permissions on the file. Labels are the most direct control over what Copilot can and cannot do with specific content.
There are two requirements before labels protect content in Copilot:
# Connect to Security & Compliance PowerShell
Connect-IPPSSession
# Enable sensitivity labels for SharePoint and OneDrive (required for Copilot)
Execute-AzureAdLabelSync
# Verify the setting is enabled in SharePoint
Connect-SPOService -Url "https://contoso-admin.sharepoint.com"
Get-SPOTenant | Select-Object EnableAIPIntegration
# EnableAIPIntegration should return True
# If False: Set-SPOTenant -EnableAIPIntegration $trueWhat Copilot does with labelled content
Understanding this behaviour is critical before configuring labels for Copilot:
- If a user has VIEW but not EXTRACT usage rights on an encrypted document, Copilot cannot summarise it. It can reference it with a link so the user can open it directly.
- When Copilot generates new content based on labelled sources, it inherits the highest-priority label from the source documents.
- Container labels (applied to SharePoint sites, Teams, Groups) are not inherited by individual files inside those containers. A site labelled "Confidential" does not automatically label the files within it.
- Documents encrypted with user-defined permissions or Double Key Encryption cannot be accessed by Copilot, even when the user has it open in an app.
DLP policies for Copilot
Purview DLP now has a dedicated Microsoft 365 Copilot and Copilot Chat policy location, which gives you two distinct controls:
-RestrictCopilotProcessingOfContent action against the current DLP for Copilot documentation before running in a live environment. Always start in AuditAndNotify mode.Connect-IPPSSession
# Step 1: Create the policy targeting the Copilot location
New-DlpCompliancePolicy `
-Name "Block Copilot - Confidential and above" `
-Comment "Prevents Copilot from processing files labelled Confidential or Highly Confidential" `
-Mode AuditAndNotify # Start in audit mode - switch to Enabled after validation
# Step 2: Add the rule using the Copilot location
# Replace SensitivityLabel GUIDs with your actual label IDs from Purview
New-DlpComplianceRule `
-Name "Restrict Copilot - Confidential" `
-Policy "Block Copilot - Confidential and above" `
-ContentContainsSensitivityLabel @{
"operator" = "And";
"groups" = @(@{
"name" = "Default";
"labels" = @(
@{ "name" = "Confidential" },
@{ "name" = "Highly Confidential" }
)
})
} `
-RestrictCopilotProcessingOfContent ProcessingPrompts
# Retrieve your label GUIDs for reference:
# Get-Label | Select-Object DisplayName, Guid-Mode AuditAndNotify first and let the policy run for 7–14 days. Review the DLP reports in Purview to understand the volume and nature of matches before switching to -Mode Enable. Turning on enforcement without audit data first is the fastest way to generate support tickets.Roles required to manage Copilot DLP policies
Standard DLP admin roles are not sufficient for the Copilot location. You need one of the following:
- Entra AI Admin — manages all aspects of Microsoft 365 Copilot and AI-related enterprise services
- Purview Data Security AI Admin — edits DLP policies for Copilot, views AI content in DSPM; does not have access to read prompt and response content
- Global Administrator — full access, but should not be used for routine DLP management
Monitoring Copilot activity after deployment
Once Copilot is enabled, two monitoring surfaces matter most for admins.
Purview Audit — Copilot interaction logs
Copilot interaction data — prompts, responses, and referenced files — is stored within Microsoft 365 services and discoverable via Microsoft Purview eDiscovery and Audit. Make sure Microsoft Purview Audit is enabled before go-live — otherwise you lose post-deployment visibility into Copilot interactions. No additional Copilot-specific audit setup is required beyond having auditing enabled.
CopilotInteraction record type is generated automatically when Purview Audit is enabled — no additional Copilot-specific audit configuration is required. Verify UnifiedAuditLogIngestionEnabled is True before go-live.Connect-ExchangeOnline
# Verify audit is enabled
Get-AdminAuditLogConfig | Select-Object UnifiedAuditLogIngestionEnabled
# If False: Enable-OrganizationCustomization; Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true
# Search Copilot interaction events (last 7 days)
Search-UnifiedAuditLog `
-StartDate (Get-Date).AddDays(-7) `
-EndDate (Get-Date) `
-RecordType CopilotInteraction `
-ResultSize 1000 |
Select-Object CreationDate, UserIds, Operations, AuditData |
Export-Csv ".\CopilotAudit_$(Get-Date -Format 'yyyyMMdd').csv" -NoTypeInformationCopilot Dashboard and DSPM for AI
The Copilot Dashboard in Viva Insights shows adoption metrics and usage trends. Microsoft Purview Data Security Posture Management (DSPM) for AI shows which sensitive files are being referenced in Copilot interactions — a critical view for understanding whether labels and DLP are working as intended. DSPM for AI availability and depth varies by licence tier — check the current Microsoft Purview licensing documentation for your specific plan before planning governance workflows around it.
Pre-deployment checklist
- Run the Data Access Governance reports in SharePoint Admin CenterIdentify sites with EEEU access, "Anyone" links, and sites without owners. Export and prioritise by traffic.
- Disable "Everyone except external users" at the tenant levelSharePoint Admin Center → Policies → Sharing. Remove EEEU access from any site where it exists. This is the single highest-impact action before enabling Copilot.
- Apply RCD or RAC to high-risk sites not yet remediatedUse Restricted Content Discovery to prevent unreviewed sites from surfacing in Copilot while remediation is in progress. Document which sites are under RCD and set a review date.
-
Enable sensitivity labels for SharePoint and OneDriveRun
Execute-AzureAdLabelSyncand verifyEnableAIPIntegrationis True on the tenant. Required for Copilot to access encrypted files. - Publish a sensitivity label taxonomy and train usersStart with four levels: Public, Internal, Confidential, Highly Confidential. Configure Confidential and above with encryption and EXTRACT restrictions where appropriate.
- Configure auto-labelling for highest-risk content typesRun auto-labelling policies in simulation mode first. Identify the volume of content that would be labelled before switching to enforcement.
-
Create DLP policies for the Copilot location — start in audit modeTarget the Microsoft 365 Copilot and Copilot Chat location. Use
AuditAndNotifymode for 7–14 days before enforcing. Review match volume in Purview DLP reports before switching toEnable. - Verify Purview Audit is enabledWithout Purview Audit, you have no post-deployment visibility into Copilot interaction data. Enable before go-live, not after.
- Review the Copilot Readiness page in the Microsoft 365 admin centerRolling out worldwide in March 2026. Covers deployment essentials, data security, and user experience settings with completion status. Use it to track what remains before go-live.
- If permissions are not fully remediated: enable Restricted SharePoint SearchAdd reviewed and approved sites to the allowed list. Set a date to revisit and disable RSS once the permissions work is complete. Do not leave it on indefinitely.