Official documentation checked October 14, 2026.
If Copilot still answers after you configure a Microsoft Purview DLP policy, the answer alone does not establish that the policy failed. A rule that blocks external web search can still allow an answer from internal sources. A rule excluding a labeled document can still leave its citation visible. Start with the operation you intended to prevent, then check the rule and a controlled test.
Do not submit real customer identifiers to prove a failure or weaken an existing policy while troubleshooting. This guide concerns organizational Microsoft Copilot experiences, not a personal Microsoft-account session.
Identify What the Rule Was Supposed to Block
Check the condition and action against Microsoft’s current Copilot-specific DLP guidance:
- Sensitive information in a typed prompt: Performing Web Searches prevents external search for the matching request; it is not a no-response rule. Processing prompts prevents the response and search processing. The latter is a preview feature whose rollout must have reached your tenant.
- A sensitivity-labeled source: the processing restriction excludes that file or email’s content, not necessarily its citation. The label must actually be on the item; a similarly named site or group label is not sufficient.
- A directly uploaded attachment: a typed-prompt sensitive-information rule does not scan that attachment’s contents. Use the separately supported controls appropriate to the upload path; do not report the text rule as universal attachment protection.
Write an expected outcome before testing. For example, “a matched typed prompt receives no answer” is different from “this request does not use web search.” A general answer containing a number is not evidence that a particular protected source was read.
Check Scope, Detection, and Enforcement in Order
- Confirm the session. Record the user’s organizational tenant, account, Copilot entry point and client. Reproduce using the same permitted environment, not a personal account or a different organization’s session.
- Inspect the actual policy. In the Microsoft Purview portal, open Data Loss Prevention > Policies. Record its name, selected location, included users and exclusions. The Copilot location is available through a Custom policy; selecting it disables the other locations in that policy. Do not try to add Exchange, SharePoint and OneDrive to the same Copilot policy.
- Inspect the rule, not only the policy name. Match the configured condition, exception and action to the failed task. Use separate rules for sensitivity labels and sensitive information types; they cannot be combined in one rule. A generic block action copied from a different workload is not a substitute for the supported Copilot action.
- Validate the detector independently. Review the selected sensitive information type’s definition and use an approved synthetic example. Many detectors need supporting evidence, a checksum or a particular pattern. An arbitrary 16-digit number is not a reliable credit-card test. Microsoft’s sensitive information type guidance explains confidence and supporting evidence. Setting a count of one and high confidence does not guarantee every sample matches; lowering confidence can increase false positives.
- Confirm deployment mode. Follow the DLP deployment workflow. Simulation helps evaluate a rule but is not enforcement, even when notifications appear. An authorized administrator must approve enabling a tested policy for the intended scope. Do not enable an unreviewed tenant-wide rule simply to diagnose one user.
Retest and Collect Evidence Without Exposing Sensitive Data
Prepare a small test record: policy and rule names, test user, client, timestamp, selected condition/action, synthetic input and expected result. Include a harmless nonmatching control. For a source-label rule, put a unique fictional statement in an approved test document so you can distinguish use of its content from a generic answer or citation.
The current Copilot DLP guidance allows up to four hours for policy changes to appear. For label-based restrictions in Word, Excel and PowerPoint, policy evaluation occurs when the file opens: save your work and reopen the test file after a mid-session label change. Do not repeatedly edit the rule during that waiting period.
Compare the observed action with the configured action and available Purview evidence. A rule match proves detection, not automatically that a blocking action was enforced; missing or unclear user messaging does not prove an absence of enforcement. Copilot audit records can help correlate the interaction, resources and available policy details. Access to policy administration does not automatically authorize reading full prompt content.
If a confirmed match still produces the prohibited behavior after propagation and a fresh test, give your security team or Microsoft support the reproduction and relevant record identifiers through an approved channel. Keep the existing protections in place. Do not remove labels, export confidential files or disable unrelated DLP rules to make the test easier.