Endpoint DLP blocks sensitive uploads and pastes to AI websites

Over the past while I've watched the risk around AI websites go from theoretical to urgent in a lot of client environments. Users emailing data out is one problem. Someone pasting source code, sensitive contracts or confidential notes into ChatGPT, Claude or Gemini is a different one. Traditional DLP solutions either don't see browser actions at all or only look at sanctioned cloud apps, and that falls short when an AI portal is one click away. Purview Endpoint DLP for AI websites fills that gap and gives admins the control they need at the device level.

Endpoint DLP targets AI websites by domain

Microsoft Purview Endpoint DLP doesn't just monitor the browser in general. It lets you control sensitive data that gets pasted or uploaded to specific domains, such as chat.openai.com or claude.ai. This happens through the Browser and domain restrictions feature in the Endpoint DLP settings (Purview portal → Data loss prevention → Settings → Endpoint DLP settings). In that section you activate and edit the sensitive service domain groups, which now ship with a prebuilt set of major AI platforms. Keep that list up to date. New AI services show up constantly, and shadow AI is a real risk (How shadow AI is detected with Defender for Cloud Apps).

These protections only apply to onboarded Windows 10 or 11 devices running Microsoft Defender for Endpoint. Edge is supported natively. Chrome needs the Purview extension, deployed and locked down, because without it DLP enforcement doesn't work. More than once I've seen companies assume their Chrome users were covered, only to find out the extension was missing or users could remove it themselves.

DLP policies stop paste and upload actions on AI websites

Most of the work happens in the DLP policy configuration. You define which information types or sensitivity labels you want to protect and choose "Paste to browser" or "Upload to browser" as actions. That covers the classic copy-paste leak as well as file uploads to AI chatbots and portals. A policy can run in "Block with override" mode, where users can justify an exception, or in "Audit only" mode, which just monitors. My advice is to start with audit so you understand how people actually work, and then move to block-with-override. You collect data and build awareness first, and you don't break urgent workflows or lose visibility along the way.

Practical tip: Look at the audit events in the Purview portal on a regular basis. You'll often find sensitive material (HR files or client documents, for example) being pasted into AI portals well before users realise it's a problem. An awareness campaign early on does a lot of good before you switch on a hard block.

What users see depends on the browser. In Edge, they get immediate feedback with clear prompts when a DLP event fires. Chrome depends entirely on the Purview extension. You have to deploy it via Intune or GPO and stop users from removing it, otherwise your Chrome devices are invisible to DLP.

Each policy action fits a different level of risk

Based on your risk and business requirements, you pick one of these DLP actions:

• Audit only: Log the event, allow the user to continue
• Block: Fully block the action, no exceptions
• Block with override: Block but allow justified overrides (every override is logged)

For AI websites I usually recommend block-with-override. Legitimate business needs get documented, and you're not leaving the door wide open. Audit-only is a good way to gauge the impact before you tighten enforcement.

Domain lists need ongoing governance tied to shadow AI discovery

Managing the domains is harder than it sounds, because the number of AI sites keeps growing. Microsoft maintains a sensitive service domain group, but you should check it and add to it based on your current shadow AI discovery results (see DSPM for AI: Visibility and monitoring). Many companies run this as a continuous process and use Defender for Cloud Apps or DSPM to spot new risks and adjust DLP accordingly.

The diagram below shows how the components fit together in terms of data flow and enforcement:

flowchart TD
  User["User (Windows 10/11)"] --> Browser["Browser (Edge/Chrome)"]
  Browser --> AIWeb["AI website (e.g. chat.openai.com)"]
  Browser --> PurviewAgent["Endpoint DLP agent"]
  PurviewAgent --> Policy["Purview DLP policy"]
  Policy -->|"Audit/Block/Override"| Action["Action (block/log)"]

Figure: Endpoint DLP data flow for AI website access

Chrome needs more care than Edge

In most organisations I work with, Edge and Chrome are both in use, and for Endpoint DLP that matters. Edge support is built in. Chrome needs the Purview extension, which is normally deployed with Intune or GPO and protected against removal. Skip that step and Chrome turns into a blind spot where users can get around DLP and paste or upload sensitive data without detection. You only get full coverage if extension removal is blocked.

You'll find the details in Microsoft's documentation: Endpoint DLP overview and Configure endpoint settings.

I consider Endpoint DLP for AI websites essential in 2026

If you're not yet controlling access to AI websites, you're putting sensitive data at risk for no good reason. In my view, Endpoint DLP is the most effective way to monitor and block clipboard pastes and file uploads to AI sites across your Windows devices. Getting the balance between audit, block and override right is as much a governance question as a technical one. Keep the domain groups current, check the audit events regularly and pay attention to how the browsers are deployed. That's what actually keeps shadow AI in check without bringing productivity to a standstill.