In This Article
- The Three Purview DLP Surfaces You Now Configure for AI
- Why May 2026 Is the Inflection Point for AI DLP
- Surface One: DLP for the Microsoft 365 Copilot Location
- Surface Two: DLP for Microsoft Foundry Agents
- Surface Three: DLP for Microsoft Agent 365
- The Pre-Deployment Checklist for Banks, Credit Unions, and Mortgage Companies
- How ABT's Guardian Operating Model Runs DLP for AI for You
- Frequently Asked Questions
Microsoft Purview Data Loss Prevention has, for years, been the policy engine that decides whether a sensitive document leaves the tenant by email, by file share, or by upload to a third-party site. As of May 2026, the same engine now decides whether a sensitive prompt reaches a Microsoft AI agent in the first place. The Microsoft Learn documentation, refreshed across all three relevant Purview pages on May 1, 2026, confirms what banks, credit unions, and mortgage companies have been waiting for: DLP for AI is a configurable, policy-driven control surface that sits at three distinct boundaries inside the Microsoft 365 and Azure AI Foundry stack.
That matters because the AI agents your team is starting to depend on, including Microsoft 365 Copilot Chat, the prebuilt agents inside Copilot, the code-first agents your developers or implementation partners build on Microsoft Foundry, and the new Microsoft Agent 365 instances that act as digital coworkers, all reach into the same tenant data your Purview DLP policies are already protecting. Until the May 2026 documentation refresh, that sentence was mostly aspirational. Now it is a configuration question.
This article walks through the three Purview DLP surfaces for AI as Microsoft documents them in May 2026, the configuration path for each, and the licensing and prerequisite picture financial institutions need to understand before the first Copilot prompt or Foundry agent goes live in production. Where ABT's Guardian operating model takes the configuration off your team's plate, we say so. Everything else is achievable in-house using only Microsoft-canonical tooling and the Microsoft Learn URLs cited throughout.
The Three Purview DLP Surfaces You Now Configure for AI
Microsoft groups its AI products into three categories on the Purview overview page at learn.microsoft.com/en-us/purview/ai-microsoft-purview. The first category, "Copilot experiences and agents," covers Microsoft 365 Copilot, Copilot Chat, Security Copilot, Copilot in Fabric, Copilot Studio, Microsoft Facilitator, and the Channel Agent in Teams. The second category, "Enterprise AI apps," covers Entra-registered AI apps, ChatGPT Enterprise, and Microsoft Foundry. The third category, "Other AI apps," covers browser-detected generative AI activity that includes consumer ChatGPT, Google Gemini, the consumer Microsoft Copilot, and DeepSeek. Microsoft Agent 365 is documented on its own page at ai-agent-365.
Across those categories, three Purview DLP surfaces matter for financial institutions getting ready to deploy AI in production. Each surface has its own configuration path. Each has its own licensing and prerequisite picture. None of them inherit from each other automatically.
| Surface | What It Controls | Configuration Path | Documentation Status (May 2026) |
|---|---|---|---|
| Microsoft 365 Copilot location | Whether Copilot processes a prompt that contains sensitive information types, whether Copilot uses external web search when prompts contain SITs, and whether Copilot can summarize a sensitivity-labeled file or email in a response. | Purview portal, DLP, Custom policy template, location set to Microsoft 365 Copilot and Copilot Chat. | Two preview features (block SITs in prompts, restrict external web search). One generally available feature (block sensitivity-labeled content from response summaries). |
| Microsoft Foundry interactions | Whether a Foundry-built or Foundry-hosted agent can process a user prompt that contains sensitive information types. | PowerShell New-DlpComplianceRule cmdlet scoped to a specific Entra-registered AI app, honored via the Microsoft Purview Process Content API in the agent code. |
Supported. Requires Foundry Data Security enablement plus pay-as-you-go billing. |
| Microsoft Agent 365 | Whether an Agent 365 instance can complete a block-or-audit DLP-relevant action across Microsoft Teams, OneDrive, SharePoint, and email, on either side of an agent-to-human or human-to-agent interaction. | Standard Purview DLP policy with the agent instance specified explicitly as a participant, the same way you would specify a user or a security group. | Supported. Agent owner is responsible for monitoring policy hits because the agent itself is unaware of a block action. |
Reading the table the right way matters. The Microsoft 365 Copilot location is where most financial institutions start, because Copilot Chat is the most common first AI deployment and the policy lives entirely inside the Purview portal. Foundry is where institutions move next as their teams or implementation partners start building agents that connect Copilot to their loan origination system, their core banking platform, or their servicing portal. Agent 365 is where institutions land once those agents start acting on behalf of users in Teams threads and email conversations. The order is intentional, because the configuration question gets harder as you move down the table.
Why May 2026 Is the Inflection Point for AI DLP
Microsoft published a coordinated documentation refresh across the three relevant Purview pages on May 1, 2026. The Foundry page at ai-azure-foundry, the Agent 365 page at ai-agent-365, and the master AI overview at ai-microsoft-purview all carry the same May 1 timestamp. The Copilot DLP location page at dlp-microsoft365-copilot-location-learn-about was last updated on April 29, 2026. That coordination is not accidental. Microsoft is signaling that the AI DLP control plane is now consistent enough across the three surfaces to treat as a single deployment effort.
For financial institutions, the practical reading is that the period between now and the next FFIEC IT examination cycle is the right window to put DLP for AI in place. Examiners increasingly ask about AI governance posture. "We use Microsoft 365 Copilot" is no longer a sufficient answer. What examiners want to see is a documented review process, a configured DLP policy, and an audit trail. All three are now possible against Microsoft-canonical tooling without third-party add-ons.
The Productivity Trade That Has to Hold
The point of deploying Microsoft 365 Copilot or a Foundry agent in a bank, credit union, or mortgage company is productivity, full stop. Loan officers need to clear pipelines faster. Underwriters need to read files in minutes instead of hours. Operations leads need agents that draft examiner-ready memos in the time it takes to drink a cup of coffee. Purview DLP for AI is the control that lets you ship that productivity without the worst case scenario where the same agent that drafts the memo also drafts the data leak. Configure it once, and the AI you wanted to deploy stays the AI you actually deployed.
Surface One: DLP for the Microsoft 365 Copilot Location
The Microsoft 365 Copilot location is the highest-leverage starting point. The Microsoft Learn documentation lists three protections at this location, and they were updated on April 29, 2026.
The first protection blocks Microsoft 365 Copilot and Copilot Chat from processing prompts that contain sensitive information types. Microsoft writes the rule literally: "This real-time control helps organizations mitigate data leakage and oversharing risks by preventing Microsoft 365 Copilot and Copilot Chat, including prebuilt agents in Microsoft 365 Copilot and Copilot Chat, from returning a response when prompts contain sensitive data and from using that sensitive data for both internal and external web searches." The capability is in preview. Once it is generally available, the policy will be the simplest single configuration that produces the largest reduction in shadow data exposure for an FI Copilot rollout.
The second protection restricts Microsoft 365 Copilot from using external web search as a grounding source when the prompt contains sensitive information types. If a user pastes a credit card number, a Social Security number, or any custom sensitive information type your Compliance Office has defined, Copilot blocks the use of external web search for that prompt and continues to ground only against permitted internal Microsoft 365 sources. Microsoft also has this capability in preview as of the May 2026 documentation refresh.
The third protection is generally available and addresses the file-and-email side. A DLP policy at the Microsoft 365 Copilot location can use the Sensitivity labels condition to exclude sensitivity-labeled content from being processed in a response summary. The labeled item still appears in the citations of the response, but the content of the item is not used in the summary or accessed by Copilot. The policy applies to files stored in SharePoint Online and OneDrive for Business, and to emails sent on or after January 1, 2025. Calendar invites are not supported. File uploads inside the prompt itself are not scanned by this surface, and DLP only checks the text typed into the prompt. Updates to the policy take up to four hours to reflect in the Copilot user experience.
Permissions to Configure DLP at the Microsoft 365 Copilot Location
The Microsoft Learn page lists the role groups authorized to create or edit a DLP policy that targets Copilot. The least-privilege option is the new Purview Data Security AI Admin role, which scopes editing to AI-related DLP policies and viewing of AI content in DSPM, without granting access to read prompts and responses. Other paths include Entra AI Admin, Purview Compliance Administrator, Purview Compliance Data Administrator, Purview Information Protection Admin, and Purview Security Administrator. Entra Global Admin works as a fallback. Microsoft recommends the lowest-privilege role that gets the job done.
Surface Two: DLP for Microsoft Foundry Agents
The Foundry side of the story is more developer-flavored than the Copilot side, because Foundry is the platform where code-first agents get built and hosted. Two prerequisites have to be in place before Purview can manage anything that happens inside a Foundry agent.
First, the customer has to enable Microsoft Purview Data Security for Microsoft Foundry. Microsoft documents two paths. Path one is to enable Data Security inside the Microsoft Foundry Control Plane through the Foundry portal at ai.azure.com. Path two is to enable Data Security for Azure AI inside Microsoft Defender for Cloud through the Azure portal. Either path turns on the Foundry-side telemetry and policy enforcement hooks that Purview needs to see.
Second, managing policies for Microsoft Foundry AI interactions with Microsoft Purview requires pay-as-you-go billing to be enabled in the organization. Microsoft Purview Audit is included with the Microsoft Purview license, so audit data flows without the billing step, but DLP policy enforcement at the Foundry surface specifically requires the pay-as-you-go billing hookup.
Once the prerequisites are in place, current DLP support is described in one paragraph that financial institutions should read carefully. Microsoft writes: "Support today is only available for a DLP policy that blocks prompts based on sensitive information types. This requires the configuration of a PowerShell cmdlet that's scoped to a specific Entra-registered AI app. The AI app can honor this configuration by integration with the Microsoft Purview APIs."
That paragraph does three things. It scopes the policy to a specific AI app rather than a global Foundry-wide enforcement. It places the configuration step in PowerShell using New-DlpComplianceRule rather than in the Purview portal. And it requires the AI app code itself to integrate with the Microsoft Purview Process Content API in the Microsoft Graph beta endpoint at graph.microsoft.com/beta/security/userDataSecurityAndGovernance/processContent. The integration is the developer's responsibility. Microsoft maintains a sample on GitHub that shows the integration pattern using a serverless LangChain.js Foundry app.
A regional bank engages an implementation partner to build a code-first agent on Foundry that reads loan files from the bank's document management system and drafts summary memos for the credit committee. The partner builds the agent against the agent SDK, registers the app in Entra ID, gets the bank to approve the consent, and ships it to production. Six months later, the bank's CISO asks whether the agent stops itself from processing prompts that contain sensitive personally identifiable information.
For the answer to be yes, three things have to have happened: the bank has to have enabled Purview Data Security for Foundry through one of the two enablement paths, the bank has to have configured a DLP rule with New-DlpComplianceRule scoped to that specific Entra-registered app, and the partner has to have integrated the agent code with the Microsoft Purview Process Content API. Without all three, the agent processes any prompt that the user can submit. The CISO's question becomes a project, not a confirmation.
One nuance from the Microsoft Learn page is worth capturing because it surprises developers. Microsoft writes: "Microsoft Purview Data Security Policies for Foundry Services interactions apply to API calls that use Microsoft Entra ID authentication with a user-context token, or for API calls that explicitly include user context. For all other authentication scenarios, user interactions are displayed in Microsoft Purview Audit and AI Interactions with classifications in DSPM for AI Activity Explorer only." Translated for FIs: the DLP policy enforces only when the agent receives the prompt under a user-context identity. Service-to-service calls, batch processes, or system-managed identities flow into Audit and DSPM for AI for visibility but do not trigger DLP enforcement at the Foundry surface. That distinction is the part developers most often miss.
Surface Three: DLP for Microsoft Agent 365
The Agent 365 surface is the easiest of the three to reason about because it follows the standard Purview DLP playbook that Compliance Officers already understand. The Microsoft Learn page at ai-agent-365 describes the configuration in one sentence: "Supported by explicitly specifying agent instances in the DLP policy as you would a user, or by specifying a security group that includes agent instances."
What that means in practice is straightforward. When you create or edit a DLP policy in the Purview portal that targets Microsoft Teams, OneDrive or SharePoint, or email, the policy participants list now accepts agent instances the same way it accepts users. The policy can block or audit agent-to-human and human-to-agent interactions across those surfaces. The policy actions, the conditions, the alerts, and the integration with Microsoft Defender XDR for incident response all work the same way they always have.
Two operational warnings are worth flagging in the same sentence Microsoft uses. First: "Because an agent instance is unaware of the block action, the agent owner must actively monitor a DLP policy that uses this configuration and understand the impact to subsequent workflows." Translation: when a DLP policy blocks an Agent 365 action, the agent does not learn that the action was blocked and does not retry, route around, or ask the user. The agent's downstream workflow simply does not run. The agent owner has to monitor the DLP policy and trace the workflow impact.
Second: newly created content from an Agent 365 instance does not automatically inherit sensitivity labels from the source items the agent read. If the agent reads three sensitivity-labeled customer files and produces a one-page summary, the summary is unlabeled by default. Sensitivity-label-based DLP rules do not catch the new artifact. The agent owner has to apply labels in the agent's tooling, or the Compliance Office has to deploy auto-labeling rules that include agent-generated content.
The DLP rule is the easy part. The agent owner taking responsibility for monitoring policy hits and understanding the downstream workflow impact is the part that turns a configuration into a control.
The Pre-Deployment Checklist for Banks, Credit Unions, and Mortgage Companies
Reading the three surfaces in sequence, a financial institution that is preparing to roll out Microsoft 365 Copilot, a Foundry-built agent, or an Agent 365 instance has a small but specific list of configuration questions to answer before the first user gets access. The checklist is short on purpose. Each item points back to the Microsoft Learn page that documents the underlying capability, so your team can read the source and execute against it.
Microsoft 365 E5 or Microsoft 365 E5 Compliance unlocks the full Purview DLP feature set for the Copilot location. The new Purview Data Security AI Admin role is included for least-privilege configuration. Microsoft Foundry policy enforcement additionally requires pay-as-you-go billing on the tenant. Agent 365 DLP works on the standard Purview license you already use for user-targeted DLP.
Inventory the SITs your DLP policy will rely on. Microsoft ships built-in detectors for credit card numbers, Social Security numbers, ABA routing numbers, US driver's license numbers, US passport numbers, and others relevant to financial institutions. Add custom SITs for institution-specific patterns: loan numbers, customer relationship identifiers, internal account numbering. Validate the SIT match precision against a sample of real prompts before turning the policy to enforce.
Open Purview, Solutions, Data Loss Prevention, Policies. Create a Custom-template policy. Set the location to Microsoft 365 Copilot and Copilot Chat. Configure rules for the SIT block, for the external-web-search restriction, and for the sensitivity-label-based file or email block. Run the policy in simulation mode for a week. Review hits. Then turn on enforcement.
If the institution is going to host code-first agents on Foundry, enable Purview Data Security for Foundry through either the Foundry Control Plane or Microsoft Defender for Cloud. Turn on pay-as-you-go billing if it is not already on. Decide whether agents will be hosted directly by the institution or by an implementation partner under partner-of-record arrangements.
For each Entra-registered Foundry agent, configure a DLP rule with the New-DlpComplianceRule PowerShell cmdlet scoped to that specific app. Hand the cmdlet output to the developer or implementation partner. Confirm the agent code calls the Microsoft Purview Process Content API on every user-context prompt. Test against a known-bad prompt that should trigger the rule and confirm the agent declines to process it.
For every Agent 365 instance the institution deploys, add the instance as a participant in the relevant Purview DLP policies. Identify the agent owner and assign monitoring responsibility for policy hits. Document the workflow impact for at least the top two scenarios where a DLP block would alter the agent's output.
Want a structured read on your AI readiness before you start configuring DLP?
Our AI Readiness Scan walks your team through the four-phase Microsoft AI Journey and surfaces where the configuration work is concentrated for your institution. Five minutes online, no sales call attached, and the output maps cleanly to the Purview DLP checklist above.
AI Readiness Scan Talk to an ABT AI SpecialistMicrosoft Purview Data Loss Prevention now applies at three boundaries inside the Microsoft 365 and Microsoft Foundry stack: the Microsoft 365 Copilot prompt boundary, the Microsoft Foundry agent prompt boundary, and the Microsoft Agent 365 interaction boundary across Teams, OneDrive or SharePoint, and email. The same engine that already governs file uploads, email sends, and endpoint copy-paste actions for users now governs how Copilot and agents process prompts and produce responses. For banks, credit unions, and mortgage companies running on Microsoft 365 E5 with Microsoft Purview, the underlying license is already in place. The configuration work in front of the institution is policy design, simulation, and enforcement, not net-new tooling investment.
How ABT's Guardian Operating Model Runs DLP for AI for You
The DLP for AI configuration work is straightforward when an institution has an in-house security engineer who reads Microsoft Learn fluently, understands PowerShell, and has bandwidth for a one-time deployment plus a quarterly governance review. Most banks, credit unions, and mortgage companies do not have that combination of skills, time, and bandwidth on staff today. This is where ABT's Guardian operating model fits.
Guardian is how ABT manages Microsoft 365 tenants for the more than 750 banks, credit unions, and mortgage companies under our Tier-1 Microsoft Cloud Solution Provider relationship. ABT manages the customer Microsoft 365 tenant via delegated administrator permissions, while Microsoft owns and operates the underlying Microsoft 365 infrastructure and service code. ABT hosts customer Azure environments where financial institution workloads run, including code-first Microsoft Foundry agents, as the partner of record on the customer's Azure subscription.
DLP for AI, Run by Guardian
Surface One (Microsoft 365 Copilot location): Guardian configures the Custom DLP policy with the SIT block, the external-web-search restriction, and the sensitivity-label exclusion on every customer tenant where Microsoft 365 Copilot is licensed. The policy runs in simulation mode for a defined window before enforcement, and Guardian operations reviews the simulation hits with the customer's Compliance Office before the rule turns to enforce.
Surface Two (Microsoft Foundry): For institutions that host Foundry agents under Guardian (including ABT's MortgageGuide Copilot, currently in beta on Microsoft Azure AI Foundry), Guardian enables Purview Data Security for Foundry, configures the New-DlpComplianceRule policies scoped to each Entra-registered agent, and validates the Process Content API integration with the agent code as part of the Foundry build pipeline. Pay-as-you-go billing setup is part of the Guardian onboarding for Foundry workloads.
Surface Three (Microsoft Agent 365): Guardian adds Agent 365 instances to the customer's Purview DLP policies as part of the agent provisioning workflow, identifies the agent owner, and provides monitoring telemetry to the customer Compliance Office through the Guardian operations report. Agent 365 instances do not enter production without a documented owner and a documented workflow-impact assessment for at least the top two DLP-block scenarios.
For continuing reading on related topics, our team has published several companion articles relevant to the AI governance posture that Purview DLP for AI fits inside. Our Microsoft Copilot Business buyer's guide for financial institutions covers the licensing tier landscape that determines which Purview controls are available to you. Our Five Microsoft 365 controls examiners will ask about before you roll out Copilot article covers the broader pre-Copilot configuration checklist that Purview DLP slots into. Our Microsoft 365 Data Loss Prevention configuration guide for financial services covers the user-side DLP work that the AI surfaces inherit from. And our recent CVE-2026-35435 article covers the agent runtime patch that Purview DLP for Foundry agents pairs with operationally.
The forward-looking question for institutions reading the May 2026 documentation refresh is straightforward. The Microsoft 365 Copilot location DLP capability is the highest-leverage starting point because the policy lives entirely in the Purview portal and produces immediate prompt-level enforcement. The Foundry surface is the most developer-flavored and benefits most from Guardian or a senior in-house engineer who can drive the PowerShell-plus-Process-Content-API configuration. The Agent 365 surface is the standard DLP playbook with one new responsibility, the agent-owner monitoring obligation. Working the three surfaces in that order produces a defensible AI governance posture inside the next FFIEC examination window.
Ready to put Microsoft Purview DLP for AI in production at your institution?
Talk to an ABT AI specialist about how Guardian configures DLP across the Microsoft 365 Copilot location, Microsoft Foundry agents, and Microsoft Agent 365 instances. We work with 750 banks, credit unions, and mortgage companies, and we built Guardian around exactly this kind of three-surface configuration question.
Talk to an Expert AI Readiness ScanFrequently Asked Questions
The Microsoft 365 Copilot location DLP is configured entirely inside the Microsoft Purview portal as a Custom-template policy. It controls whether Microsoft 365 Copilot and Copilot Chat process a prompt that contains sensitive information types, whether they use external web search when prompts contain SITs, and whether they summarize sensitivity-labeled files or emails. The Microsoft Foundry surface is configured through the New-DlpComplianceRule PowerShell cmdlet scoped to a specific Entra-registered AI app, and the policy is honored by the Foundry agent only when the agent code integrates with the Microsoft Purview Process Content API in the Microsoft Graph beta endpoint. The Copilot location is portal-driven and immediate. The Foundry surface is developer-driven and requires the agent code to honor the policy.
Microsoft 365 E5 or Microsoft 365 E5 Compliance unlocks the full Microsoft Purview DLP feature set, including the Microsoft 365 Copilot location capability and the Sensitive Information Types library that the policies depend on. The new Purview Data Security AI Admin role for least-privilege configuration is included. Microsoft Foundry DLP enforcement additionally requires pay-as-you-go billing to be enabled on the tenant for managing policies. Microsoft Agent 365 DLP works on whatever Microsoft Purview license already covers user-targeted DLP. Institutions on Microsoft 365 E3 with Purview Audit Premium add-ons can audit AI activity but cannot configure the Copilot-location DLP rule set without the E5 or E5 Compliance entitlement.
No. Microsoft Learn states this directly: DLP cannot scan the contents of files uploaded directly into a Microsoft 365 Copilot prompt. Evaluation of the uploaded file for sensitive data does not occur in the Copilot DLP location. The DLP rule only checks the text the user types into the prompt itself. Files stored in SharePoint Online or OneDrive for Business that have sensitivity labels can be excluded from response summaries through the labeled-content rule, but the prompt-upload pathway is a documented gap. Banks, credit unions, and mortgage companies should account for this in user training and in Endpoint DLP configuration on Windows devices, which can warn or block users from uploading sensitive files to AI sites at the device layer.
Microsoft documents the propagation window as up to four hours for a DLP policy change to reflect in the Microsoft 365 Copilot and Copilot Chat experience. That is the official write-time guidance from the Microsoft Learn page. Institutions running policy simulation mode should plan their review windows accordingly. The four-hour figure also applies when the institution turns a rule from simulation to enforce, which is the most consequential transition in the configuration lifecycle.
The agent does not learn that the action was blocked, does not retry, and does not route around the block. The downstream workflow simply does not run. Microsoft writes this directly: "Because an agent instance is unaware of the block action, the agent owner must actively monitor a DLP policy that uses this configuration and understand the impact to subsequent workflows." Translated for a financial institution, this means every Microsoft Agent 365 instance in production needs a documented owner who watches the DLP policy hits, traces the workflow impact, and decides whether the agent design needs to change to avoid the block scenario. The DLP rule itself is the easy part. The agent owner taking responsibility for monitoring is the part that turns the rule into a real control.
Guardian is how ABT manages Microsoft 365 tenants for more than 750 banks, credit unions, and mortgage companies. As a Tier-1 Microsoft Cloud Solution Provider, Guardian configures the Microsoft 365 Copilot location DLP policy on every customer tenant where Copilot is licensed, runs the policy in simulation mode through a defined window with the customer Compliance Office, and turns the policy to enforce after review. For institutions hosting Foundry agents under Guardian, including ABT's MortgageGuide Copilot in beta on Microsoft Azure AI Foundry, Guardian enables Purview Data Security for Foundry, configures the New-DlpComplianceRule policies scoped to each Entra-registered agent, and validates the Process Content API integration as part of the agent build pipeline. For Microsoft Agent 365 instances, Guardian adds the instance to existing DLP policies during provisioning and provides monitoring telemetry to the customer Compliance Office through the Guardian operations report.