Inline web DLP explained: the three enforcement paths

"Inline web DLP" is not one feature. It's three enforcement mechanisms that Microsoft ships under overlapping names (Browser DLP, Network DLP, Edge DLP, AI DLP), spread across 10+ Learn articles.

The three paths:

1. Edge for Business to unmanaged apps - the browser blocks paste, upload, and download to consumer AI and 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. When you pick "Edge for Business" as the enforcement point, Edge itself checks each request against the policy and blocks paste, upload, or download as it happens. Only works on Intune-managed Windows.

Covers around 20 curated AI apps (ChatGPT, Gemini, Claude, Perplexity, consumer Copilot, DeepSeek, Meta AI, Grok, Qwen, Notion AI, and more) plus cloud storage, webmail, social, and forms. 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".

MDCA reverse-proxies the app session and Edge for Business handles the in-browser controls (download, copy/paste, print, screen capture). It 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, catalog apps like Workday, ServiceNow, Salesforce, Box and Dropbox are pre-integrated with CAAC. The order to light one up:

1. Entra → Conditional Access → new session policy targeting the SaaS app. Client apps = Browser. Under Session: Use Conditional Access App Control → Use custom policy.
2. Defender portal → Settings → Cloud apps → Conditional Access App Control → Edge for Business protection. Turn on, set to Allow access only from Edge, All devices.
3. A scoped user signs into the app once in the Edge for Business work profile. That's the action that officially registers it. The app now appears under CAAC connected apps and becomes selectable as a managed app in Purview.

If your IdP is Okta, PingOne, AD FS or another non-Microsoft IdP, there's an extra step upstream. You have to integrate the IdP with Defender first by adding a SAML app in CAAC, exchanging SAML metadata and certificates, and repointing each SaaS app's sign-in URL to the Defender SAML URL so sessions route through the proxy. Microsoft's walkthrough: Onboard non-Microsoft IdP catalog apps for CAAC. Only once that SAML plumbing is in place do the three steps above apply.

Two things that catch people out: you need the Conditional Access Administrator role for the session policy, and if you want to scope the Purview policy to user groups you must import user groups under Defender → Cloud apps → User groups first, otherwise the group picker will be empty too.

Chrome and Firefox get locked out. When a block fires on the Edge path, Firefox is blocked entirely and Chrome is blocked unless you've deployed the Purview Chrome extension. There's no workaround. Tell users before you enforce, or the help desk will hear about it.

PAYG is a procurement blocker. Paths 1 and 2 need pay-as-you-go billing linked to an Azure subscription. In some organisations that takes months to approve. The toggle for these paths doesn't even appear in the wizard until PAYG is set up, so people follow the docs and wonder why they can't see the options.

Endpoint DLP mutual exclusion 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, the Edge policy silently 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.

Only Audit only or Block - no Warn, no Block-with-override. Unlike classic endpoint DLP, inline web traffic activities (text sent, file uploaded, text received, file downloaded) only offer two actions. Stage rollouts using the policy mode (simulation, then simulation with notifications, then enforce), not action levels.

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 for AI, which is a separate set of controls. Easy to get wrong.

B2B guests are excluded everywhere. If a guest pastes data into 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. It has the longest lead time and nothing else works without it. Link an Azure subscription to the tenant before you go anywhere near the wizard.

Pick paths by scenario, not by product. Blocking paste into 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 three modes, not three actions. Inline web activities only support Audit only or Block (no Warn, no Block-with-override), so the gradient is in the policy mode. Spend two weeks in simulation mode to see what would have been caught. Move to simulation with notifications so users see policy tips but nothing blocks. Only switch to enforce once those two phases are clean. It's tempting to block straight away because the business wants ChatGPT leaks stopped today - don't. False positives in a live enforcement policy destroy trust in Purview for years.