Category: Microsoft Purview

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

1. Policy: The Foundation of AI Governance
2. Blocking Generative AI with Defender for Cloud Apps and Defender for Endpoint
   1. Step 1: Sanction Allowed Applications
   2. Step 2: Create a Block Policy for the Generative AI Category
   3. Step 3: Validate Enforcement via Defender for Endpoint
3. Data Protection with Microsoft Purview
   1. Sensitivity Labels
   2. Endpoint DLP Policy
4. Conclusion

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.

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.

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.

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.

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:

1. Policy: Define which tools are allowed and under what conditions
2. 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.
3. 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.