Microsoft Purview – Microsoft Security Blog

Microsoft Purview vs. Defender for Cloud Apps: Preventing vs. Correcting Data Exposure

A finance employee applies a Confidential label to a spreadsheet, works on it for a few days, and then shares it with an external consultant through a link in Teams. Depending on how the tenant is configured, that share attempt is either stopped in real time, or it goes through completely unnoticed until someone reviews it weeks later. Which of those two outcomes happens depends entirely on which Microsoft security tool is doing the watching, and at what point in the document’s lifecycle it gets involved.

This is exactly where Microsoft Purview and Microsoft Defender for Cloud Apps get confused as doing “the same thing” for data protection. They do not. One prevents an action before it happens. The other cleans up after data has already moved. In this post, I will walk through both sides with concrete policy examples, and explain why most mature environments end up running both rather than picking one over the other.

Table of Contents

Disclaimer: This blog post is provided for informational purposes only. While every effort has been made to ensure accuracy, implementation of these features should be performed by qualified administrators in accordance with your organization’s security and change management policies. The author is not responsible for any issues, data loss, or security incidents that may occur from following this guidance. Always test in a non-production environment first and consult official Microsoft documentation before implementing security features in production.

Two Different Moments of Control

A question I get regularly: “We have Microsoft Purview, so why do we also need Defender for Cloud Apps for data protection?” The short answer is that they intervene at two different moments in a document’s lifecycle. Purview prevents sensitive data from going down the wrong path in the first place. Defender for Cloud Apps cleans up what has already been shared. Neither one replaces the other; they cover different gaps.

Microsoft Purview DLP: Blocking Data After Classification

Microsoft Purview Data Loss Prevention (DLP) intervenes at the moment a user tries to do something with a document: sending it by email, uploading it to a cloud app, pasting it into a browser, or sharing it outside the organization.

That intervention depends entirely on classification. Before a DLP rule can block anything, Purview first needs to know that a document is sensitive. This is done through:

Sensitive information types (SITs): pattern-based detection such as credit card numbers, national identification numbers, or customer IDs
Sensitivity labels: applied manually by users or automatically based on content, for example Confidential or Internal
Trainable classifiers: machine-learning-based recognition of content types such as contracts or financial statements

Once content is classified as sensitive, a DLP policy can act on it. A common example: a user tries to share a document labeled Confidential with someone outside the organization. The DLP policy recognizes the label and the action is immediate: block, optionally with a business justification override, or block without that option. Every attempt is logged in Activity Explorer, so you can see exactly who tried what and whether the policy intervened.

Image 1: Microsoft Purview DLP rule with a Confidential sensitivity label condition and a block action set to restrict access for people outside the organization

The strength of this approach is that it is preventive, and it applies across the locations Purview has visibility into: endpoints, email, Teams chats, SharePoint/OneDrive, and even prompts sent to Microsoft 365 Copilot and external generative AI tools.

Microsoft Defender for Cloud Apps: Revoking Access on Already-Shared Files

Where Purview DLP is about preventing an action, Defender for Cloud Apps is about correcting a situation that already exists. Think of a document that was shared externally before a label was ever applied, or a file that ended up in a cloud app outside your visibility through a route DLP never inspected.

With a file policy in Defender for Cloud Apps, you can continuously scan for files matching specific conditions, for example an access level of External or Public combined with a sensitivity label or a sensitive information type detected through the Data Classification Service. Once a file matches those conditions, automated governance actions can follow, including:

Remove external users: removes all collaborators outside the internal domains configured in your settings
Remove public access / remove direct shared link: revokes a shared link or restricts access to named collaborators
Make private: removes all shares, leaving access to site administrators only
Remove a collaborator: revokes access for one specific person without affecting the rest

Image 2: Defender for Cloud Apps file policy filtering on External or Public access level and a Confidential sensitivity label, with the Remove external users governance action enabled

This works across connected apps such as SharePoint, OneDrive, Google Workspace, and Box, which makes it particularly valuable as a backstop for content that was already shared before it was classified, or for gaps that fall outside Purview DLP’s preventive reach.

Why You Need Both

Microsoft Purview DLP intervenes before or during the action (preventive), triggered by classification detected during an activity, typically blocking sharing, copying, pasting, or uploading, across endpoints, email, Teams, SharePoint/OneDrive, Copilot, and browsers.

Microsoft Defender for Cloud Apps intervenes after the action, on data at rest (corrective), triggered by a continuous scan of files against conditions such as access level and label, typically revoking permissions, undoing sharing, or quarantining/making files private, across connected cloud apps such as SharePoint, OneDrive, Google Workspace, and Box.

This is where the combination earns its value. Purview DLP prevents a large share of risky actions from happening at all. But no preventive layer is airtight: files shared before a label was applied, or content that leaked out through an unmanaged path, will slip through. Defender for Cloud Apps acts as the safety net, continuously scanning what is already out there and revoking access the moment it should not have been granted.

Conclusion

Data protection is not a single control, it is a layered model:

Classify first: sensitivity labels and sensitive information types are the foundation both solutions depend on. Neither Purview DLP nor Defender for Cloud Apps has anything to act on without classification.
Microsoft Purview DLP: prevents risky actions on sensitive content at the moment they happen, across endpoints, email, Teams, and browsers.
Microsoft Defender for Cloud Apps: continuously scans already-shared content in connected cloud apps and revokes access when it violates policy.

Prevent where you can, correct where you must. Together, these two layers close the gap that either one would leave open on its own.

Blocking Generative AI with Microsoft Defender for Cloud Apps and Microsoft Defender for Endpoint

Employees are using generative AI tools every day, often without IT or security teams knowing about it. Tools like ChatGPT, Gemini, Deepseek, and dozens of others are freely accessible from any browser on any managed device. While these tools can be productive, they also represent a significant data governance risk. Sensitive information can leave the organization the moment it is pasted into a prompt.

Blocking generative AI is not about being anti-innovation. It is about making a deliberate, governed choice about which tools are trusted, how they handle your data, and what controls exist when they are used. In this blog post, I will walk through a layered approach to governing generative AI in your organization using Microsoft Defender for Cloud Apps, Microsoft Defender for Endpoint, and Microsoft Purview.

Table of Contents

Disclaimer: This blog post is provided for informational purposes only. While every effort has been made to ensure accuracy, implementation of these features should be performed by qualified administrators in accordance with your organization’s security and change management policies. The author is not responsible for any issues, data loss, or security incidents that may occur from following this guidance. Always test in a non-production environment first and consult official Microsoft documentation before implementing security features in production.

Policy: The Foundation of AI Governance

Policy comes before technical controls. Policy determines what is and what is not permitted within an organization, and is the foundation for staying in control of company data. Without a policy, any technical control you implement lacks a foundation. You cannot enforce a rule you have not defined.

Examples of questions that an AI usage policy should address:

Which generative AI tools are sanctioned for use by the organization?
Are there restrictions on what data can be used in those tools?
What happens when an employee uses an unsanctioned tool?

For the purpose of this blog post, I will use the following example policy:

Tool	Status	Rationale
Microsoft 365 Copilot	✅ Allowed	Integrated with the Microsoft 365 data boundary, governed by tenant controls
Claude (Anthropic)	✅ Allowed	Approved for specific use cases via organizational account
All other generative AI tools	❌ Blocked	Unsanctioned, unmanaged, and outside the organization’s data governance framework

This distinction is important. Microsoft Copilot operates within your Microsoft 365 tenant and is subject to the same compliance and data residency controls as the rest of your Microsoft 365 environment. Claude, when accessed via an approved organizational account, can be governed and audited. All other generative AI tools, unless explicitly evaluated and approved, operate outside of your organization’s governance and data protection framework.

Documenting this in a policy gives you the basis to enforce controls technically and to communicate expectations clearly to your employees.

Blocking Generative AI with Microsoft Defender for Cloud Apps and Microsoft Defender for Endpoint

With a policy in place, the next step is enforcement. Microsoft Defender for Cloud Apps (MDA) allows you to discover, classify, and govern cloud application usage across your organization. One of the built-in application categories in MDA is Generative AI, which automatically groups over 1200 known generative AI services like ChatGPT, Gemini, Deepseek, and many others, a list that keeps growing.

The enforcement mechanism on managed endpoints is provided by Microsoft Defender for Endpoint (MDE). When MDE is deployed on a device, it enforces blocking via Network Protection, which operates at the network level. This means that access to unsanctioned generative AI tools is blocked regardless of how the request is made, whether through a browser, PowerShell, or any other HTTP client, without requiring an additional proxy or agent. This integration is one of the reasons this approach is practical for most organizations that are already using Microsoft Defender for Endpoint.

Step 1: Sanction Allowed Applications

Before creating a block policy, mark the applications that are explicitly allowed as Sanctioned in the Microsoft Defender for Cloud Apps app catalog. This ensures they are excluded from any block policy you create.

Location: Microsoft Defender Portal > Cloud Apps > Cloud app catalog

Search for Microsoft Copilot and Claude and set their tag to Sanctioned.

Image 1: The Cloud App Catalog in Microsoft Defender for Cloud Apps, filtered on the Generative AI category showing Sanctioned apps including Microsoft Copilot and Anthropic Claude.

Step 2: Create a Block Policy for the Generative AI Category

Navigate to the Cloud Apps policies section and create a new App discovery policy.

Location: Microsoft Defender Portal > Cloud Apps > Policies > Policy Management > Create Policy > App discovery policy

Configure the policy as follows:

Policy name: Block Unsanctioned Generative AI
Category filter: Generative AI
Action: Tag app as Unsanctioned

This policy targets the entire Generative AI category while excluding the applications you have explicitly sanctioned in the previous step.

Image 2: Creating an App Discovery Policy in Microsoft Defender for Cloud Apps targeting the Generative AI category with the governance action to tag apps as Unsanctioned.

Step 3: Validate Enforcement via Microsoft Defender for Endpoint

Once an app is tagged as Unsanctioned, Microsoft Defender for Endpoint enforces the block via Network Protection on managed devices. When a user attempts to access a blocked generative AI service, the connection is blocked at the network level and the user sees a notification that the site is blocked by their organization.

Image 3: Microsoft Defender for Endpoint blocking access to deepseek.com

You can review blocked access attempts in the Microsoft Defender for Cloud Apps activity log and in the Microsoft Defender for Endpoint device timeline, giving you full visibility into which users attempted to access which tools and when.

Data Protection with Microsoft Purview

Blocking unsanctioned tools addresses the governance problem at the application level. But what about data being used in the tools that are allowed? Even within sanctioned tools, not all data should be treated equally.

Consider the following scenario: a user has a document classified as Confidential containing financial projections or personal data. Within Microsoft Copilot, this is acceptable because Copilot operates inside your Microsoft 365 tenant boundary. The data does not leave your environment. However, if that same user copies the content and pastes it into Claude, the data is now being sent to an external third-party service, even if Claude is an approved tool.

Microsoft Purview allows you to create controls that distinguish between these scenarios at the data level.

Sensitivity Labels

Microsoft Purview Information Protection uses sensitivity labels to classify content. Labels can be applied manually by users or automatically based on content inspection. Common examples include:

Public: No restrictions
Internal: For internal use only
Confidential: Sensitive data, restricted sharing
Highly Confidential: Strictly limited access

When a document or piece of content carries a sensitivity label, that label travels with the content and can be used to enforce policy wherever the content goes.

Note: This assumes sensitivity labels are already configured and published in your organization.

Endpoint DLP Policy

Microsoft Purview Data Loss Prevention (DLP) allows you to create policies that detect when labeled content is being handled in a way that violates your policy, such as being pasted into a browser-based application.

Location: Microsoft Purview Portal > Solutions > Data loss prevention > Policies > Create policy > Enterprise applications & devices

For the scenario described above, you create a custom Endpoint DLP policy with the following logic:

Condition: Content contains a sensitivity label of Confidential or Highly Confidential
Action: Audit or restrict activities on devices
- Enable Upload to a restricted cloud service domain or access from an unallowed browsers > Block
- Click Choose different restrictions for sensitive service domains > add Claude AI domain group > Block
- Copilot is not added to the sensitive service domain group and is therefore not restricted

This means a user can work with Confidential content in Microsoft Copilot without restriction, but will be blocked from pasting that same content into Claude.

Image 4: Microsoft Copilot successfully reading the Mario_Internal_Secrets document and responding to the question “How do I warp to world 8?”, demonstrating that Confidential content is accessible within the Microsoft 365 boundary.

Image 5: Microsoft Purview blocking the upload of the Mario_Internal_Secrets document to Claude, “Your organization prevents you from uploading the file to this location. To protect the sensitive info in this file, your organization prevents you from uploading it to unapproved locations.”

The DLP policy generates an alert in the Microsoft Purview compliance portal and can be configured to notify the user, notify an administrator, or require the user to provide a business justification before overriding the block, depending on your organization’s risk tolerance.

This creates a data-aware enforcement layer on top of the application-level controls you configured in Microsoft Defender for Cloud Apps. Even for approved tools, sensitive data is protected.

Conclusion

Generative AI is not going away. Employees will continue to look for ways to use these tools, and many of those tools are genuinely useful. The goal is not to block everything, but to make deliberate choices about which tools are trusted, enforce those choices technically, and add a data protection layer to ensure sensitive information does not end up where it should not be.

The approach described in this blog post follows a three-layer model:

Policy: Define which tools are allowed and under what conditions
Microsoft Defender for Cloud Apps + Microsoft Defender for Endpoint: Tag unsanctioned generative AI tools in the Microsoft Defender for Cloud Apps catalog. Microsoft Defender for Endpoint enforces the block via Network Protection.
Microsoft Purview DLP: Enforce data-level controls so that sensitive content cannot be used in external tools, even when those tools are technically allowed.

Each layer addresses a different risk. Together, they give you a practical and enforceable governance framework for generative AI that does not require you to choose between productivity and security.

Start with policy. Enforce at the app level. Protect at the data level.