Copilot DLP and sensitivity labels: recipes that block

There is no shortage of writing about sensitivity labels and Copilot, including Frontrow's own labels playbook at /insights/purview-sensitivity-labels-playbook and the container-versus-file-labels field report at /insights/container-vs-file-labels-australian-tenants. This piece assumes that groundwork is done and answers a narrower question that comes up in almost every Copilot governance engagement: which policy configurations actually block Copilot from touching content, and how do you prove they are working? The distinction matters because much of the labels stack is advisory or access-driven, and 2026 gave Australian tenants two reasons to care about hard enforcement: Microsoft completed the rollouts that make real blocking possible, and a January incident demonstrated what happens when enforcement silently fails.

Two enforcement layers, and what each one blocks

The first layer is the label itself. When a sensitivity label applies encryption, Copilot honours the usage rights: a user needs both VIEW and EXTRACT rights on an item for Copilot to return its content in a response. No EXTRACT, no summarisation, regardless of what the user can open and read. Separately, Microsoft extended the label setting that prevents connected experiences from analysing content, so that files carrying a label configured this way are blocked from Copilot file analysis in Word, Excel and PowerPoint. That extension finished rolling out to tenants around July 2026, which means labels that previously only limited a narrow set of connected experiences now carry real weight against Copilot in the Office apps.

The second layer is Microsoft Purview data loss prevention, which gained a dedicated policy location for Copilot: the Microsoft 365 Copilot and Copilot Chat location. Policies in this location act on Copilot's behaviour directly, excluding labelled files and emails from response generation, refusing prompts that contain sensitive information types, and cutting off external web search as a grounding source. Label enforcement travels with the content; the DLP location governs the Copilot interaction itself. A defensible posture uses both, and if you are weighing Purview DLP against standalone tools more broadly, that decision has its own guide at /insights/microsoft-purview-vs-third-party-dlp-australia-2026.

Recipe 1: block labelled files and emails from Copilot processing

This is the recipe most organisations actually want: items carrying your most sensitive labels never feed a Copilot response, even for users entitled to open them. In the Microsoft Purview portal:

1. 1Create a new DLP policy from the Custom template (the Copilot location is only available there), and on the locations page switch on Microsoft 365 Copilot and Copilot Chat. Every other location in the policy is disabled at that point by design.
2. 2Add a rule with the condition Content contains, then Sensitivity labels, and select the labels to protect, typically your Highly Confidential tier and any legal or board labels.
3. 3Set the action to Prevent Copilot from processing content.
4. 4Run the policy in simulation mode first to see what it would match, then turn it on.

Three behaviours to know before the change ticket is written. Labelled items can still appear in citations, but their content is not used in the response, so a user may see that a document exists without Copilot revealing what it says. Email coverage applies to messages sent on or after 1 January 2025, and calendar invites are not covered at all. And in Word, Excel and PowerPoint, the policy is evaluated when the file is opened: label a file mid-session and enforcement begins the next time it is opened, which matters when you test.

Recipes 2 to 4: prompts, web search, and external email

Three more rules belong in the same policy conversation, all using the same Copilot location. Note one constraint: a sensitivity-label condition and a sensitive-information-type condition cannot share a single rule, so build them as separate rules within the policy.

• Block sensitive prompts (recipe 2): condition Content contains, then Sensitive information types, covering the SITs that matter to you (financial account numbers, TFNs, credentials, or custom SITs), with the action Prevent Copilot from processing content, Processing prompts. Copilot refuses to respond when a prompt contains the configured SITs. This control is rolling out in preview, and during preview the block message inside Word, Excel and PowerPoint can be vague even though the block itself works.
• Block web-search grounding on sensitive prompts (recipe 3): the same SIT condition with the action Prevent Copilot from processing content, Performing Web Searches. Prompts containing the SITs are never sent to external web search as a grounding source; Copilot answers from permitted internal sources only.
• Exclude external email from grounding (recipe 4, preview): condition Email is received from, External users, action Prevent Copilot from processing content. Copilot stops using externally received email for grounding, summarisation and citation, which reduces the surface for prompt-injection content arriving by email. Only sender metadata is evaluated, and users keep normal access to the email itself.

How to test that it actually blocks

A policy that has been created is not a policy that works. Purview itself tells you what would match (simulation mode, activity explorer); only a live prompt tells you what Copilot actually does. Allow up to four hours after any policy change before testing, because that is how long updates can take to reach the Copilot experience, then run a verification pass like this:

1. 1Seed test content: a document and an email carrying each blocked label, with distinctive marker text you can search for (a phrase like 'PROJECT COBALT FIGURES' works well), stored where the test user has full access.
2. 2In Copilot Chat, ask directly: 'Summarise [document name]' and 'What does the document containing PROJECT COBALT FIGURES say?'. Pass: Copilot declines or answers without the content, even if the item shows in citations. Fail: any marker text appears in the response.
3. 3Repeat against email: 'Summarise my recent emails about Project Cobalt', including a labelled message in Sent Items, not just the inbox. The January incident, covered below, is the reason Sent Items and Drafts belong in the test set.
4. 4Test the prompt block with a dummy SIT value: paste a test credit card number such as 4111 1111 1111 1111 into a prompt and confirm Copilot refuses to process it, and that the event lands in DLP alerts.
5. 5Open a labelled file in Word and invoke Copilot in the document. Confirm the Copilot skills are unavailable for that file. If you applied the label seconds earlier, close and reopen the file first, since evaluation happens at file open.
6. 6Check the audit trail: confirm the interactions appear in activity explorer under AI activities, because the audit record is your evidence that enforcement was in place on a given date.

Keep the seeded content and re-run the prompt set after label taxonomy changes, after tenant-level Copilot changes, and on a periodic schedule. It takes minutes and it is the only end-to-end proof available.

What the January 2026 incident taught

From 21 January 2026, a code defect caused Copilot Chat's work mode to summarise emails sitting in users' Sent Items and Drafts folders even when those messages carried sensitivity labels and were covered by DLP policies that should have excluded them. The bug ran for roughly four weeks before Microsoft completed remediation in mid-February; public reporting followed on 18 February. Microsoft noted that users only ever saw content they were already authorised to access, which is true and also not the point: organisations had configured explicit controls stating that labelled content must not feed Copilot responses, and for a month, in two folders, it silently did.

Three durable lessons. First, enforcement can regress without any change on your side, which is why the verification prompts above are worth running on a schedule rather than once at go-live: a monthly five-minute read-back test would have caught this in week one instead of week four. Second, layers matter: encryption-backed labels enforcing EXTRACT rights, the DLP location policy, and audit logging fail independently, and an incident that slips one layer is still visible to another. Third, the audit trail is what turns an incident into an answerable question. Organisations with AI interaction auditing in place could establish which labelled items were actually summarised and by whom; those without it could only guess. None of this is a reason to avoid Copilot. It is a reason to run it with controls you test, on a platform where, it should be said, the vendor detected the defect, fixed it, and disclosed it.