Island described the integration in a June 3, 2026 announcement, and its Microsoft Marketplace listing explicitly identifies the offering as a preview. That earlier announcement is important context: this is an integration to evaluate against a future general-availability milestone, rather than a newly available production feature that administrators should assume appeared on September 21. The practical case rests on how browser inspection connects to Purview policies, which identities those policies cover, and what organizations must configure and pay for.
Microsoft Purview brings Island browser activity into its policy system
The integration targets data shared with unmanaged cloud applications: destinations that an organization wants to monitor or restrict through Purview, even when it does not administer the destination application itself. Microsoft’s Network Data Security documentation identifies interactions such as AI prompts, cloud-storage uploads, webmail, online forms, and social-media posts. Island supplies a browser-based route into that system.
Island’s contribution is visibility at the browser’s presentation layer, where users enter and interact with information. Its announced scope includes typed and pasted input, file uploads and downloads, extension activity, and AI interactions. That makes the integration relevant to a user entering sensitive text directly into a web application, as well as someone transferring a document. These are vendor-described capabilities, not results from an independent WindowsForum test.
The documented before-and-after is specific. Island says browser-layer enforcement already existed in its product; the integration connects that enforcement to Purview’s classifiers, sensitive information types, sensitivity labels, and policy infrastructure. Organizations using both products can therefore evaluate browser activity through their Purview data-protection framework instead of treating it as an entirely separate classification project.
That reuse should not be mistaken for automatic deployment. Microsoft’s architecture requires administrators to establish the integration and configure collection or data loss prevention policies defining the relevant applications, activities, and conditions. An organization’s existing sensitive-information definitions provide a starting point, but the network policies still need a deliberate scope.
For a Windows administrator, the distinction is operationally useful: the change concerns the Island browser workflow connected to Purview. Neither the roadmap’s “Web” platform designation nor the integration announcement establishes universal coverage for Windows applications or traffic outside that workflow. The submitted scope is Worldwide Standard Multi-Tenant, rather than a promise of availability across every Microsoft cloud environment.
The Island preview needs a calendar, not a launch assumption
The roadmap information places preview availability in March 2026 and general availability in June 2027, while retaining an “In development” status. As of September 22, 2026, March is already in the past and June 2027 remains in the future. Those fields describe different release stages; a past preview date does not establish that the integration has reached general availability.
There is also a timing discrepancy in public copies of the announcement. Older roadmap reproductions retain a June 2026 general-availability target. A public archive of Microsoft Message Center notice MC1249424 records a September 18, 2026 timeline update and now gives June 2027. These reproductions are copies of Microsoft communications, not independent confirmation of deployment, and the older June 2026 date should not be used to declare the feature generally available.
Island’s Marketplace listing provides a more direct status signal: its product name includes “Preview.” Combined with Island’s June announcement, that supports treating the integration as an existing preview offering with a later production milestone, rather than treating the March preview date as merely an unexplained historical entry. It does not establish access for every tenant.
Microsoft also describes roadmap dates and feature descriptions as estimates subject to change. Organizations can use June 2027 for planning, but procurement commitments and production dependencies should be based on the availability and support terms actually offered to their tenant. The sensible immediate decision is whether to evaluate the preview—not whether to assume a completed worldwide production rollout.
Purview separates browser enforcement from delayed reporting
Microsoft documents two related policy functions in Network Data Security. Collection policies discover and collect relevant activity or content. Data loss prevention policies apply protective actions, with the general network feature supporting “Audit only” and “Block.” Collection-only communication is asynchronous, while communication used for DLP protection is real time.
The integration is established through the Security Store within Microsoft Purview Data Loss Prevention. This creates a bidirectional connection: Purview supplies the relevant policy configuration, and the integrated security solution sends matching data for classification and evaluation. Island’s Marketplace description identifies its connection as a consented application using Microsoft Graph.
This is an important boundary in the phrase “before it leaves the browser.” Island describes inspecting information before it is shared with the destination application, but Microsoft’s documented architecture still involves sending matching data to Purview for evaluation. Browser-based enforcement should therefore not be interpreted as a guarantee that all inspection happens locally or that no content enters a cloud classification service.
After classification, events can appear in Activity Explorer and the activity explorer within Data Security Posture Management, or DSPM. DLP alerts appear when the policy matches and alerting has been configured. The Island announcement also describes enrichment of Insider Risk Management and AI compliance workflows; that is a signal-integration claim, not evidence that a particular event necessarily produces an alert or a specified risk-score change.
Administrators must distinguish this enforcement path from reporting latency. Microsoft says initial policy distribution and data appearance can take up to 24 hours after integration setup. Once communication is established, request information can take up to 30 minutes to appear in the audit log and Activity Explorer. Those reporting delays do not mean a configured block waits 30 minutes to take effect.
A useful validation therefore checks two outcomes separately: whether the user’s attempted action receives the configured treatment, and whether the corresponding event subsequently reaches reporting. In Activity Explorer, Microsoft documents filtering the enforcement plane to “network” to isolate Network Data Security activity. Immediately missing telemetry, on its own, is insufficient evidence that an inline policy failed.
Island’s unmanaged-device promise stops at Purview’s identity boundary
Island says the integration can support managed and unmanaged devices without requiring additional endpoint agents, mobile device management enrollment, or virtual desktops. Its Marketplace description explicitly identifies bring-your-own-device and contractor use cases. Those statements make the preview worth evaluating where an organization wants browser-based controls without enrolling the entire device.
Microsoft documents a separate restriction that must accompany that promise: Network Data Security policies do not apply to B2B guest users. Device management status and account type are different questions. An unmanaged device may be within Island’s advertised deployment scope while the identity using it remains outside Purview’s documented policy scope.
For contractor access, that means the evaluation must begin with the actual account model. A claim about contractor devices cannot be read as a guarantee of enforcement for contractors signing in as business-to-business guests. Organizations need to establish which identities are eligible before judging whether the integration solves their external-worker scenario. This follows directly from the difference between Island’s device claim and Microsoft’s account restriction.
Application boundaries need similar care. Microsoft warns that consumer and enterprise editions of a service may share a URL, allowing a policy targeting an unmanaged application to capture interactions from both. A policy intended to monitor personal-service use may therefore have a broader practical scope than its administrator expects. Microsoft also says multiple catalog entries can exist for one application and may need to be included to avoid coverage gaps.
Copilot has an explicit boundary of its own. Microsoft says the unmanaged-cloud-app features described in this Network Data Security guidance apply to consumer Microsoft Copilot; enterprise Copilot has separate protection guidance. Administrators should not transfer these instructions wholesale to Microsoft 365 Copilot governance simply because both products carry the Copilot name.
Network Data Security has limits that a browser does not erase
Microsoft’s general Network Data Security model covers four activities: sending text, uploading files, receiving text, and downloading files. However, Microsoft explicitly says supported activities and actions can differ by integration. Island’s descriptions establish its intended browser-level scope, but they do not justify assuming that every general Purview capability behaves identically across the Enterprise Browser, Extension, and every add-in.
The documented technical boundaries give administrators concrete tests to design:
| Boundary | Documented behavior | Evaluation consequence |
|---|---|---|
| Network protocols | HTTP and HTTPS are supported; WebSocket support depends on the integration. | Validate the actual application interaction rather than assuming the site’s HTTPS address proves complete coverage. |
| Inline text evaluation | Purview evaluates up to 4 MB for text upload and download operations. | Include text sizes representative of the intended workload. |
| Inline file evaluation | Microsoft lists files up to 3 MB for upload and download evaluation. | Do not extrapolate a successful small-file test to larger transfers. |
| Application behavior | Encoded content and dynamically generated endpoints can affect enforcement. | Test the specific service and operation that employees use. |
| Enforcement actions | The general model supports auditing and blocking, with partner-dependent support. | Confirm the required action for each Island deployment path. |
These are Microsoft’s published Network Data Security boundaries, not independently measured Island limits. They constrain what can safely be promised before a tenant-specific evaluation.
Cost also has two sides. Island’s announcement lists an Island Enterprise Browser or Island Extension license alongside Purview E5 or equivalent licensing and configured Purview pay-as-you-go. Microsoft separately confirms that non-Microsoft secure-browser integrations require the Purview per-user entitlement and pay-as-you-go billing. An eligible Purview subscription alone is not the complete prerequisite.
For these partner integrations, Microsoft defines the billing unit as a request: a network call from a device or browser to a website or API. Responses are excluded from that definition. A budget based only on the number of employees, documents, or visible AI conversations therefore does not map directly to the published meter; an evaluation should establish the relevant request volume and applicable charges before broad deployment.
There is a data-handling decision alongside the cost decision. Microsoft warns that third-party partners can access and potentially store some policy configuration, including user identifiers, under their own terms and privacy policies. Separately, enabling content capture in a collection policy can send the full user–AI conversation to Purview. Security teams should explicitly decide whether that collection is required, rather than treating discovery, blocking, and conversation capture as one inseparable setting.
What this means for your Purview and Island evaluation
Organizations already using Island and Purview have the clearest reason to evaluate the preview: they can assess an additional enforcement path while reusing established classification work. The evaluation should establish account eligibility, supported browser workflows, policy behavior, reporting, and consumption cost before anyone relies on the integration as a production control. That recommendation follows from the vendor’s reuse model and Microsoft’s documented prerequisites and restrictions.
The supported preparation sequence starts with licensing and pay-as-you-go, followed by the Security Store integration and the relevant collection or DLP policies. Microsoft’s general documentation establishes that order, but it is not a complete Island installation runbook: the cited material does not establish minimum Island versions, exact consent permissions, or an operating-system compatibility matrix. Those details are prerequisites to a deployment decision, not settings to infer from the roadmap.
For a controlled evaluation, the most concrete takeaways are:
- Treat the Marketplace offering as a preview and June 2027 as the current general-availability target, rather than relying on older copies that still show June 2026.
- Verify user identity types before selecting the pilot population, because Microsoft excludes B2B guest users from Network Data Security policies.
- Define the applications and activities explicitly, accounting for shared consumer/enterprise URLs and multiple catalog entries for the same service.
- Evaluate auditing and blocking against the required typed-text, pasted-text, file-transfer, and extension workflows, without assuming every integration supports every general Purview action.
- Check user-facing enforcement separately from Activity Explorer results, allowing for Microsoft’s documented policy-distribution and reporting delays.
- Establish request-based costs and content-capture requirements before widening policy scope, and review the partner’s handling of policy configuration and identifiers.
Purview’s Island integration offers a concrete extension of existing data-protection work: browser interactions can become inputs to the same classification and policy system used elsewhere in the organization. Its value will be clearest where eligible users already work through Island and administrators can validate the relevant application paths. With general availability currently targeted for June 2027, the actionable milestone is a bounded preview evaluation that establishes exactly which interactions the organization can protect—and at what operational and consumption cost.