An employee asks Copilot to summarize “all documents related to the pending acquisition.” Copilot responds with excerpts from contracts, financial terms, and customer data pulled from fifteen different files in SharePoint. No document was shared. No email was sent. But the confidential information is already visible, copyable, and ready to leave the secure environment. That is the real risk of deploying Copilot without DLP in Copilot properly configured.
This article explains what types of data are safe to handle with Copilot, which ones you must actively protect, what licenses you need for each protection layer, and how to configure data loss prevention policies in Microsoft Purview step by step so that AI works in your favor without becoming a data leakage vector.
Why Traditional DLP Is Not Enough for Copilot
Classic DLP policies monitor three actions: sharing documents externally, sending emails with sensitive content, and downloading files to unauthorized devices. Copilot breaks that model entirely.
Traditional DLP scans content at rest in SharePoint and OneDrive, intercepts outbound emails with sensitive content, and blocks unauthorized transfers to USB or cloud storage. But Copilot does not share, download, or send: it synthesizes. A Copilot response can contain fragments of sensitive data from multiple sources, none of which would have triggered traditional DLP because no document was shared or downloaded.
The Copilot response can contain aggregated confidential information that the user can copy, paste, screenshot, or discuss in a Teams meeting with external participants. Traditional DLP never sees that interaction unless you have configured specific policies for DLP in Copilot through Microsoft Purview.
This is the starting point that every CTO or security manager must internalize before activating Copilot in production: the data exposure surface changes radically with generative AI, and existing privacy policies do not cover that new perimeter.
What Licenses You Need for Each DLP in Copilot Layer
Before designing any policy, you need to know what you have contracted. Access to DLP in Copilot capabilities depends directly on your licensing level. This is the reference table we recommend reviewing with your partner before approving the project:
| Protection Layer | Minimum Required License | Notes |
|---|---|---|
| Restriction by sensitivity label (files and emails) | Microsoft 365 E3 + Microsoft 365 Copilot license | Requires sensitivity labels published in Purview |
| Prompt blocking with SITs (sensitive information types) | Microsoft 365 E5 or E3 + Purview add-on + Copilot license | Included for all M365 Copilot users since Ignite 2025 |
| Blocking external web searches with sensitive data | Microsoft 365 E5 or E3 + Purview add-on + Copilot license | Same DLP policy, different action |
| SharePoint Advanced Management (oversharing) | Included in the Microsoft 365 Copilot license | Does not require E5 separately |
| Audit, eDiscovery, and prompt retention | Microsoft 365 E5 or Purview add-on | Mandatory for LGPD, Habeas Data compliance and regulated audits |
If your organization operates with E3 licenses without the Purview add-on, the prompt blocking layer will not be available. This is the most frequent licensing gap we find in initial tenant audits in LATAM. Validating it before designing the security architecture saves you weeks of rework.
Copilot can only summarize or reference content that the user is authorized to access. That is a baseline guarantee, but it is not sufficient for environments with confidential information.
Data You Can Handle with Copilot Without Additional Restrictions
- Internal working documents without a confidentiality label (drafts, general presentations, team wikis).
- Everyday emails and calendars without regulated data.
- Ongoing project information accessible to the entire team involved.
- Aggregated and anonymized data for productivity analysis.
Data That Requires Active DLP in Copilot Policies
- Regulated financial information: account numbers, agreement terms, audit data, material non-public information (MNPI).
- Health data: clinical records, health insurance numbers, any data covered by HIPAA or local LATAM regulations.
- Intellectual property: source code, formulas, trade secrets, unpublished product plans.
- Personally identifiable information (PII): passport numbers, national ID numbers, credit cards, physical addresses.
- M&A information: due diligence documents, valuations, non-disclosure agreements.
How DLP in Copilot Works: The Three Protection Layers
Microsoft Purview protects interactions with Copilot at three distinct levels. You need policies at each layer to have real coverage.
Layer 1: File and Email Restriction by Sensitivity Label
In November 2024, Microsoft introduced the ability to create a DLP policy to restrict Microsoft 365 Copilot and Copilot Chat from processing sensitive files and emails using sensitivity labels. When a file open in Word, Excel, or PowerPoint has a label for which a DLP policy has been configured to prevent processing by Copilot, the AI features in those applications are disabled. The file may still appear in metadata search results, but its content is not read or summarized.
Layer 2: Prompt Blocking with Sensitive Information Types (SIT)
This functionality evaluates the text entered by the user in real time, before processing occurs. With DLP in Copilot for prompts, the input text is scanned for built-in SITs—such as social security numbers or credit cards—or custom SITs defined by your organization. If a SIT is detected, Copilot restricts the processing of the prompt: no AI response is generated and users receive a clear notification that their request cannot be completed due to company policies.
Layer 3: Blocking External Web Searches with Sensitive Data
Microsoft Purview DLP can prevent Copilot from sending sensitive information to external web services. When a prompt contains SITs—such as credit card numbers, passports, or custom SITs—Copilot automatically blocks the use of external web search as a grounding source for that prompt. Instead, it continues generating responses using only the permitted Microsoft 365 internal data sources.
DLP in Copilot and the Zero Trust Framework: How They Complement Each Other
DLP in Copilot policies are most effective when they are part of a Zero Trust architecture. The Zero Trust principle—never trust, always verify—also applies to AI models: no user or system, including AI, should have implicit access to sensitive data simply by being inside the corporate perimeter.
In practice, this means combining three complementary control layers:
- Conditional Access: defines the conditions under which a user can access Microsoft 365 Copilot: managed device, geographic location, sign-in risk level. If the user does not meet the conditions, Copilot is simply not available for that session, regardless of DLP policies.
- Privileged Identity Management (PIM): limits the exposure time of administrative roles that can modify Copilot DLP policies. An administrator with permanent access to those policies represents a greater risk than one with just-in-time access.
- DLP in Copilot policies: act as the last line of defense within the authorized session, blocking the processing of sensitive content even if the user has legitimate access to the system.
In LATAM environments operating under LGPD or Habeas Data, the combination of Conditional Access and DLP in Copilot is already an implicit requirement in many data security audits. Documenting both layers in the governance plan significantly accelerates certification processes.
Real Cases: Oversharing and DLP in Copilot in LATAM
Field data is more eloquent than any architecture diagram. In Copilot deployment projects we accompany from KCP Dynamics, these are the most frequent patterns:
Case 1 — Financial sector, Colombia: in the initial tenant audit of a mid-sized bank, 38% of M&A due diligence documents had no sensitivity label applied. Copilot could summarize them without restriction for any user with access to the SharePoint library. Remediation required three weeks of labeling assisted by Purview auto-classification and the activation of DLP in Copilot with label-based blocking. Result: zero unauthorized access incidents to M&A information in the following six months.
Case 2 — Healthcare sector, Mexico: a private hospital activated Copilot without reviewing SharePoint permissions. In the first week, three administrative users were able to obtain summaries of patient clinical records through natural language prompts, without directly accessing the records. Traditional DLP detected no incident because there was no file download or sending. Activating DLP in Copilot with custom SITs for local health data cut off access in less than four hours after configuration.
These two cases illustrate why oversharing and the absence of DLP in Copilot are risks that materialize in days, not months, once AI is active in production.
Step-by-Step Guide: Configuring DLP in Copilot with Microsoft Purview
Before creating the first policy, you need to complete a critical prerequisite: inventorying and labeling your sensitive content. The model is label-first: without labels applied, sensitivity-based policies have nothing to act on.
Step 1: Audit and Label Content
- Inventory sensitive information and map it to sensitivity labels (e.g., Confidential, Highly Confidential). Record the percentage of high-risk documents already labeled.
- Create or refine sensitivity labels and, where possible, configure auto-labeling rules for Office files and PDFs. Auto-labeling currently only applies to Office files and PDFs.
Step 2: Create the DLP Policy for Copilot in Microsoft Purview
- Sign in to the Microsoft Purview portal. Go to Data Loss Prevention > Policies and select + Create policy. Choose the Custom > Custom policy template. On the Locations page, enable the Microsoft 365 Copilot and Copilot Chat location.
- Add a rule with the condition Content contains > Sensitive information types and choose the SITs you want to detect.
- Set the action: Prevent Copilot from processing content > Prompt processing (full block) or Perform web searches (only to block external grounding).
- Save and activate the policy.
Step 3: Know the Key Technical Limitations
- SITs created through document fingerprinting cannot be used in these policies. Only standard pattern-based SITs and trainable SITs are supported.
- Policy changes take up to four hours to propagate. In environments with more than 5,000 users, plan maintenance windows that respect that latency.
- Files uploaded directly in a prompt are not scanned: DLP only evaluates the text written in the prompt.
- You cannot use the conditions “content contains sensitive information types” and “content contains sensitivity labels” in the same rule. Create a separate rule for each condition within the same policy.
Roles Required to Manage DLP in Copilot
Not just any administrator can create or edit these policies. Accounts with the following roles can create or edit a DLP policy in Copilot for the Microsoft 365 Copilot and Copilot Chat location: Microsoft Entra AI Admin (manages all aspects of Microsoft 365 Copilot and enterprise AI services) and Purview Data Security AI Admin (edits DLP policies related to Copilot and views AI content in Data Security Posture Management).
Assign these roles carefully. The principle of least privilege applies here just as in any other critical system. An administrator with excessive access to Copilot DLP policies can disable protections without leaving a visible trace in standard operational logs.
Continuous Monitoring and Auditing
Configuring policies is the first step. Keeping them effective requires continuous monitoring. Purview audit logs include Copilot prompts, responses, and referenced content, as well as interaction data for eDiscovery and compliance investigations.
Use Microsoft Purview DSPM data risk assessments to continuously validate that sensitive data remains protected from Copilot access. Review Microsoft Purview Insider Risk Management and DLP alerts to detect and investigate risky AI use or potential data leakage.
For LATAM environments with regulations such as LGPD (Brazil) or Habeas Data (Colombia), the traceability of personal data access by AI systems is already a de facto requirement in many audits. Purview logs cover that need if you configure them correctly from the start.
Oversharing: The Silent Risk That DLP Alone Does Not Cover
DLP in Copilot policies protect against active data leakage, but there is another risk that operates more silently: oversharing. Copilot can access any file the user has permission to access. If permissions in SharePoint are misconfigured—which occurs in most tenants without an active review—Copilot can synthesize information that the user technically can see but should not see in that context.
To address oversharing in a Microsoft 365 Copilot deployment, Microsoft published the Oversharing Blueprint, which uses Microsoft Purview and SharePoint Advanced Management, included in the Microsoft 365 Copilot license. The enhanced data risk assessment capability enables bulk remediation: administrators can remediate or disable overshared links at scale, proactively reducing data exposure before Copilot amplifies it.
In real projects we accompany from KCP Dynamics, oversharing is the number one problem that appears in the first weeks of Copilot use in production. The solution is not to deactivate Copilot: it is to clean up permissions before activating it.
What to Do When DLP Detects a Real Leak
Prevention is the goal, but you need a response plan for when alerts are triggered. A detected incident without a defined response flow is almost as dangerous as an undetected one. This is the minimum protocol we recommend:
- Alert and triage (first 30 minutes): Purview Activity Explorer generates the alert. The Purview Data Security AI Admin validates whether the event is a false positive or a real incident. If real, escalate to the CISO or data security officer.
- Containment (first 2 hours): if the prompt contained regulated data that reached a visible response, identify the user, review the interaction history in audit logs, and if necessary, temporarily suspend that user’s access to Copilot via Conditional Access.
- Investigation and documentation (first 24 hours): use Purview eDiscovery to retrieve the prompt, the response, and the referenced files. Document the incident according to applicable regulatory requirements (LGPD requires notification to the ANPD within a maximum of 72 hours in the event of a personal data breach).
- Policy remediation: if the incident revealed a gap in DLP in Copilot policies, adjust the SITs or labels involved and re-run simulation mode for 48 hours before reactivating the block.
Governance Checklist Before Activating Copilot in Production
If you are preparing the deployment or reviewing the current state of your tenant, this is the minimum sequence we recommend from KCP Dynamics:
| Step | Tool | Responsible | Success Criterion |
|---|---|---|---|
| 1. Sensitive data inventory | Purview Content Explorer | Compliance Admin | >80% of high-risk documents identified |
| 2. Sensitivity labeling | Microsoft Purview + auto-labeling | Compliance Admin | Labels published and auto-labeling active |
| 3. DLP policy for files and emails | Microsoft Purview DLP | Purview Data Security AI Admin | Policy active in Copilot location |
| 4. DLP policy for prompts (SITs) | Microsoft Purview DLP | Purview Data Security AI Admin | SITs configured and rule active |
| 5. Simulation mode (2 weeks) | Activity Explorer | Compliance Admin | False positive rate <5% |
| 6. SharePoint permissions review | SharePoint Advanced Management | SharePoint Admin | Sites with excessive access remediated |
| 7. Conditional Access for Copilot | Microsoft Entra ID | Entra AI Admin | Policy active: managed devices only |
| 8. Incident response plan | Purview + eDiscovery | CISO / Compliance Admin | Runbook documented and tested |
Frequently Asked Questions About DLP in Copilot
Does Copilot use my data to train Microsoft’s AI models?
Prompts, responses, and data accessed through Microsoft Graph are not used to train the foundational language models, including those used by Microsoft 365 Copilot. Your organizational data remains within your tenant environment.
What happens when a user tries to use a prompt with sensitive data blocked by DLP?
When a user attempts to send a prompt that contains any of the configured sensitive information types, they receive a message indicating that the request cannot be completed because it contains sensitive information that the organization has blocked for Microsoft 365 Copilot. No AI response is generated.
Do Copilot DLP policies also apply to agents created in Copilot Studio?
This capability extends to Microsoft 365 Copilot and to agents created in Copilot Studio that are published in Microsoft 365 Copilot. Custom agents inherit the same DLP protections configured for DLP in Copilot.
Can I restrict Copilot from using external emails as a data source?
You can prevent Microsoft 365 Copilot and Copilot Chat from using emails sent from external domains as grounding data for responses. When this control is enabled, Copilot excludes external emails received by users from being referenced or summarized during prompt processing. This protection helps organizations reduce the risk of prompt injection and influence from untrusted data.
How long does it take for changes to Copilot DLP policies to take effect?
Policy changes take up to four hours to propagate. Plan maintenance windows and validation tests taking that latency time into account.
Do I need an E5 license to activate DLP in Copilot?
It depends on the layer. Sensitivity label restriction is available from Microsoft 365 E3 with a Copilot license. Prompt blocking with SITs requires E5 or the Purview add-on. SharePoint Advanced Management is included in the Copilot license at no additional cost.