Auto-Labeling Data at Rest in SharePoint: Closing the Oversharing Gap Before Copilot

Setting a default sensitivity label on a SharePoint library has always protected what lands there next. It never touched what was already sitting in the library. A new Purview capability finally closes that gap — and it matters more than it sounds, because every one of those unlabeled files is fair game for Copilot to summarize.

Use Case

A client had done the right thing months ago: every SharePoint library got a default sensitivity label, so new uploads were protected automatically. The problem was everything uploaded before that policy existed — years of contracts, HR files, and financial documents — sat completely unlabeled. Nobody wanted to relabel thousands of files by hand, so the org quietly carried that risk while planning a Microsoft 365 Copilot rollout.

Solution

Microsoft Purview now extends default-label inheritance to existing content at rest in a library, not just new or edited files. Once a library has a default label configured, Purview can apply that same label retroactively to the files already stored there — without anyone having to open and relabel each one manually.

The practical effect: you can close the historical oversharing gap in a library before you ever turn on Copilot for the people who use it, instead of discovering the gap because Copilot happily surfaced something it shouldn't have.

Prerequisites

• A published sensitivity label policy with a default label configured on the target SharePoint library.
• Licensing that covers Purview Information Protection auto-labeling (this rides on the same entitlement as auto-labeling policies generally — check your current label policy scope if you're unsure).
• Compliance Administrator (or equivalent) permissions to configure the library's default label and review labeling activity.

Implementation

1. In the SharePoint admin center (or the library's own settings), confirm a default sensitivity label is set on the target document library.
2. In the Microsoft Purview portal, locate the corresponding label policy and confirm the option to apply the default label to existing content at rest is enabled for that library.
3. Let the initial pass run against a single, well-understood library first — treat this like any bulk classification job, not a one-click fix across your whole tenant on day one.
4. Use Activity explorer in Purview to review which files were labeled, and spot-check a sample to confirm the label lines up with what the content actually is.
5. Once you're comfortable with the results, expand the same default-label configuration out to your other libraries, prioritizing the ones with the oldest and least-governed content first.

Checking labeling coverage with Advanced Hunting

Once labeling activity starts flowing, a simple Advanced Hunting query against CloudAppEvents is a fast way to confirm files are actually picking up the label, without waiting for the Purview reporting UI to catch up:

// Adjust table/column names to your tenant's schema
CloudAppEvents
| where ActionType == "FileSensitivityLabelApplied"
| where Timestamp > ago(1d)
| summarize count() by SensitivityLabelName, SiteUrl

Why this matters before you flip on Copilot

Microsoft 365 Copilot respects existing permissions, but permissions and protection are not the same thing — a file with no sensitivity label carries no encryption, no watermarking, and no downstream DLP trigger tied to its content. Auto-labeling data at rest means you're not relying on every past uploader to have made the right labeling choice; the library-level default now applies to everything in it, past and present.

If you're mid-way through a Copilot rollout and haven't checked this, it's worth pausing to confirm your oldest, most sensitive libraries aren't sitting there unlabeled while everyone else's inbox gets AI-generated summaries pulled from them.