DLP for Copilot uses sensitivity labels to keep Copilot away from content

Now that Microsoft 365 Copilot is running in production environments, admins are under real pressure to keep Copilot and Copilot Chat from exposing the wrong data. In many of the tenants I work with, the discussion soon moves to technical controls, and one question keeps coming up: whether there is a practical way to stop Copilot from processing files and emails that contain sensitive information. The new DLP for Copilot location in Microsoft Purview addresses exactly that. It lets you use sensitivity labels as a direct gatekeeper for Copilot's access to your data.

Purview now offers a dedicated DLP policy location for Copilot

Since late 2024, the Purview portal has offered a dedicated policy location called "Microsoft 365 Copilot and Copilot Chat" when you create a custom DLP policy. For information protection this makes a genuine difference, because DLP now triggers at the point where Copilot tries to process content, not only when users share or modify items. Sensitivity labels do the heavy lifting. If you configure DLP to block Copilot access to items with specific labels (such as "Confidential" or "Highly Confidential"), you decide which documents, emails or chats Copilot can use for prompts and context.

The setup is refreshingly simple. In the Purview portal (see the official docs), create a new DLP policy, choose "Microsoft 365 Copilot and Copilot Chat" as the location, add a condition that content must contain a sensitivity label and list the labels you want to protect. The usual action is "Block", which stops Copilot from using the item's content. None of this works well without a solid label taxonomy. I covered the practical side in an earlier post, Microsoft Purview Information Protection: Building a pragmatic sensitivity label taxonomy.

Pro tip: Start every new DLP for Copilot policy in simulation mode. You'll see what would be blocked before you frustrate end users or disrupt business processes.

DLP for Copilot limits what Copilot reads, not what users see

This DLP policy only blocks Copilot's access to labelled content. Regular user access stays as it is. That nuance catches many teams off guard: even if Copilot can't process a file, the file may still show up in SharePoint or OneDrive search results as a reference, depending on sharing settings and search scope. Users might see the filename, but Copilot can't read the contents or use them as prompt context. This matters most in stricter DLP scenarios, where the aim is to limit AI exposure without hiding content from people altogether.

There is also a hard technical limit. DLP for Copilot only works on files that already carry a sensitivity label. Unlabelled or mislabelled files aren't protected and slip through, however well your DLP rules are written. That's why automated labelling and good label hygiene carry so much weight in Copilot governance.

Every rollout should start in simulation mode

Rolling out DLP for Copilot policies without testing them first is asking for disruption. In the Purview portal you can put a policy in simulation mode and see what would be blocked without affecting productivity (deployment doc here). In practice, a simulation quickly shows how many everyday files actually carry labels and whether your policy is too aggressive. I only recommend enforcing the rule once the simulation has gone well.

A typical rollout runs like this:

flowchart TD
  A["Configure DLP policy for Copilot"] --> B["Enable in simulation mode"]
  B --> C["Test (e.g. access labelled file with Copilot)"]
  C --> D["Review reports: What would be blocked?"]
  D --> E["Enforce policy in production"]

Figure: Typical DLP for Copilot rollout process with simulation

The policy depends entirely on label discipline

Many people assume this DLP location hides everything. It doesn't. It only blocks Copilot from reading item content and does nothing to stop filenames or metadata from appearing in search. It is also driven entirely by labels, so if your users don't label sensitive content consistently, DLP for Copilot won't help you. In my experience, many organisations only take labelling seriously once DLP blocks start to bite. To get real value from DLP for Copilot, pair it with a strong, automated labelling setup (see this post).

If you need to bulk-label files or adjust policies at scale, PowerShell can handle it (Microsoft Graph PowerShell SDK, Information Protection Admin role). Here's an example that assigns a label to a document:

# Prerequisite: Microsoft Graph PowerShell SDK, Information Protection Admin role
Connect-MgGraph -Scopes 'InformationProtectionPolicy.ReadWrite.All'
$labelId = '<label-id>'
Set-MgUserDriveItem -UserId <UserId> -DriveId <DriveId> -ItemId <ItemId> -SensitivityLabelId $labelId

I see DLP for Copilot as real progress that depends on good labels

DLP for Copilot is a big step forward for AI governance in Microsoft 365. For the first time, you can block Copilot from processing labelled content without awkward permission hacks or risky workarounds. The catch is that it's only as strong as your labelling discipline. In my projects, the best results come from combining automated labelling, clear label policies and DLP, which gives you usable AI and genuine information protection at the same time. If you want Copilot with compliance, start with your labels and then add DLP for Copilot to enforce them where it matters.