Control 1.5: Data Loss Prevention (DLP) and Sensitivity Labels
Control ID: 1.5
Pillar: Security
Regulatory Reference: FINRA 3110, FINRA 4511, FINRA Notice 25-07 (RFC, contextual), SEC Reg S-P (17 CFR 248, 2024 amendments), SEC Rule 17a-4, GLBA 501(b) Safeguards Rule, SOX 302/404, NYDFS 23 NYCRR 500.11/500.15/500.16, OCC 2011-12, FFIEC; PCI DSS 4.0 (where card data flows); state breach-notification laws (NY GBL 899-aa, MA 201 CMR 17, CCPA/CPRA)
Last UI Verified: April 2026
Governance Levels: Baseline / Recommended / Regulated
Two distinct DLP control planes
This control covers two separate Microsoft DLP surfaces — do not conflate them:
- Microsoft Purview DLP for Microsoft 365 Copilot and Copilot Chat — configured in
purview.microsoft.comunder Data Loss Prevention. Governs prompts and labeled grounding files for first-party Copilot. - Power Platform data policies — configured in
admin.powerplatform.microsoft.comunder Policies > Data policies. Governs Copilot Studio agents (custom agents), connector classification, and channel publishing.
Microsoft Learn documents these as different products with different cmdlets (Get-DlpCompliancePolicy vs. Get-DlpPolicy), different portals, and different licensing floors. A change to one does not apply to the other.
Objective
Prevent sensitive financial data from unauthorized exposure through AI agents by implementing DLP policies that detect and block sensitive information in agent knowledge sources, user prompts, and agent responses. Combined with sensitivity labels, this provides comprehensive data protection for Microsoft 365 Copilot and Copilot Studio agents.
Why This Matters for FSI
- FINRA 4511: Requires preservation and protection of customer records — DLP rules can help block or warn on customer PII appearing in AI prompts and responses, but do not by themselves satisfy the books-and-records preservation requirement (see Control 2.6 — Microsoft 365 Records Management)
- FINRA 3110 / 25-07: AI-specific supervisory obligations require real-time monitoring and audit trails for AI agent data access — DLP event logging and exception review help meet these requirements
- SEC Reg S-P (as amended 2024, 17 CFR 248): Privacy protection — sensitivity labels and DLP help control AI access to customer information. The 2024 amendments require a written incident response program and two distinct notification clocks: notice to affected individuals as soon as practicable but not later than 30 days after determining unauthorized access/use is reasonably likely to result in substantial harm or inconvenience, and (for covered service-provider arrangements) written notice within 72 hours to the covered institution. DLP telemetry feeds the determination but does not itself satisfy the written-program requirement (see Control 3.4 — Incident Reporting and RCA)
- GLBA 501(b): Safeguard customer information — DLP helps prevent exposure of financial account numbers
- SOX 404: IT controls over data confidentiality — DLP event logging contributes to the IT general controls evidence base when paired with Purview Audit (Control 1.7) and tamper-resistant retention; coverage is only as complete as the surfaces instrumented (see DLP Surface Coverage Matrix below)
- NYDFS 23 NYCRR 500.11 / 500.15 / 500.16: Third-party service-provider security (500.11), encryption of NPI in transit and at rest (500.15), and incident-response/business-continuity planning (500.16) — sensitivity labels with encryption, DLP egress controls, and DLP-driven incident telemetry support (do not satisfy) these requirements
- OCC Bulletin 2011-12 / Federal Reserve SR 11-7 (Model Risk Management): Where AI agents are treated as models, DLP forms part of the data-quality and confidentiality controls expected around model inputs and outputs (see Control 2.6 / 2.16)
- PCI DSS 4.0 (where cardholder data flows): Requirement 3 (protect stored account data) and Requirement 7 (least privilege) — DLP rules referencing PCI SITs help detect cardholder data leaving authorized cardholder data environments via Copilot or agents
- State breach-notification laws (NY GBL §899-aa, MA 201 CMR 17.00, CCPA/CPRA): DLP detection telemetry supports the "knew or should have known" determination that drives state notification clocks
- CFPB UDAAP (where consumer financial data is exposed): Inadvertent disclosure of consumer financial data via AI surfaces can become a UDAAP exposure; DLP-driven egress controls help reduce that surface
Non-substitution
DLP and sensitivity labels support but do not replace:
- Data classification governance — labels reflect a classification scheme that must exist on paper first (see Control 2.14 — Training and Awareness)
- Records management and preservation — SEC 17a-4(f) WORM-equivalent retention is satisfied by Microsoft 365 Records Management (Control 2.6 / 1.9), not by DLP
- Formal incident response — Reg S-P 2024 written incident response programs and the 30-day customer / 72-hour SP notification clocks are policy and process obligations (Control 3.4); DLP telemetry feeds those processes
- Supervisory review — FINRA 3110 / Notice 25-07 (RFC, contextual) supervisory obligations require human review workflows (Control 2.12); DLP alerts are inputs, not the review itself
- Encryption key custody — sensitivity-label encryption uses Microsoft-managed keys by default; jurisdictions or contracts requiring customer-held keys should evaluate Double Key Encryption (DKE) per Control 1.15
DLP Surface Coverage — the central FSI failure mode
The most common FSI DLP failure pattern is partial coverage — DLP enabled for SharePoint/OneDrive but not for endpoint, Teams chat, Exchange, the Copilot prompt/response surface, or unmanaged AI traffic. Sensitive data exfiltrates through whichever surface is uninstrumented. For Zone 3 enterprise-managed agents in regulated FSI workloads, all of the following surfaces must be instrumented and the gap (if any) documented in Written Supervisory Procedures:
| Surface | DLP location to enable |
|---|---|
| SharePoint Online sites | SharePoint sites |
| OneDrive for Business | OneDrive accounts |
| Exchange Online (mail in transit) | Exchange email |
| Teams chat & channel messages (incl. private channels) | Teams chat and channel messages — extend the default policy beyond credit cards |
| Endpoint DLP — Win 10/11, Win Server 2019/2022, last 3 macOS versions | Devices |
| Microsoft 365 Copilot & Copilot Chat — block by label (GA) | Microsoft 365 Copilot and Copilot Chat (Custom template) |
| Microsoft 365 Copilot & Copilot Chat — block prompts by SIT (preview) | Same location, separate rule |
| Power Platform connector classification (Copilot Studio agents) | PPAC Policies > Data policies |
| Power Platform HTTP endpoint filtering (preview) | PPAC connector config |
| Edge for Business — unmanaged AI (preview, ChatGPT/Gemini/DeepSeek/Copilot consumer) | Inline web traffic |
| Network DLP for unmanaged AI (preview) | Network activity policy |
| Defender for Cloud Apps (non-Microsoft SaaS) | DLP via DfCA file policy |
| Power BI / Fabric workspaces | Fabric and Power BI workspaces |
| On-premises file shares / on-prem SharePoint | Purview Information Protection scanner |
FSI rule of thumb: If any surface above is uninstrumented in Zone 3, treat that surface as the most likely exfiltration path during an incident. Reference: Learn about Microsoft Purview DLP.
- FFIEC Guidelines: Data classification — label-based access control for AI agents
Automation Available
Companion solutions in FSI-AgentGov-Solutions:
- Deny Event Correlation Report — daily deny event correlation across Purview Audit, DLP, and Application Insights
- Scope Drift Monitor — automated detection of agent data access beyond declared operational scope
Control Description
DLP policies protect sensitive information from unauthorized exposure through AI agents. When combined with sensitivity labels, DLP provides comprehensive data protection across Microsoft 365 Copilot, Copilot Studio agents, and other AI applications. Integration with DSPM for AI enables oversharing detection and AI-specific policy enforcement.
Evolving Capability: Microsoft Purview DSPM for AI is an actively developing feature set. Monitor Microsoft Learn documentation for new capabilities and changes to existing functionality.
Power Platform DLP applies to Copilot Studio agents by default
Per Microsoft public communication in early 2025, Power Platform data policies are now enforced against Copilot Studio agents and their AI-related connectors automatically. Organizations cannot opt agents out of an in-scope tenant data policy. Agents that previously operated without DLP constraints are now subject to existing tenant policies.
Recommended action: Inventory AI-related connectors in your tenant via Power Platform Admin Center > Policies > Data policies > [policy] > Connectors and confirm each is classified as Business, Non-Business, or Blocked. The connector catalog is maintained by Microsoft and additive over time — verify the live list against your tenant rather than relying on a static count.
Reference: Microsoft 365 Roadmap and Message Center (search MC973179 / Power Platform DLP for Copilot).
| Capability | Description |
|---|---|
| AI-aware DLP policies | Policies targeting AI applications to prevent sensitive data exposure |
| Sensitivity label enforcement | Block or warn based on content classification labels |
| Oversharing assessment | Identify data exposure risks in agent knowledge sources |
| Channel control | DLP controls which publishing channels agents can use |
| DSPM integration | Unified AI data protection and visibility |
| HTTP endpoint filtering | Block or allow external HTTP calls based on URL patterns |
DLP Deny Event Visibility
DLP deny events for Copilot Studio agent actions may not consistently appear in Defender advanced hunting. Organizations should verify DLP enforcement through Power Platform Admin Center analytics and Purview audit logs in addition to Defender-based monitoring.
Copilot Studio DLP Connector Categories
DLP policies can control the following connector categories for Copilot Studio agents:
| Category | Connectors | FSI Governance Notes |
|---|---|---|
| Knowledge Sources | SharePoint, OneDrive, Dataverse, Public websites, Uploaded documents | Zone 3: Restrict to approved SharePoint sites only |
| Channels | Microsoft Teams, Direct Line, Facebook, SharePoint, WhatsApp, Custom website | Zone 2-3: Block social media channels (Facebook, WhatsApp) |
| Actions | HTTP with Microsoft Entra, HTTP webhook, Premium connectors | Zone 3: Require connector-level approval |
| AI Services | Azure OpenAI, AI Builder | Apply tenant-wide policies |
Power Platform Virtual Governance Connectors
Connector catalog is dynamic
Power Platform DLP enforces classification across the AI-related connectors surfaced in your tenant's Power Platform Admin Center. The catalog is additive over time as Microsoft ships new AI capabilities; do not rely on a fixed count or closed list. The table below is illustrative — verify against your tenant's live Policies > Data policies > [policy] > Connectors view and against Microsoft Learn: Power Platform DLP.
Power Platform data policies enforce classification across AI-related connectors. The connectors below are commonly seen in FSI tenants; the exact display names and additions in your tenant may differ:
| Connector (illustrative) | Description | Zone 1-2 Recommendation | Zone 3 Recommendation |
|---|---|---|---|
| AI Builder (GPT) | Access to GPT models via AI Builder for text generation and analysis | Business | Business (with usage monitoring) |
| AI Builder (Document Processing) | AI Builder document understanding and form processing | Business | Business (monitor for sensitive content) |
| Copilot Studio (agent / topic / skill connectors) | Copilot Studio authoring and runtime connectors | Business | Business (require change-control approval) |
| Knowledge source connectors (SharePoint, Dataverse, websites) | Access to grounding data sources | Business | Business (only after Control 1.3 implemented) |
| HTTP with Microsoft Entra ID | Authenticated HTTP calls to external APIs | Business or Non-Business | Business (with endpoint filtering) |
| HTTP Webhook | Unauthenticated HTTP webhook calls | Non-Business or Blocked | Blocked (data exfiltration risk) |
| Direct Line | Agent publishing via Direct Line API for custom channels | Business | Business |
| Microsoft Teams + M365 Channel | Agent publishing into Teams and Microsoft 365 Copilot | Business | Business |
| SharePoint channel | Agent embedding in SharePoint sites | Business or Non-Business | Non-Business or Blocked (require approval) |
| Custom Website / Direct Line custom channel | Agent publishing to external websites | Non-Business or Blocked | Blocked (security review required) |
Configuration: All connectors are classified via Power Platform Admin Center > Policies > Data policies > [Policy Name] > Connectors tab. Classifications apply to all environments within the DLP policy scope.
Non-Microsoft channels require pay-as-you-go billing
When Copilot Studio agents are published to non-Microsoft channels (Direct Line custom, Slack via Direct Line, Facebook, Custom Website, telephony, etc.) and the tenant relies on Microsoft Purview / DSPM for AI to monitor those interactions, a Purview pay-as-you-go (PAYG) billing meter tied to an Azure subscription is required. Verify your billing posture before enabling non-Microsoft channels in Zone 2 or Zone 3 environments.
Zone-Specific Virtual Connector Configuration
The following table provides comprehensive zone-specific recommendations for financial services organizations:
| Zone | Configuration Approach | Rationale |
|---|---|---|
| Zone 1 (Personal Productivity) | Allow most connectors as Business; block social channels (Facebook, WhatsApp) | Enable self-service agent development while helping prevent external data sharing |
| Zone 2 (Team Collaboration) | Business classification for core capabilities; block HTTP Webhook and Custom Website; restrict social channels | Balance team collaboration needs with controlled external access |
| Zone 3 (Enterprise Managed) | Strict Business-only for approved connectors; block all unauthenticated external access; require endpoint filtering for HTTP with Entra ID | Highest security posture for customer-facing and regulated agents |
Per-Connector Zone 3 Governance:
| Connector | Zone 3 Classification | Governance Control |
|---|---|---|
| AI Builder (GPT) | Business | Required for generative AI; monitor via Control 3.1 (Usage Dashboards) |
| AI Builder (Document Processing) | Business | Document processing capability; log all document uploads |
| Copilot Studio Topics | Business | Core agent functionality; no restrictions |
| Copilot Studio Skills | Business | Power Automate integration; require flow approval per Control 2.2 |
| Copilot Studio Knowledge | Business | Prerequisites: Control 1.3 (SharePoint Governance), Control 4.1 (IAG/RCD) must be implemented first |
| HTTP with Microsoft Entra ID | Business | Required: HTTP endpoint filtering (allow list only); see below for FSI patterns |
| HTTP Webhook | Blocked | Unauthenticated HTTP poses data exfiltration risk; use Entra-authenticated alternative |
| Direct Line | Business | Required for web chat deployment; monitor via Control 3.3 (Conversation Transcripts) |
| Microsoft Teams Channel | Business | Primary publishing channel for internal agents |
| SharePoint Channel | Non-Business or Blocked | Require security review before enabling; embedding poses XSS risk |
| Custom Website Channel | Blocked | External publishing requires comprehensive security review and penetration testing |
FSI Governance Recommendations:
- Prerequisite Controls: Before classifying Copilot Studio Knowledge as Business, implement Control 1.3 (SharePoint Content Governance) and Control 4.1 (Information Access Governance) to prevent agents from grounding on unauthorized content
- HTTP Connector Strategy: Zone 3 agents should use HTTP with Microsoft Entra ID only (never HTTP Webhook); configure endpoint filtering with allow list of approved internal APIs and regulatory data sources
- Channel Publishing: For customer-facing agents, approve only Microsoft Teams Channel and Direct Line; block Custom Website and SharePoint channels until publishing strategy undergoes change control approval
- Separation of Duties: DLP policy changes for Zone 3 environments should require dual approval (Power Platform Admin + AI Governance Lead) per Control 2.3 (Change Management and Release Planning)
HTTP Endpoint Filtering
For agents that call external APIs via the "HTTP with Microsoft Entra ID" connector, DLP policies can enforce URL-based filtering. This capability helps support FINRA 4511 (helping prevent unauthorized data sharing via external API calls), GLBA 501(b) (controlling external access paths to customer information), and SOX 404 (documenting IT controls over external integrations).
Configuration: Power Platform Admin Center > Policies > Data policies > [Policy Name] > Connectors > HTTP with Microsoft Entra ID > Configure connector > Endpoint filtering.
| Filter Type | How It Works | When to Use |
|---|---|---|
| Allow list | Only specified URL patterns permitted; all others blocked | Zone 3 environments (default deny approach) |
| Block list | Specified URL patterns blocked; all others allowed | Zone 1-2 environments (block known risky endpoints) |
| Pattern matching | Wildcards (*) and domain patterns for flexible matching |
Both modes; enables domain-level or path-level control |
Common FSI Endpoint Patterns
URLs below are illustrative patterns for endpoint filtering configuration — replace with your organization's actual domains.
The following table provides FSI-specific endpoint patterns for HTTP endpoint filtering allow lists:
| Pattern | Purpose | Example URLs | Allow/Block |
|---|---|---|---|
*.internal.example.com |
Internal corporate APIs | https://api.internal.example.com/customer |
Allow (Zone 3) |
*.example.com |
Corporate domain APIs | https://api.example.com/* |
Allow (Zone 3) |
https://api.sec.gov/* |
SEC EDGAR API for regulatory filings | https://api.sec.gov/submissions/ |
Allow (Zone 2-3) |
https://api.finra.org/* |
FINRA regulatory data APIs | https://api.finra.org/data/ |
Allow (Zone 2-3) |
https://www.ffiec.gov/* |
FFIEC Central Data Repository | https://www.ffiec.gov/nicpubweb/ |
Allow (Zone 2-3) |
https://data.treasury.gov/* |
U.S. Treasury data feeds | https://data.treasury.gov/datasets/ |
Allow (Zone 2-3) |
*.marketdata.example.com |
Approved market data vendors (Bloomberg, Refinitiv) | https://api.marketdata.example.com/v2/ |
Allow (Zone 2-3, with vendor data-license agreement) |
https://*.social-network.example.com/* |
Social media APIs (LinkedIn, Twitter, Facebook) | https://api.twitter.com/2/tweets |
Block (Zone 2-3) |
https://*.file-sharing.example.com/* |
Consumer file sharing (Dropbox, Box personal) | https://api.dropbox.com/2/files/ |
Block (Zone 3) |
https://*.free-tier.example.com/* |
Free-tier external APIs (no SLA, no contract) | Various | Block (Zone 3) |
http://* (non-HTTPS) |
Unencrypted HTTP endpoints | Any non-HTTPS URL | Block (all zones) |
Zone-Specific Filtering Strategies:
- Zone 1: Use block list mode; block social media APIs, consumer file sharing, and unencrypted HTTP
- Zone 2: Use allow list or block list depending on agent scope; document approved external endpoints in agent registration
- Zone 3: Use allow list mode exclusively; explicitly permit only internal APIs and approved regulatory data sources
Banking System API Patterns:
For internal banking systems, common patterns to allow in Zone 3:
*.internal.example.com # Internal domain (all subdomains)
api.example.com # Primary API gateway
*.core-banking-system.local # On-premises core banking APIs
https://api.partner.example.com/* # Approved partner bank APIs (with data-sharing agreement)
Regulatory Data Source Patterns:
For agents that need access to regulatory data:
https://api.sec.gov/* # SEC EDGAR API
https://api.finra.org/* # FINRA regulatory APIs
https://www.ffiec.gov/* # FFIEC data repository
https://data.treasury.gov/* # U.S. Treasury data feeds
https://www.federalreserve.gov/* # Federal Reserve data
Zone 3 Best Practice
For customer-facing agents, configure HTTP endpoint filtering to allow only pre-approved external APIs. Combine with network isolation (Control 1.20) for defense in depth. Document all allowed external endpoints in your IT change control system per Control 2.3 (Change Management and Release Planning).
Market Data Vendor APIs
If agents require access to market data provider APIs (Bloomberg, Refinitiv, etc.), verify that:
- A vendor data-license / data-processing agreement is in place (BAA terminology is HIPAA-specific and does not apply to FSI market-data vendors)
- The vendor API supports audit logging of all data access
- API credentials are stored in Azure Key Vault (Control 1.15)
- API access is limited to specific agents via endpoint filtering
Document vendor API approvals in your third-party risk management system per Control 2.7 (Vendor and Third-Party Risk Management).
Regulatory Mapping: Virtual connector governance and HTTP endpoint filtering help support FINRA 4511 (helping prevent unauthorized data sharing by controlling external API access paths and publishing channels), GLBA 501(b) (safeguarding customer information access by restricting knowledge sources and blocking unauthenticated connectors), and SOX 404 (documenting IT controls over AI data flows by enforcing classification across all AI-related virtual governance connectors in scope).
Endpoint filtering preview status
Connector endpoint filtering for HTTP connectors is documented on Microsoft Learn as prerelease / preview with design-time and runtime limitations. Validate behavior in a non-production environment before relying on it as a sole control in regulated production. Reference: Connector endpoint filtering.
DLP for Microsoft 365 Copilot and Copilot Chat
Rollout status
The Microsoft 365 Copilot and Copilot Chat DLP location is generally available for the block-by-label action. The block-by-SIT-on-prompts capability is documented by Microsoft Learn as preview as of this revision. Verify your tenant's current rollout status against the Microsoft 365 Roadmap and Message Center before relying on either as a sole Zone 3 control.
A DLP capability allows organizations to (a) block sensitive information types (SITs) from being processed in Microsoft 365 Copilot and Copilot Chat prompts (preview), and (b) prevent Copilot from processing labeled files and emails as grounding content (GA). This is distinct from DLP for files at rest or email in transit.
| Aspect | DLP for Copilot prompts (SITs) | Block by sensitivity label | Files / Email DLP |
|---|---|---|---|
| Status | Preview | GA | GA |
| Scope | User prompts to M365 Copilot and Copilot Chat | Labeled SharePoint Online and OneDrive files; Exchange emails sent on or after January 1, 2025 | Documents, emails, messages |
| License | Available for tenants with access to Microsoft 365 Copilot and Copilot Chat — verify per-user entitlement against the M365 Service Descriptions | Verify per-user entitlement against the Purview DLP licensing guidance | Microsoft Purview DLP entitlements (typically E5 / E5 Compliance / Purview Suite) |
| Location in policy | "Microsoft 365 Copilot and Copilot Chat" — Custom template only | "Microsoft 365 Copilot and Copilot Chat" — Custom template only | Standard file/email locations |
| Action | Restrict Copilot from processing prompts | Prevent Copilot from processing/summarizing labeled content | Block, notify, or warn |
Same-rule restriction (read before authoring rules)
For the Microsoft 365 Copilot and Copilot Chat DLP location, you cannot combine Content contains sensitive info types and Content contains sensitivity labels in the same rule. Create separate rules in the same policy — Rule A with the SIT condition, Rule B with the sensitivity-label condition. Saving a single rule with both conditions will be rejected by the Purview UI. Source: Learn — DLP for Microsoft 365 Copilot location (Important callout).
Block-by-label scope limits
The Prevent Copilot from processing content action applies only to:
- Files in SharePoint Online and OneDrive for Business
- Emails sent on or after January 1, 2025 (Exchange Online)
- Calendar invites are not supported
- Items still appear in citations with a link even when the content is not summarized into the response
Files uploaded directly into a Copilot prompt are not scanned by this DLP location.
Custom template required; admin-unit limitations
- The Microsoft 365 Copilot and Copilot Chat location is exposed only when you create a Custom policy in Purview. The Standard templates (Financial, Privacy, etc.) do not surface this location.
- The Copilot DLP location does not support administrative units. A Restricted Administrative Unit-scoped admin cannot create or edit a policy that includes this location — use a tenant-scoped role.
- DLP policy changes for the Copilot location can take up to 4 hours to fully propagate. Plan validation windows accordingly and treat earlier "no match" results as inconclusive, not as failure.
FSI use case: Help prevent users from pasting customer account numbers, SSNs, or other regulated PII directly into Copilot prompts (SIT rule), and help prevent Copilot from processing labeled customer files into responses (label rule), even when the source document allows the user direct access.
Key Configuration Points
- Build the Microsoft 365 Copilot and Copilot Chat DLP policy from the Custom template in Purview (Standard templates do not expose this location)
- Split conditions into separate rules in the same policy: Rule A for SITs, Rule B for sensitivity labels (the same-rule restriction applies to the Copilot location)
- Configure Power Platform data policies in Power Platform Admin Center for Copilot Studio agents and connector classification (this is a separate product from Purview DLP)
- Create sensitivity label taxonomy (Public, Internal, Confidential, Highly Confidential) and publish label policies to the appropriate users and groups (publishing is required — labels do not appear to users until a label policy is published)
- Implement SITs for financial data (SSN, ABA routing, account numbers) per Control 1.13 and document the confidence threshold and proximity settings used in each rule
- Configure label-based DLP rules to prevent Copilot from processing Highly Confidential content (action label per current Learn UI; the action does not remove user access to the underlying file and items may still appear in citations)
- Use Power Platform DLP to control which publishing channels Copilot Studio agents can use; treat non-Microsoft channels as a higher-risk surface (PAYG and additional review required)
- Validate custom MCP servers against Power Platform DLP policy scope and tool-level access controls before enabling them in regulated environments
- Start every new policy in Test with notifications mode and only move to enforcement after the propagation window (up to 4 hours for the Copilot location) and a documented validation pass
Do not combine SIT and sensitivity-label conditions in one rule for the Copilot location
Saving a single Copilot-location rule that contains both Content contains > Sensitive info types and Content contains > Sensitivity labels is rejected by the Purview UI. Always create two rules in the same policy. Source: Learn — DLP for Microsoft 365 Copilot location (Important callout).
Block-by-label scope (read with the rule)
The block-by-label action applies only to:
- Files in SharePoint Online and OneDrive for Business
- Emails sent on or after January 1, 2025 (Exchange Online)
- Calendar invites are not supported
- Items still appear in citations with a link
- Files uploaded directly into a Copilot prompt are not scanned by this DLP location
This action helps support GLBA 501(b) data protection objectives for highly confidential content but does not, by itself, satisfy any single regulatory obligation.
Automated Validation: Deny Event Correlation Report
For aggregated DLP violation reporting correlating deny events across Purview Audit, DLP, and Application Insights with anomaly detection and zone-based alerting, see the Deny Event Correlation Report solution.
Capabilities:
- Multi-source deny event extraction (RAI telemetry, Purview Audit, Purview DLP)
- Daily correlation engine with 7-day trend analysis and volume anomaly detection
- Zone-based alerting with Teams adaptive cards and email notifications
- Dataverse persistence with zone-based retention (90d/365d/730d)
- SHA-256 integrity-hashed evidence export with regulatory alignment mapping
Deployable Solution: deny-event-correlation-report provides PowerShell extraction scripts, Dataverse infrastructure, Power Automate orchestration flow, and evidence export pipeline.
Sensitivity Label Boundaries
The control relies on sensitivity labels operating in their documented scope. Two boundaries are commonly misunderstood:
Container labels vs. file labels. Labels applied to Microsoft 365 Groups, Teams, and SharePoint sites govern container-level settings (privacy, external sharing, device access, default link types). Items inside the container do not inherit the container label. File-level labeling requires either a published file/email label policy, an auto-labeling policy, or manual application.
Auto-labeling scope. Service-side auto-labeling policies apply to:
- SharePoint Online sites
- OneDrive for Business accounts
- Exchange Online mailboxes
Auto-labeling does not label Copilot prompts, agent responses, or "AI interactions" — there is no such location in Purview. Label-based DLP for Copilot relies on labels already present on the underlying SharePoint / OneDrive / Exchange items at the time of the prompt. Reference: Apply a sensitivity label automatically.
Adaptive Protection Integration
Adaptive Protection, driven by Insider Risk Management (IRM), can dynamically adjust DLP rule strength for Copilot interactions based on a user's risk tier (low / moderate / elevated). This is the recommended pattern for risk-tiered enforcement on Zone 2 / Zone 3 populations.
| Aspect | Detail |
|---|---|
| Dependency | Insider Risk Management must be onboarded and a baseline window completed before risk tiers are populated |
| Hook into DLP | DLP rule conditions reference the IRM-derived risk level |
| Sovereign cloud parity | Insider Risk Management — and therefore Adaptive Protection — is not available in any US Government cloud (GCC, GCC High, DoD) per Microsoft Learn. Zone 3 deployments in those clouds must use static, role-based DLP rules (no risk-tiered enforcement) and document this as a compensating-control note. Source: Adaptive Protection in Microsoft Purview |
| License | Verify per-user IRM entitlement against current Microsoft 365 licensing guidance |
Reference: Adaptive Protection in Microsoft Purview.
Sovereign Cloud Availability
DLP, sensitivity labels, and the connector classification used in this control have different parity across Microsoft commercial and US Government clouds. Verify against your tenant before assuming the click-path or the capability applies.
| Capability | Commercial | GCC | GCC High | DoD |
|---|---|---|---|---|
| Purview DLP for Microsoft 365 Copilot and Copilot Chat (block by label) | GA | Verify Roadmap / MC | Verify — staged | Verify — staged |
| Purview DLP for Microsoft 365 Copilot prompts (SIT, preview) | Preview | Verify | Verify | Verify |
| Power Platform data policies | GA | GA | GA | GA |
| Connector endpoint filtering | Preview | Verify | Verify | Verify |
| Sensitivity labels (file / email) | GA | GA | GA | GA |
| Auto-labeling (SPO / ODB / Exchange) | GA | GA | GA (verify model parity) | GA (verify model parity) |
| Insider Risk Management + Adaptive Protection | GA | Not available | Not available | Not available |
| DSPM for AI | Staged | Verify | Verify | Verify |
Portal endpoints:
- Commercial:
https://purview.microsoft.comandhttps://admin.powerplatform.microsoft.com - GCC:
https://compliance.microsoft.com(transitioning topurview.microsoft.com); PPACadmin.powerplatform.microsoft.usfor Government tenants - GCC High / DoD:
https://purview.microsoft.usandhttps://admin.powerplatform.microsoft.us
For PowerShell, use Connect-IPPSSession -ConnectionUri ... -AzureADAuthorizationEndpointUri ... for Security & Compliance and Add-PowerAppsAccount -Endpoint usgov | usgovhigh | dod for Power Platform. See docs/playbooks/_shared/powershell-baseline.md for canonical sovereign-cloud parameters.
Zone-Specific Requirements
| Zone | Requirement | Rationale |
|---|---|---|
| Zone 1 (Personal) | Baseline DLP policies; avoid scope beyond user's own data | Low friction while maintaining safety |
| Zone 2 (Team) | DLP with label conditions; identified owner and approval trail | Shared agents increase blast radius |
| Zone 3 (Enterprise) | Strictest DLP with mandatory labels; block mode enforcement | Highest audit/regulatory risk |
Roles & Responsibilities
| Role | Responsibility |
|---|---|
| Purview Compliance Admin | Create and manage DLP policies; configure DLP locations for AI workloads |
| Purview Info Protection Admin | Manage sensitivity labels and taxonomy |
| Power Platform Admin | Configure Power Platform DLP policies and virtual governance connector classification |
| AI Administrator | Manage Copilot connector delegation, AI-specific DLP policy scoping, and Copilot data protection settings |
| Purview Data Security AI Admin | Configure Purview DSPM for AI policies and AI data security posture assessments |
| Entra Security Admin | View DLP reports and alerts; investigate DLP violations |
| AI Governance Lead | Agent data protection strategy; approve HTTP endpoint filtering allow lists |
Related Controls
| Control | Relationship |
|---|---|
| 1.6 - DSPM for AI | AI monitoring and assessment |
| 1.13 - Sensitive Information Types | SITs power DLP detection |
| 1.3 - SharePoint Content Governance | Knowledge source protection |
| 4.1 - SharePoint IAG | Content discovery controls |
Implementation Playbooks
Step-by-Step Implementation
This control has detailed playbooks for implementation, automation, testing, and troubleshooting:
- Portal Walkthrough — Step-by-step portal configuration
- PowerShell Setup — Automation scripts
- Verification & Testing — Test cases and evidence collection
- Troubleshooting — Common issues and resolutions
MCP Server DLP Governance
Custom MCP servers in Copilot Studio are subject to Power Platform data policies, including DLP enforcement and access controls. Treat custom MCP servers as an expanded integration surface, not as a DLP bypass.
| DLP consideration | Control response |
|---|---|
| Reusable MCP servers can serve many agents and non-Microsoft tools | Document every approved consumer and data classification in the agent inventory or MCP registry |
| Servers can combine connector actions, tools from other MCP servers, and custom APIs | Review tool-level permissions and exposed data paths during DLP change control |
| DLP is applied at server and tool level | Validate policy behavior in testing before relying on MCP servers for Zone 3 data |
| Cross-platform compatibility increases reuse | Extend Purview audit review and exception handling to external agent platforms that can call the same MCP server |
FSI implementation guidance: - Pair this control with Control 1.4 - Advanced Connector Policies so MCP server approvals and DLP classifications stay aligned - Require named ownership and monthly review for any custom MCP server approved in Zone 3 - Use sensitivity labels and Purview reporting for data at rest, but validate response- and tool-level DLP behavior during controlled testing
Verification Criteria
Confirm control effectiveness by verifying:
- The Microsoft 365 Copilot and Copilot Chat DLP policy was created from the Custom template (capture screenshot evidence of the template selection)
- The policy contains separate rules for SIT-based and sensitivity-label-based conditions (export
Get-DlpComplianceRuleand confirm two distinct rule objects) - Sensitivity labels exist, and at least one label policy is published to the in-scope users or groups (
Get-LabelPolicyreturns the expected policy withMode = Enable) - Auto-labeling policies, where used, are scoped to SharePoint Online, OneDrive for Business, and Exchange Online locations only
- SITs referenced by the policy are validated and detecting sensitive content per Control 1.13 (record the confidence threshold and proximity settings used)
- A deterministic activation test (named test user, known prompt, UTC-stamped) triggers the expected DLP action after the propagation window (≥ 4 hours for the Copilot location) and produces a record in Purview Audit
- Power Platform data policies classify all in-scope AI-related connectors and the classification is reflected in
Get-DlpPolicyoutput - If custom MCP servers are enabled, server-level and tool-level DLP behavior is validated and documented before production use
- If Adaptive Protection is in use, the IRM dependency is documented, baseline window is complete, and behavior is validated in a non-production tenant first; for GCC High / DoD, the parity gap is recorded as a compensating-control note rather than an assertion of behavior
Additional Resources
- Microsoft Learn: DLP for Microsoft 365 Copilot location
- Microsoft Learn: Create and Deploy DLP Policies
- Microsoft Learn: Sensitivity Labels Overview
- Microsoft Learn: Apply a sensitivity label automatically
- Microsoft Learn: Sensitivity labels for containers (Teams / Groups / Sites)
- Microsoft Learn: DSPM for AI Overview
- Microsoft Learn: Adaptive Protection in Purview
- Microsoft Learn: Power Platform DLP
- Microsoft Learn: Connector endpoint filtering (preview)
- Microsoft Learn: Copilot Studio security and governance
- Microsoft Learn: New-DlpCompliancePolicy cmdlet
- Microsoft Learn: Endpoint DLP onboarding overview
Agent Essentials
Note: Agent governance features in the M365 Admin Center are rolling out progressively. Verify feature availability in your tenant.
- Microsoft Learn: Agent Deployment Checklist - Category 7 covers data security and compliance requirements for agent deployments
Updated: April 2026 | Version: v1.4.0 | UI Verification Status: Current