Control 1.5: Data Loss Prevention (DLP) and Sensitivity Labels

Control ID: 1.5
Pillar: Security
Regulatory Reference: FINRA 3110, FINRA 4511, FINRA RN 24-09, 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 Bulletin 2026-13 (formerly 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: May 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.com under Data Loss Prevention. Governs prompts and labeled grounding files for first-party Copilot.
Power Platform data policies — configured in admin.powerplatform.microsoft.com under Policies > Data policies. Governs Microsoft 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 Rule 3110 / Regulatory Notice 24-09: AI-specific supervisory obligations under FINRA's technology-neutral application of existing supervision rules require near-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 2026-13 (formerly OCC Bulletin 2011-12) / Federal Reserve SR 26-2 (formerly 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 Rule 3110 / Regulatory Notice 24-09 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.2 (Usage Analytics and Activity Monitoring)
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 1.7 (Comprehensive Audit Logging and Compliance)
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 sensitivity-label file and email processing restriction. Microsoft Learn documents both the SIT prompt processing restriction and the SIT external web-search restriction as preview as of this revision. Verify your tenant's current rollout status against the Microsoft 365 Roadmap and Message Center before relying on any single action as a sole Zone 3 control.

A DLP capability allows organizations to (a) restrict Microsoft 365 Copilot and Copilot Chat from processing prompts that contain sensitive information types (SITs) (preview), (b) restrict external web search when prompts contain SITs (preview), and (c) 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)	DLP for Copilot external web search (SITs)	Block by sensitivity label	Files / Email DLP
Status	Preview	Preview	GA	GA
Scope	User prompts to M365 Copilot and Copilot Chat	External web search as a grounding source for prompts containing SITs	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	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	"Microsoft 365 Copilot and Copilot Chat" — Custom template only	Standard file/email locations
Action	Prevent Copilot from processing content > Processing prompts	Prevent Copilot from processing content > Performing Web Searches	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 restrict users from pasting customer account numbers, SSNs, or other regulated PII directly into Copilot prompts (SIT prompt rule), restrict external web search as a grounding source when a prompt contains regulated PII (SIT web-search 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 SIT and sensitivity-label conditions into separate rules in the same policy (the same-rule restriction applies to the Copilot location)
Document whether the SIT prompt-processing restriction and SIT external web-search restriction are configured as separate rules or distinct actions, then validate each behavior independently
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

Sensitivity labels are the only supported AI-app encryption path

Microsoft Purview sensitivity labels are the only supported AI-app encryption path for Copilot and Microsoft 365-grounded scenarios. Encryption-at-rest applied at the underlying storage layer (BitLocker on the SharePoint farm, Customer Key DEPs, Power Platform CMK, Azure Storage Service Encryption) is not propagated to AI agent grounding output — Copilot prompts, responses, and citations operate on decrypted content surfaced through the user's authorization context. To carry encryption-equivalent protection into the AI grounding/output path, the source content must be labelled and the label must enforce content marking, encryption (RMS), or DLP-driven processing restrictions per Control 1.6 and the Copilot DLP location patterns in this control.

See Control 2.1 — Customer Lockbox & Data Residency Posture for related caveats on Customer Lockbox coverage of Agent 365 audit-logging and the data-residency surface that affects label-based encryption evidence.

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
License	Verify per-user IRM entitlement against current Microsoft 365 licensing guidance

Reference: Adaptive Protection in Microsoft Purview.

Sanctions Screening and BSA / AML for Transaction-Touching Agents

This subsection extends the DLP and labeling controls above with the specific sanctions-screening and Bank Secrecy Act / Anti-Money Laundering guardrails that apply when an agent is involved in any payment, credit, lending, account-opening, or wire-instruction workflow. DLP rules and sensitivity labels by themselves do not address OFAC sanctions exposure or 31 CFR Chapter X transaction-monitoring obligations — those require dedicated screening and audit-trail controls, applied before any agent-influenced transaction is executed or any decision is communicated to the customer.

Scope. Applies to any Zone 2 or Zone 3 agent that:

Initiates, drafts, or recommends a payment, transfer, or wire instruction
Contributes to a credit, lending, account-opening, KYC / CIP, or onboarding decision
Surfaces customer or counterparty information that flows into a transaction system of record
Generates outbound communication that confirms a transaction or commits the firm to a counterparty relationship

Required guardrails:

OFAC SDN list integration. Before any agent-recommended action that touches a payment, credit, or account-opening workflow is executed, the named counterparty (and, where applicable, beneficial owners) must be screened against the OFAC Specially Designated Nationals and Blocked Persons (SDN) List, the Sectoral Sanctions Identifications (SSI) List, and any applicable Consolidated Sanctions List. The screening is performed by the firm's existing sanctions-screening platform (e.g., the AML / sanctions transaction-monitoring system) — the agent must not execute or commit until the screening result is captured.
Country-based screening. Block or escalate any agent-initiated workflow that involves a counterparty, beneficial owner, address, or routing instruction in a comprehensively sanctioned jurisdiction (currently Cuba, Iran, North Korea, Syria, and the Crimea / so-called DNR / LNR regions of Ukraine — verify the current OFAC list before relying on this list). Sectoral and list-based programs (e.g., Russia/Belarus directives) require routing to the sanctions-program SME rather than auto-block.
Beneficial ownership lookup. For account-opening or relationship-establishment workflows in scope of FinCEN's Customer Due Diligence Rule (31 CFR § 1010.230) and the Corporate Transparency Act beneficial-ownership reporting regime (31 CFR § 1010.380), the agent workflow must surface beneficial-ownership data captured by the firm's CIP / KYC system before completing onboarding.
Agent-output sanctions-screening verification gate. The agent's output (or the workflow step that consumes it) is configured so that the transaction or decision cannot be committed until a recorded screening-result event is present. The verification result (clear, hit, hit-cleared-by-analyst) is persisted alongside the agent decision artifact.
Audit trail of screening result. For every in-scope agent action, retain: input payload (counterparty name, address, routing data, beneficial-owner data); the sanctions / AML platform invoked; the request and response identifiers; the disposition (clear / blocked / escalated); the human reviewer attestation where required; and the final action committed. Retain in WORM-configured storage per FINRA Rule 4511 / SEC 17a-4(f) and per the BSA five-year recordkeeping baseline (31 CFR § 1010.430).
Suspicious-activity escalation pathway. Any agent-detected pattern that meets the firm's SAR escalation criteria under 31 CFR § 1020.320 (banks) or § 1023.320 (broker-dealers) is routed to the BSA/AML team via the existing SAR queue. The agent does not autonomously file or close SAR cases — it escalates and records the escalation.
DLP rule pairing. Configure a DLP rule (Power Platform data policy or Purview Copilot location, depending on the agent surface) that detects sanctioned-country names, OFAC SDN-style identifiers, and high-risk routing identifiers in agent prompts and responses, and either blocks or warns based on zone. This rule is a detective backstop to the screening gate above — not a substitute for the dedicated sanctions-screening platform call.

Implementation guidance:

Pair this subsection with Control 1.13 - Sensitive Information Types so that sanctioned-country, OFAC-list, and routing-identifier SITs are defined once and reused by both Purview DLP and Power Platform data policies.
Coordinate with the firm's existing OFAC compliance program owner; the agent control extends — it does not replace — the OFAC compliance program required by 31 CFR Part 501 Appendix A.
For Zone 3 transaction-touching agents, require sanctions-screening evidence in the same change-control package that documents the agent's release approval (see Control 2.16).
Implementation requires coordinated work between Compliance, BSA/AML Operations, the agent owner, and Power Platform / Purview administration. Organizations should validate the screening gate against representative SDN-hit and clean-counterparty test cases before promoting any in-scope agent to Zone 3.

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

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
2.1 - Managed Environments — Customer Lockbox & Data Residency Posture	Sensitivity-label-driven encryption interaction with Customer Lockbox / data-residency scenarios is covered in the Control 2.1 sub-section

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 documents separate handling for SIT prompt processing, SIT external web-search restriction, and sensitivity-label conditions (export Get-DlpComplianceRule and confirm the rule/action mapping; SIT and sensitivity-label conditions are not combined in one rule)
Sensitivity labels exist, and at least one label policy is published to the in-scope users or groups (Get-LabelPolicy returns the expected policy with Mode = 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)
Deterministic activation tests (named test user, known prompt, UTC-stamped) confirm the prompt-processing restriction, external web-search restriction, and label-based content-processing behavior separately after the propagation window (≥ 4 hours for the Copilot location) and produce records in Purview Audit
Power Platform data policies classify all in-scope AI-related connectors and the classification is reflected in Get-DlpPolicy output
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.

Additional Resources

OFAC and BSA / AML References

OFAC: A Framework for OFAC Compliance Commitments — the five components of an effective OFAC compliance program
OFAC Sanctions List Service — primary OFAC sanctions-list distribution point (SDN, consolidated lists, sectoral and program lists)
31 CFR Part 501 Appendix A — Economic Sanctions Enforcement Guidelines
FFIEC BSA/AML Examination Manual — examiner methodology referenced by federal banking regulators
FinCEN: BSA Resources for Financial Institutions — current FinCEN guidance and rule index for 31 CFR Chapter X
31 CFR § 1010.230 — Beneficial ownership requirements (CDD Rule)
31 CFR § 1020.320 — Suspicious activity reporting (banks)
31 CFR § 1023.320 — Suspicious activity reporting (broker-dealers)

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: May 2026 | Version: v1.6.2 | UI Verification Status: Current