Microsoft 365 Copilot opens up exciting possibilities for productivity, but it also raises fresh questions about data security. Who has access to what, and how can we keep sensitive information from accidentally leaking through Copilot-powered assistance?
In this post, we’ll explore how you can use Data Loss Prevention (DLP) policies in Microsoft Purview to help control what Copilot can (and cannot) do with your sensitive, or outdated, content. This builds on my earlier post about advanced sensitivity labels, where we restricted Copilot access by stripping out EXTRACT permissions. Now, we’re adding to that approach with DLP to take things one step further. This DLP policy for Copilot is new to Purview, currently in preview and only applies to chat-based experiences, although what those are remains a surprise. And in the end I ended up combining both solutions for a surprising result.
First, we will make our policy in Microsoft Purview. Start by creating a new custom policy.
Give your DLP policy a suitable name.
Choose where to apply the policy. Select Microsoft 365 Copilot (preview).
The only option we have here to create our own advanced DLP rules.
Give it a name (I’ve given it Label). Click on Add Condition, select Sensitivity label and the sensitivity label you want this policy to work with.
You cannot run this policy in simulation mode, so be careful here. I’m going to test the results, so I will turn the policy on.
After publishing, you’ll see a summary of your new policy. Now we’re ready to see what happens in action.
So, how does it work? I have two documents, a spreadsheet with Sales over 2025 and a detailed Word document about the sales over 2025. Both have the High confidential\Finance label, where I scoped the DLP policy to.
Copilot cannot get the context from inside the files, so no hit here.
If I ask Copilot about these files in general terms, it responds, “This file is restricted.” So the policy is doing its job.
However, when I asked Copilot to generate a PowerPoint based on the file, it actually allowed me to do it. That’s because this doesn’t count as a “chat experience” in the DLP scope apparently.
In Microsoft Loop, things also get interesting. Copilot can still extract information from the file, even with the DLP policy in place.
This reminded me of our previous test with advanced sensitivity labels. There, we removed EXTRACT permissions in the No Copilot label to block Copilot from using content in new documents. So I asked myself what happens if we combine this with our DLP policy.
Here’s what changed when I updated the policy to include a label with no EXTRACT rights (“No Copilot”).
Copilot recognizes the files exist, but it can’t open them. Same as before with just the DLP policy.
But in Loop, Copilot can no longer read the content. The protection holds.
In PowerPoint and Word, Copilot is also blocked from accessing the file.
I have even created a SharePoint Agent in the folder where these protected files are located. The agent also cannot extract the contents of the file to form a response.
By itself, a DLP policy targeting Copilot can provide a useful layer of protection, but it’s not airtight. Certain experiences, like in Loop or PowerPoint file generation, might still bypass those controls depending on how the policy is configured.
But when you combine DLP with a sensitivity label that removes extract permissions, you start to see real control over what Copilot can and cannot access. It’s this layered approach, combining tools by using DLP policies and sensitivity labels, that gives you the strongest security posture.
Want to test this yourself? Start small in with a select group of users, apply different combinations, and see what works best for your organization’s needs. This would also be a good way to restrict archive libraries from showing up without taking them out of your enterprise search.
