Microsoft Purview DLP for Copilot: What IT Admins Must Configure Before Rollout

Microsoft Purview DLP for Copilot is a set of policies that block Microsoft 365 Copilot and Copilot Chat from using, returning, or grounding answers on documents and prompts that contain sensitive data types an admin defines, such as Social Security numbers, card numbers, or a custom label like "Board Only." The core version finished rolling out to every tenant by late April 2026, and an extension covering external web search grounding completed in late June. None of it protects anything on its own: Copilot ships with zero DLP policies turned on by default, so the feature only works once someone in IT builds the rules.

That gap between "available" and "active" is the actual story here, not the feature announcement.

Every Microsoft 365 tenant I have reviewed in the past two months has Copilot licensed and in daily use. Almost none of them had a corresponding Purview DLP policy live for it. Copilot had been answering questions against whatever content it could see for months, with no rule in place to say a given document was too sensitive to summarize.

What Does DLP for Copilot Actually Block?

The feature works by scanning the content Copilot would otherwise use to answer a prompt, meaning both the document it might reference and the answer it is about to generate, against a list of sensitive information types (SITs) you configure in the Purview compliance portal. If a match hits, Copilot either declines to use that content for grounding or blocks the response outright, and the user sees a policy notice instead of an answer built on a file they should not have been able to summarize.

• Prompt and response DLP: blocks Copilot, including prebuilt agents, from using sensitive content in a prompt or returning it in a response. Rolled out tenant-wide between late March and late April 2026.
• External web search DLP: stops Copilot and Copilot Chat from grounding an answer on a live web search when the prompt itself contains a protected data type. Completed GA rollout in late June 2026.
• External email DLP: will block Copilot and Copilot Chat from processing emails sent from outside the organization. Currently in preview, with general availability planned for January 2027.

Why Does Copilot Ship With No DLP Policies Turned On?

Microsoft built the enforcement engine and left the policy decisions to you, which is a defensible design choice but not one most rollout teams expect. Every default sensitive information type Purview ships (credit card numbers, US Social Security numbers, passport numbers, and a few dozen others) has to be explicitly attached to a DLP policy and scoped to the Copilot workload before it does anything. Custom labels, like an M&A folder or an unreleased product name, need their own rule written from scratch.

That default protects no one until an admin turns it on.

How Do You Configure DLP Policies for Microsoft 365 Copilot?

• Open the Microsoft Purview compliance portal and confirm the Copilot workload is even listed as a policy location. If your tenant has not been touched since the licensing rollout, it usually is not.
• Start with the sensitive information types you already enforce in Exchange or SharePoint DLP rather than building a new list. Reusing an existing SIT set means the policy matches behavior your users have already seen elsewhere.
• Set the initial policy to test mode with user notifications off before you enforce anything. Copilot usage patterns are noisy in the first two weeks and a hard block on day one generates more helpdesk tickets than it prevents.
• Add your highest-risk custom label first, whatever the one document type is that would trigger an incident report if Copilot summarized it for the wrong person, and confirm the block works before adding the rest.
• Review the DLP alert dashboard weekly for the first month, then fold it into the same access review cadence your SSO and MFA policies already go through.

Where This Fits Your Broader AI Governance Program

This is the same pattern we flagged when Microsoft turned on federated connectors by default for every tenant: the vendor ships the capability, and the admin has to go build the guardrail after the fact. DLP for Copilot is the more consequential version of that pattern, because the gap here is not a third-party connector nobody approved. It is Copilot already answering questions against your own sensitive documents with no policy in place at all.

Treat Copilot DLP as part of the same access control program as everything else, not a standalone Purview project. We built a similar tiered rollout into the SSO and MFA reset security model we deploy with clients, starting with the highest-risk rule and expanding only once the false positive rate is low enough that users stop routing around it.