The Architecture of the Problem

Microsoft 365 Copilot operates on top of the Microsoft Graph. When a user invokes Copilot — in Teams, Word, Outlook, or through Business Chat — the underlying retrieval mechanism queries Graph on behalf of that user, using their delegated permissions. This is the core of Microsoft's semantic index, which builds a per-user knowledge graph from content the user has access to across SharePoint, OneDrive, Exchange, and Teams.

The critical phrase is has access to. Graph-level access is determined by SharePoint permissions, Exchange mailbox rights, and Teams membership — not by sensitivity label classification. A document marked Confidential \ All Employees with no encryption applied is, from Graph's perspective, a document with standard SharePoint permissions. If the user has read access to the SharePoint library, Copilot can retrieve it, summarize it, and surface its contents in a Business Chat response.

This is where the architectural mismatch lives. Most enterprises applied sensitivity labels at scale under the assumption that the label itself was doing protective work. In many cases, it was — because DLP policies were configured to block external sharing, and Rights Management encryption was applied to the highest tiers. But the middle tier — documents marked Confidential that live in broadly accessible SharePoint libraries — was never truly restricted. Copilot simply makes that exposure visible in a new and operationally significant way.

---

How Copilot's Retrieval Differs from Traditional Search

Classic SharePoint search respects permissions and returns document links. A user still has to open the document, read it, and extract meaning from it manually. The friction is low, but it exists.

Copilot eliminates that friction entirely. A user can ask Business Chat: "Summarize all documents related to our Q3 acquisition strategy" — and if those documents exist in a SharePoint library the user has read access to, regardless of their sensitivity label, Copilot will retrieve, synthesize, and present their contents in plain language. The user does not need to know the documents exist. They do not need to navigate to them. The AI surfaces the information proactively.

This changes the threat model in two ways.

First, overpermissioned users — a near-universal condition in mature Microsoft 365 tenants — now have effective access to content they technically have permission to read but would never have discovered through normal workflows. A finance analyst who was added to a SharePoint site three years ago and forgot about it now has Copilot surfacing that site's confidential deal memos in response to unrelated queries.

Second, data aggregation becomes trivial. Copilot can synthesize content across dozens of documents in a single response. Even if each individual document is appropriately labeled and individually accessible to the user, the aggregated summary may constitute a disclosure that no single document would have triggered — a pattern that GDPR's data minimization principle and HIPAA's minimum necessary standard were designed to prevent.

---

Where Encryption Actually Holds — and Where It Doesn't

Microsoft's official guidance points to Azure Rights Management (Azure RMS) encryption as the mechanism that prevents Copilot from reading labeled content. This is partially correct and worth being precise about.

When a sensitivity label applies Azure RMS encryption, the document is encrypted at rest and in transit. Copilot's retrieval cannot decrypt content it does not have rights to on behalf of the user — if the user's account is not in the Rights Management usage rights for that document, Copilot cannot read it. This is the intended protection boundary.

The problem is the gap between what enterprises think they have encrypted and what is actually encrypted.

Run this KQL query in Microsoft Purview's Content Explorer or via the Compliance portal to audit the actual encryption state of your labeled content:

ContentExplorer
| where SensitivityLabel contains "Confidential"
| summarize
    TotalDocuments = count(),
    EncryptedCount = countif(IsEncrypted == true),
    UnencryptedCount = countif(IsEncrypted == false)
    by SensitivityLabel, Workload
| extend EncryptionCoverageGap = UnencryptedCount
| order by EncryptionCoverageGap desc

In most enterprise tenants, this query returns a significant population of Confidential-labeled documents with IsEncrypted == false. These documents are fully in scope for Copilot retrieval. The label is present. The protection is not.

The reasons for this gap are well-documented in practice: labels were applied retroactively via auto-labeling policies that classify without encrypting, migration projects that preserved metadata but not protection, and label policies configured to recommend rather than enforce encryption at certain tiers.

---

Auditing Copilot's Actual Data Reach

Before making architectural decisions about Copilot scope, you need to know what Copilot can actually reach in your tenant. The following PowerShell script uses the Microsoft Graph API to enumerate sensitivity label distribution across SharePoint sites and cross-reference with site permission breadth — giving you a risk-ranked view of which labeled content is most exposed.

Connect-MgGraph -Scopes "Sites.Read.All", "InformationProtectionPolicy.Read"

$sites = Get-MgSite -All -Property "id,displayName,webUrl"
$report = @()

foreach ($site in $sites) {
    try {
        $drives = Get-MgSiteDrive -SiteId $site.Id
        foreach ($drive in $drives) {
            $items = Get-MgDriveItem -DriveId $drive.Id -Top 999 `
                     -ExpandProperty "sensitivityLabel" `
                     -Filter "sensitivityLabel ne null" `
                     -ErrorAction SilentlyContinue

            foreach ($item in $items) {
                $label = $item.SensitivityLabel
                if ($label -and $label.DisplayName -match "Confidential|Restricted|Highly") {
                    $report += [PSCustomObject]@{
                        SiteName       = $site.DisplayName
                        SiteUrl        = $site.WebUrl
                        FileName       = $item.Name
                        LabelName      = $label.DisplayName
                        IsEncrypted    = $item.File.Hashes -ne $null  # proxy check
                        LastModified   = $item.LastModifiedDateTime
                        DriveId        = $drive.Id
                    }
                }
            }
        }
    } catch {
        Write-Warning "Failed on site: $($site.DisplayName) — $_"
    }
}

$report | Export-Csv -Path ".\CopilotLabelExposureReport.csv" -NoTypeInformation
Write-Host "Report exported: $($report.Count) labeled items found across $($sites.Count) sites."

This gives you a starting inventory. The output should feed directly into your Copilot enablement decision — not the other way around.

---

The Compliance Exposure Is Not Theoretical

GDPR Article 25 requires data protection by design and by default. Enabling Copilot across a tenant where Confidential-labeled personal data exists in broadly permissioned SharePoint libraries — without first auditing encryption coverage — is a defensible argument for a data protection by design failure. The supervisory authority does not need to prove a breach occurred. The architectural decision to enable AI-assisted data aggregation without validating protection controls is the exposure.

HIPAA's minimum necessary standard (45 CFR §164.502(b)) requires covered entities to limit the use and disclosure of protected health information to the minimum necessary to accomplish the intended purpose. A Copilot deployment that allows clinical staff to query across all SharePoint content — including sites containing PHI that the user has incidental access to — creates a structural minimum necessary violation that no BAA with Microsoft resolves. The BAA addresses Microsoft's handling of data. It does not address your architectural decision to enable unrestricted Copilot access.

Internal data governance policies present a third category of risk that is often underestimated. Most enterprise data governance frameworks include language stating that documents classified at a certain tier are accessible only to individuals with a defined business need. Copilot's retrieval model does not enforce business need — it enforces SharePoint permissions. In most tenants, those two things are not the same.

---

Architectural Decisions You Can Make Now

The answer is not to disable Copilot. The answer is to scope it correctly before you enable it broadly, and to close the encryption gap that makes label-based governance insufficient.

Decision one: Enforce encryption on all Confidential and above labels. This is the single most effective control. Use the following PowerShell to audit which label policies currently apply encryption and which do not:

Connect-IPPSSession -UserPrincipalName admin@yourtenant.onmicrosoft.com

$labels = Get-Label | Where-Object { $_.DisplayName -match "Confidential|Restricted|Highly" }

foreach ($label in $labels) {
    $settings = Get-LabelPolicy | Where-Object { $_.Labels -contains $label.ImmutableId }
    $encryptionApplied = $label.EncryptionEnabled

    [PSCustomObject]@{
        LabelName         = $label.DisplayName
        EncryptionEnabled = $encryptionApplied
        EncryptionType    = $label.EncryptionRightsDefinitions
        PolicyCount       = ($settings | Measure-Object).Count
    }
} | Format-Table -AutoSize

Decision two: Scope Copilot licenses to users whose data access is well-governed. Copilot licenses are assigned per user. Assign them first to user populations where SharePoint permissions are tightly controlled — not to the entire tenant. Use Entra ID groups scoped to departments with mature permission hygiene.

Decision three: Enable Copilot interaction logging and route it to Purview. Copilot interactions are auditable. Ensure your audit log retention policy captures Copilot query events and that you have a defined review process for anomalous query patterns — particularly queries that span multiple sensitivity label tiers in a single session.

Decision four: Run a SharePoint permissions audit before Copilot goes live. Overpermissioned sites are the root cause. Use the SharePoint Admin Center's Access Reviews feature or Microsoft Entra ID Access Reviews scoped to SharePoint groups to identify and remediate stale permissions before Copilot amplifies their exposure.

---

Governance Considerations for the Copilot Enablement Decision

The Copilot enablement decision is not an IT decision. It is a data governance decision that IT is being asked to implement. The distinction matters because the risk owners are different.

Your Chief Privacy Officer and General Counsel need to understand that enabling Copilot without closing the encryption gap means accepting that AI-assisted data aggregation will operate across content that your governance policies classify as restricted. That is a risk acceptance decision, not a technical configuration decision.

Document the decision explicitly. If your organization chooses to enable Copilot before achieving full encryption coverage on Confidential-labeled content, that decision should be recorded in your risk register with the specific gap acknowledged, the compensating controls identified, and the timeline for remediation committed. Regulators and auditors respond better to documented, managed risk than to undocumented exposure discovered after the fact.

The Microsoft Purview Data Security Posture Management dashboard (currently in preview for Copilot) provides a starting point for ongoing visibility — but it is a monitoring tool, not a remediation tool. Do not treat dashboard visibility as equivalent to architectural remediation.

---