Inline web DLP explained: the three enforcement paths

"Inline web DLP" is not one feature. It's three enforcement mechanisms stitched across different Microsoft products - Purview DLP for Cloud Apps in Edge for Business, Network Data Security, and Conditional Access App Control - spread across 10+ Learn articles.

Why not just use Endpoint DLP? Endpoint watches what happens on the device (clipboard paste, file save, USB, print). If a user types sensitive info straight into ChatGPT, Endpoint never sees it - no clipboard event to catch. It also doesn't cover unmanaged devices at all. Inline inspects the HTTP request as it leaves the browser, so it catches typed content and works on unmanaged devices too. Use both together.

The three paths:

1. Edge for Business to unmanaged apps - the browser blocks text sent, files uploaded, and files downloaded when the destination is a consumer AI site or unsanctioned cloud storage.
2. Network Data Security - a SASE proxy inspects traffic across any browser or OS.
3. Edge for Business to managed apps - in-browser controls for Entra-connected SaaS like Workday and ServiceNow.

Paths 1 and 2 live under a section called Inline web traffic in the Purview portal. Path 3 lives under Enterprise apps and Devices, even though it's also enforced in the browser. The split depends on whether the target app is Entra-connected, not on where enforcement actually runs. That's where most people get lost in the policy wizard.

The path most teams start with. Edge for Business v144+ has the Purview DLP engine built in. Pick Edge for Business as the enforcement point in the wizard, and the browser inspects every text submission or file upload to a target site and blocks it in flight. The trigger is the network submission, not the clipboard paste - that's Endpoint DLP's job. Only works on Intune-managed Windows.

Covers 21 curated AI apps (ChatGPT consumer, Gemini, Perplexity, consumer Copilot, DeepSeek, Meta AI, Grok, QwenAI, Notion AI, Otter.ai, Adobe Firefly, Cohere, DeepL and others) plus cloud storage, webmail, social, and forms. Claude is not on the list. You need E5, PAYG billing, and the policy creator holding Intune Admin + Edge Admin roles. Billed per request to unmanaged apps.

The Edge path only covers Edge. Anyone on Firefox, Chrome, Safari, or a native desktop app walks straight past it. Network Data Security solves that by doing the inspection at your SASE proxy (Zscaler, Netskope, Palo Alto, Island, Menlo, or Entra Global Secure Access). Your SASE sends decrypted traffic to Purview through the Security Store, and the policy enforces regardless of which browser or OS the user is on.

Microsoft's own GSA option is file-only and still in preview, so if you want prompt or text inspection you need a third-party partner. You need E5, PAYG, and a SASE contract in place. Billed per request.

The Edge-vs-Network choice is one dropdown. In the wizard, paths 1 and 2 look 90% identical - same template, same location, same conditions. The only meaningful difference is the `Choose where to enforce` toggle: `Edge for Business` or `Network and non-Microsoft secure browsers`. Pick the wrong one and you're on a completely different path with different licensing.

The path that trips people up because it lives in a different section of the portal. Blocking a download from Workday to a personal laptop is not an "Inline web traffic" policy. It's an "Enterprise apps and Devices" policy under "Managed cloud apps".

Edge for Business handles the in-browser controls directly (download, in-browser copy/paste between tabs, print, screen capture). Sessions that can't use in-browser protection fall back to the MDCA reverse proxy - same enforcement, different mechanism. Works on both managed and unmanaged devices, as long as the user is signed into the Edge work profile. Apps covered are Entra-connected SaaS: Workday, ServiceNow, Salesforce, SAP SuccessFactors, Atlassian, custom apps.

Included in E5, no PAYG. It's the only inline path that isn't billed per request. In exchange there's more to set up than the other two.

The "managed apps" list stays empty until you onboard the app. Purview reads managed apps from Conditional Access App Control (CAAC) in Defender - it doesn't create them. Open the DLP wizard before CAAC knows about the app and the only option is "unmanaged". That's where most people get stuck.

For Entra ID tenants, apps like Workday, ServiceNow, Salesforce, Box and Dropbox are already on CAAC's pre-onboarded list. You still need to switch the plumbing on and do a first sign-in before they show up in Purview.

First, check SSO is set up for the app. Entra → Enterprise applications → the app → Single sign-on (SAML or OpenID Connect). If SSO isn't configured, nothing below will work.

2. Turn on Edge for Business protection. Open security.microsoft.com/cloudapps/settings?tabid=edgeIntegration. Set On, Allow access only from Edge, All devices. Save.

3. Sign into the app in the Edge work profile as a user from step 1. Must be the work profile - personal Edge, InPrivate, Chrome, or another tenant won't register anything.

4. Check it's onboarded. Defender → Settings → Cloud apps → Connected apps → Conditional Access App Control apps. The app should show as Connected. If it says Continue Setup or isn't there, step 1 didn't route the session - recheck it.

5. Build the Purview policy. Purview → Data loss prevention → + Create policy → Enterprise apps and Devices → Managed cloud apps → pick the app. Microsoft's full walkthrough with a Workday example: Prevent users from sharing sensitive info with cloud apps in Edge for Business.

Non-Microsoft IdPs (Okta, PingOne, AD FS) need a SAML integration step with Defender first. Microsoft's walkthrough: Onboard non-Microsoft IdP catalog apps for CAAC. After that, the 5 steps above still apply.

In-browser protection is in preview, only on the latest two stable Edge versions (Windows 10/11 or macOS). Everything else (Chrome, Firefox, Safari, Edge on Android, InPrivate, B2B guests) falls back to the MCAS reverse proxy - still enforces, but users see a `.mcas.ms` URL. Full list.

Two gotchas: you need the Conditional Access Administrator role for step 1, and if you want to scope the Purview policy to groups you have to import them first under Defender → Cloud apps → User groups. Otherwise the group picker is empty too.

Path 1 blocks Chrome and Firefox at the device level. When a Path 1 policy is set to block, Firefox is blocked entirely and Chrome is blocked unless you've deployed the Purview Chrome extension. Tell users before you switch to enforce, or the help desk will hear about it. (Path 3 is different - non-Edge users fall back to the MCAS reverse proxy and still get enforcement.)

Endpoint DLP wins on managed apps. For path 3 specifically (Edge protecting Workday, ServiceNow, and other Entra-connected apps), if the user is also in scope for an endpoint DLP policy or an MDCA session policy targeting the same app and action, Endpoint takes precedence and the Edge policy does nothing. Purview won't warn you. Exclude those users from the overlapping policies, or your path 3 policy will pass testing and fail in production.

Enterprise Copilot isn't covered. The Edge path only covers consumer Copilot (the free chat on copilot.microsoft.com). Enterprise M365 Copilot is governed by DSPM, which is a separate set of controls. Easy to get wrong.

B2B guests are excluded everywhere. If a guest sends data to ChatGPT through your tenant, you can't see it or block it. If you have a lot of guest users you'll need a different control for them.

Get PAYG approved first. Paths 1 and 2 need pay-as-you-go billing linked to an Azure subscription. Procurement can take months, and the `Choose where to enforce` toggle doesn't even appear in the Purview wizard until PAYG is live - so if you skip this step, you'll follow the docs and wonder why half the options aren't there. Link an Azure subscription before going anywhere near the wizard.

Pick paths by scenario, not by product. Blocking sensitive text sent to ChatGPT is path 1 or 2. Protecting Workday downloads on personal devices is path 3. Each scenario fits one path - the Inline Web DLP Planner will work it out for you before you start clicking around in Purview.

Stage the rollout in simulation, not fake actions. Inline web activities only support Audit only or Block (no Warn, no Block-with-override), and the policy mode is just Simulation, On, or Off. Spend at least two weeks with your Block actions configured and the policy in Simulation mode - no user-visible change, but Activity Explorer shows exactly what would be blocked. Once false positives are in single digits, flip the policy to On. It's tempting to turn On immediately because the business wants ChatGPT leaks stopped today - don't. False positives in a live policy destroy trust in Purview for years.