Edge for Business, Chrome work profiles and the Microsoft Compliance Extension

What Edge for Business and a work profile actually are

Start by deflating a piece of jargon. 'Edge for Business' is not a separate browser you download instead of Edge. It is Microsoft Edge running under a work profile: the profile that is signed in with the organisation's Entra identity and that carries the organisation's policy and managed extensions. The same installed Edge holds the user's personal profile alongside it, and the two share nothing, exactly as Chapter 18 described for browser profiles in general. A work profile is the product instantiation of that generic profile. Google Chrome has the equivalent under Chrome Enterprise, where a managed work profile carries the organisation's policy separately from the user's personal Chrome.

The property that carries over from Chapter 18 is the one that matters: policy attaches to the profile, not to the human being. The organisation does not configure the person; it configures a profile, and its controls exist when, and only when, the AI site is loaded in that profile. So the instruction that will recur throughout this chapter, 'sign into the work profile', is not housekeeping. It is the precondition for every control described here. A staff member who is not in the work profile is, as far as these controls are concerned, not being watched at all.

Inline AI prompt protection: the control that needs no onboarding

The first feature is the one that reaches a personal device, and it is worth quoting Microsoft precisely, because the precision is the point. Microsoft's documentation states that Purview data-loss-prevention monitoring and protection are built into the Microsoft Edge for Business browser, without needing to onboard the device into Microsoft Purview (high).

Chapter 18 already explained why this is possible, and the explanation is worth restating now that the product has a name. The protection is the browser's own built-in data-loss prevention, running inside Edge's trusted view of the page, in the renderer where the prompt text lives. It reads the typed prompt before TLS encrypts anything for the network, and it does so without any privileged agent sitting below the browser in the operating system. Because nothing has to be installed on the privileged side of the device, nothing has to be onboarded. The browser is doing the watching, and on a personal device the user has put the browser there themselves by signing into the work profile.

What it does, concretely, is audit or block a typed prompt that contains sensitive information types when the user submits it to a defined set of consumer AI sites. Microsoft names ChatGPT, Google Gemini and DeepSeek among the targets, and the capability reached general availability across the middle and later part of 2025 (high; the supported-site list and rollout dates are product specifics that drift, so treat the exact list as something to confirm against current documentation). The dependency is light: the policy flows to the browser through the Microsoft Edge management service and is activated by the user being signed into the work profile. It does not require the device to be enrolled in Intune, and it does not require mobile-application-management enrolment. Sign into the work profile and the control is live.

Browser DLP for managed apps on unmanaged devices, and why it is a different feature

The second feature is the one most often mistaken for the first, and keeping them apart is the single most useful thing this chapter can give a defender. Microsoft's documentation is again exact: Edge for Business applies data-loss-prevention policies for unmanaged devices only to the work profile, and these policies do not apply when the user chooses a personal or InPrivate profile; to target managed apps on unmanaged devices, the work profile must be enforced (high).

This is a broader capability than the inline-prompt feature. Where inline AI prompt protection is specifically about reading the text submitted to consumer AI sites, the managed-apps browser DLP governs the wider range of actions a user takes against organisation-managed cloud apps reached through the browser: uploads, downloads, copying and the like. It is also the feature with the licensing wrinkle, and the wrinkle is real enough that a defender who ignores it will make a promise they cannot keep. Inline AI prompt blocking to consumer AI sites is included in the standard Microsoft 365 E5 entitlement. The broader data-security controls for managed apps on unmanaged Windows and macOS devices are structured as a pay-as-you-go Purview capability, sitting on top of the standard entitlement that already covers managed devices (medium; Microsoft has moved this licensing more than once during 2025, the specific Australian and A5 position is not always clear in the documentation, and it should be verified against current licensing guidance and the tenant billing portal before anything is promised).

The practical instruction is to ask, of any specific capability someone claims Edge for Business provides on a personal device, a single disambiguating question: is this the inline AI prompt feature that is included in E5, or the broader managed-apps-on-unmanaged-devices feature that is pay-as-you-go? The two get described in the same breath and they are not the same thing, and the difference shows up on an invoice.

One detail from the documentation deserves a defender's attention because it explains why the control is harder to circumvent than the architecture alone would suggest. When an administrator saves the first policy targeting unmanaged apps in Edge for Business, the Microsoft Edge management service automatically creates the Edge configuration policies and the supporting Intune policies needed to activate the policy in the browser and to prevent its circumvention (high). The point is that Microsoft has done some of the work of pinning the user into the work profile on the organisation's behalf, rather than leaving it entirely to be assembled by hand.

The Microsoft Compliance Extension: the control that does need onboarding

The third feature is the contrast that makes the whole posture make sense, and it concerns the other browsers. The Microsoft Purview browser extension, commonly called the Microsoft Compliance Extension, brings data-loss-prevention visibility and enforcement into Google Chrome and Mozilla Firefox: sensitive-information detection on uploads and pastes, and the Insider Risk Management browser signals that feed Microsoft's risk engine. In the Edge story the protection is built into the browser; in the Chrome and Firefox story it is bolted on as an extension.

And here is the decisive difference, again in Microsoft's own words: to use the Microsoft Purview extension for Chrome, the device must be onboarded into Endpoint data-loss prevention (high). The reason is architectural, and Chapter 18 set it up. The extension is a content-script-based front end, running in the page like any extension, but its detection engine is the local Endpoint DLP service, which lives below the browser in the operating system and exists only on an onboarded device. The extension is the eyes; the brain is the onboarded endpoint. So even if a user on a personal device installs the Compliance Extension by hand from the web store, it does nothing useful, because the device has no Purview device identity and no DLP engine for the extension to report to. The extension is also Windows-only, supported on Windows 10 and 11, and is not used on macOS at all, which is the fact Chapter 16 stated from the Mac's side and can now be explained from this one: on macOS the Endpoint DLP path uses Defender hooks in supported browsers rather than this extension.

This is the asymmetry that drives Microsoft's recommended posture for personal devices. The Edge built-in inline control needs no onboarding; the Chrome and Firefox extension does. On a managed device both paths are available, because the device is onboarded. On an unmanaged personal device only the Edge path survives, because there is nothing onboarded for the extension's engine to live in. That single asymmetry is why 'route AI access through Edge for Business' is the answer Microsoft gives for bring-your-own-device, and why a defender who understands it stops treating the four feature names as interchangeable.

Answering the privacy officer

Now the opening question can be answered in the sentence the architect could not assemble. Take the staff member on a personal laptop and walk it across their choices.

In an Edge for Business work profile, inline AI prompt protection applies, and a policy targeting the relevant information types can block the patient-data paste into ChatGPT at the moment of submission (high). In Edge's personal profile, or an InPrivate window, it does not apply, because the policy is bound to the work profile (high). In Chrome, Firefox or Safari on that same personal laptop, nothing applies: the Compliance Extension needs an onboarding the personal device does not have, and the Edge built-in control is, by definition, Edge's (high). So the precise answer to 'can we stop them' is this: yes, if and only if they submit from an Edge for Business work profile, for a supported AI site, under a policy that targets the information types in question; otherwise no. That is the sentence the privacy officer can act on, and assembling it required keeping the three features distinct.

Everything turns on the user being in the work profile, which is Chapter 18's profile-is-the-linchpin point in Microsoft dress. The control is real exactly to the extent the organisation can ensure the AI site is reached in the work profile and nowhere else, and Microsoft's documentation is candid that a user can defeat it by switching to a personal profile, an InPrivate window, or another browser. Its recommended reinforcement is Conditional Access: a policy that blocks other browsers from reaching Microsoft 365 unless the user is in an Edge work profile. It is worth being honest about what that buys, because Chapter 12 already established the limit. Conditional Access governs authentication to the organisation's own services. It can require the work profile as a condition of reaching corporate resources, which raises the bar and makes the work profile the path of least resistance for someone who needs those resources anyway. It does not stop a determined user opening Chrome and going to ChatGPT outside any work session, because free browsing to a consumer site is not an authentication to the organisation that Conditional Access can intercept. The reinforcement shifts the bar; it does not close the gap.

On a corporate standard operating environment the picture inverts, and it inverts in a way worth naming precisely. There, every surface stacks: Edge inline DLP, the broader Edge browser DLP, the Compliance Extension in Chrome and Firefox because the device is now onboarded, Endpoint DLP, and the sensitivity-label and upload controls. The native Edge integration is the strongest single surface, but the deeper point is that onboarding unlocks the Chrome and Firefox path that the personal device could never have. A managed device is not 'a personal device plus a little more'. It is a categorically wider control surface, and the line between the two is the enrolment ladder that Chapter 20 sets out in full.

One layer remains to be placed, so that a reader does not mistake it for a prerequisite. Windows App Protection Policy targeting Edge, the Windows form of mobile-application management, is a separate and additional Intune feature. It adds controls such as clipboard restriction across the work profile, watermarking, conditional launch and threat-level checks, and on Windows it targets only Microsoft Edge; there is no Windows app-protection policy for the Outlook, Word or Teams desktop applications (high). It is a hardening layer on top of the work-profile control, not a condition of it. The inline DLP described above works without it. A defender should keep the two separate, so as not to believe the BYOD control requires an enrolment it does not.

The reason Edge for Business is the linchpin, then, is the architecture of Chapter 18 plus one product decision. Architecturally, a control built into the browser sees the prompt before TLS without needing the privileged operating-system layer that only a managed device grants. Microsoft's decision was to ship that built-in inline control with no onboarding gate, while leaving the Chrome and Firefox extension dependent on the onboarded Endpoint DLP engine. The first half is why any browser-resident control can reach a personal device. The second half is why, in a Microsoft shop specifically, the surviving personal-device control is Edge.

Last updated 9 August 2026