You configured a Data Loss Prevention policy in the Microsoft 365 Purview compliance portal, but Copilot still returns content that contains credit card numbers, social security numbers, or other sensitive information. This problem usually occurs because the DLP policy does not include the Copilot workload or because the policy uses a detection rule that Copilot cannot evaluate in real time. This article explains why the DLP policy does not block sensitive content in Copilot interactions and provides the exact steps to verify, update, and test the policy so that Copilot respects your data protection rules.
Key Takeaways: Fixing Copilot DLP Policy Gaps
- Microsoft Purview compliance portal > Data Loss Prevention > Policies > Edit policy > Locations > Copilot: The Copilot workload must be explicitly selected as a location for the DLP policy to apply to Copilot responses.
- Microsoft Purview compliance portal > Data Loss Prevention > Policies > Edit policy > Rules > Condition > Content contains sensitive info type: Use a high-confidence rule with the correct sensitive info type and a minimum count of 1 to ensure detection.
- Microsoft Purview compliance portal > Data Loss Prevention > Policies > Edit policy > Rules > Action > Block access or restrict: Set the action to “Block” and enable the end-user notification to inform users when content is blocked.
Why Copilot Ignores Your DLP Policy
Microsoft 365 Copilot is a workload that processes data from Microsoft Graph, SharePoint, OneDrive, and Exchange Online. A DLP policy that applies to Exchange, SharePoint, and OneDrive does not automatically apply to Copilot. The policy must include the Copilot location in the policy scope. Even if the location is included, the policy rule must use a sensitive info type that Copilot can detect during the response generation. Copilot evaluates DLP rules when it returns content to the user, not when the user enters a prompt. If the rule uses a custom sensitive info type that is not indexed or uses a minimum count that is too high, Copilot will not detect the violation and will show the sensitive content.
Policy Location Not Selected
The most common cause is that the DLP policy was created before Copilot was added as a workload in Purview. Older policies target Exchange, SharePoint, OneDrive, and Teams but do not include Copilot. You must edit the policy and add the Copilot location.
Incorrect Sensitive Info Type or Threshold
Copilot uses the same sensitive info types that are available in Purview. If the rule uses a custom type without a published confidence level or sets a minimum count of 5 or higher, Copilot may not classify the content as sensitive. Use a built-in type with confidence level high and minimum count 1.
Action Set to Audit Instead of Block
A DLP policy in audit mode logs violations but does not block content. If the policy action is set to “Audit only” or “Notify user” without blocking, Copilot will return the sensitive content and only log the event. Change the action to “Block” to prevent Copilot from displaying the content.
Steps to Fix the Copilot DLP Policy
Follow these steps to verify and correct the DLP policy for Copilot. You need the Information Protection Administrator role or a role with DLP management permissions in the Microsoft 365 Purview compliance portal.
- Open the Microsoft Purview compliance portal
Go to https://compliance.microsoft.com and sign in with your admin account. In the left navigation, select Data Loss Prevention and then Policies. - Select the policy that should block sensitive content in Copilot
Find the policy name from the list. If you do not have a policy that targets Copilot, create a new policy by clicking Create policy and choose Custom. For this fix, edit the existing policy by clicking the policy name. - Verify the policy locations include Copilot
In the policy editor, go to Locations. Ensure the Copilot workload is toggled to On. If it is off, toggle it on. Also verify that Exchange, SharePoint, and OneDrive are on, as Copilot may reference data from those sources. Click Next. - Check the rule conditions and sensitive info type
Go to Rules. Click the rule name to edit it. Under Conditions, look for Content contains sensitive info type. Click Add if it is missing. Select a built-in sensitive info type such as U.S. Social Security Number or Credit Card Number. Set the Minimum count to 1 and the Confidence level to High. Click Save. - Set the action to block
Still in the rule editor, scroll to Actions. Select Block access or restrict. Under Block access, choose Block access to the content. Enable Notify users and customize the notification text so users understand why the content is blocked. Click Save and then Next. - Review and save the policy
Review the policy summary. Confirm that the policy mode is set to Turn on policy immediately or Test mode with notifications. If you use test mode, ensure the action is set to block. Click Submit. - Test the policy with Copilot
Open Copilot in Microsoft 365 and type a prompt that includes a known sensitive data pattern, for example, a 16-digit credit card number. Copilot should block the response and display the notification message you configured. If it does not block, wait up to 24 hours for policy replication and test again.
If Copilot Still Shows Sensitive Content After the Fix
If the DLP policy is correctly configured but Copilot still returns sensitive content, check these additional factors.
Copilot Uses a Different Tenant or Data Source
If the user accesses Copilot from a personal Microsoft account or a different tenant, the DLP policy from your organization does not apply. Ensure the user is signed in with their work or school account and that the Copilot workload is enabled in the same tenant where the policy is deployed.
The Sensitive Info Type Is Not Supported for Copilot
Microsoft publishes a list of sensitive info types that Copilot can evaluate. Custom sensitive info types that use regex patterns without a keyword list may not work. Use a built-in type or add a keyword list to the custom type. Check the Microsoft documentation for the list of supported types.
Policy Replication Delay
DLP policy changes can take up to 24 hours to replicate across all Microsoft 365 services. If you tested immediately after saving, wait and test again after 24 hours. You can check the policy status in the Purview portal under Data Loss Prevention > Policies. The status should show Active.
End-User Notification Is Not Shown
If the action is set to block, the content is blocked even if the notification does not appear. Check the audit log in Purview under Audit > Search for DLP rule matches. If the audit log shows a match, the policy is working but the notification may be suppressed by the user’s browser or client settings.
| Item | DLP Policy Without Copilot Location | DLP Policy With Copilot Location |
|---|---|---|
| Scope | Exchange, SharePoint, OneDrive, Teams | Exchange, SharePoint, OneDrive, Teams, Copilot |
| Effect on Copilot | No enforcement; sensitive content is returned | Content is blocked when sensitive data is detected |
| Detection timing | Evaluated only on stored data | Evaluated on Copilot response before display |
| User notification | Not applicable | Shows a block message with policy tip |
| Audit logging | Logs violations from Exchange, SharePoint, OneDrive | Logs violations from all workloads including Copilot |
You can now verify that your DLP policy includes the Copilot workload, uses a high-confidence sensitive info type with a minimum count of 1, and sets the action to block. After saving the policy, test with a known sensitive pattern and wait up to 24 hours for replication. For advanced protection, configure multiple rules for different sensitive info types and enable the end-user notification with a custom message that directs users to your data protection guidelines.