In the previous articles we covered labeling fundamentals and architecture and deployment patterns. A well-run labeling programme gives you consistent classification across your tenant. Classification on its own doesn’t stop anything, though.
The pressure to turn labels into enforcement is now coming from AI. Copilot and agents reach across your content to ground their answers, so the question becomes: which labelled content are they allowed to use? This article covers how labels and DLP work together to answer it.
Labels are the signal, DLP is the control
In the architecture article I described labels as a control plane signal consumed by downstream services. DLP for Copilot is a good example. You build a policy using the Microsoft 365 Copilot and Copilot Chat location, with the Content contains > Sensitivity labels condition to exclude items from being processed. The label identifies the data, and the DLP rule decides what Copilot can do with it.
The scope has widened over the last year:
- Emails. DLP can detect sensitivity labels in emails as enterprise grounding data and restrict access of the labeled emails in Microsoft 365 Copilot chat experiences.
- Office files. DLP policies will block Microsoft 365 Copilot from processing sensitivity-labeled Word, Excel, and PowerPoint files across all storage locations, including local devices. At the time of writing this was still rolling out, so check the Message Center post (MC1234661) for your tenant.
- Alerts and simulation. With GA, admins can edit existing policies to enable alerts and policy simulation.
Portal navigation
Microsoft Purview portal → Data loss prevention → Policies → create a custom policy → select Microsoft 365 Copilot and Copilot Chat as the location → condition Content contains > Sensitivity labels → action to restrict Copilot processing.
You can also start from Data Security Posture Management for AI, which shows recommendations for creating Microsoft 365 Copilot policies.
Enforcement patterns for AI
These mirror the maturity model from the architecture article.
Pattern 1: Visibility first
- Use case: early-stage organisations that haven’t yet decided what Copilot can touch.
- Use DSPM for AI recommendations and the audit log to see what Copilot is interacting with.
- Run DLP policies in simulation, with no enforcement.
- This gives you a baseline, just as manual-first labeling does.
Pattern 2: Block the top tier
- Use case: most organisations in steady state.
- Restrict Copilot from processing your highest-sensitivity label only (for example, Highly Confidential).
- Leave Internal and Confidential available so Copilot stays useful.
- This is the usual balance: the crown jewels stay out, and adoption doesn’t stall.
Pattern 3: Allow-list by label
- Use case: regulated environments.
- Restrict Copilot to a specific sensitivity label and exclude everything else, using rules that prevent Copilot from processing content labelled with any other label.
- Be aware of the coverage gap: unlabelled content is a risk in this pattern, so it only works with strong default labeling and auto-labeling in place.
Where agents fit
Agents raise the stakes because they act on someone’s behalf. This is where Agent 365 comes in: it extends Microsoft Purview capabilities to help organisations understand and manage how agents interact with your data, including information protection, DLP, compliance, retention and risk controls. Your label taxonomy is what those controls act on, so the work you do on labels now carries straight over to agents.
Things to validate before you enforce
- Label coverage. DLP can only restrict what is labelled. Check your unlabelled content percentage first.
- Usage rights. Encrypted labels bring usage rights into play. Confirm how Copilot behaves with your encryption settings, and test with a pilot group rather than trusting the documentation alone.
- Supported surfaces. Not every Copilot experience and file location behaves the same way. Maintain a matrix, as you would for client support in labeling.
- User experience. Decide what users should see when Copilot declines to use a file, and brief the service desk.
Common failure modes
- Blocking too many labels and driving users to unmanaged AI tools
- Enforcing before auditing what Copilot is actually touching
- Assuming labelled means safe, when unlabelled content is the real gap
- Treating Copilot DLP as separate from your labeling governance, so label changes silently break policies
Conclusion
Labeling is only half the story. Its value shows when DLP, Copilot and agent governance consume the labels you’ve built. If you’ve invested in taxonomy and staged deployment, adding AI enforcement is largely a policy exercise. If you haven’t, AI adoption is a good reason to start.
