Browsing with Copilot reads the page a user is on. That makes it a data governance decision wearing a browser setting’s clothes, and the Edge Copilot policies that landed in Intune with the Edge 149 administrative templates give you the controls to make that call deliberately rather than by default.
What actually arrived
The Microsoft Edge administrative templates in the Windows settings catalog were refreshed to Edge 149, which brought the Copilot governance policies with it. Microsoft sets out the feature and its controls in Configure browsing with Copilot. Find them in the Intune admin centre under Devices > Manage devices > Configuration > Create > New policy > Windows 10 and later > Settings catalog, then search the Microsoft Edge category.
| Policy | What it controls |
|---|---|
AllowBrowsingWithCopilot | Whether browsing with Copilot is available at all. This is the master switch. |
BrowsingWithCopilotAllowList | URL patterns where it is permitted. |
BrowsingWithCopilotBlockList | URL patterns where it is not. |
CopilotNewTabPageEnabled | The Copilot new tab page. |
CopilotAddressBarSuggestionsEnabled | Copilot suggestions in the address bar. |
M365LinksAutoOpenCopilotEnabled | Whether the Copilot side pane opens automatically with contextual insights for links opened from Outlook. |
ConfigureNTPFeedTabVisibility | Whether the Discover and Work feed tabs appear on the Copilot new tab page. |
SetNTPDefaultFeedTab | Which of those two is the default. |
The two Edge Copilot policies that matter
Most of that list is user experience. Two entries are not.
AllowBrowsingWithCopilot and its allow and block lists decide whether page content leaves the page. Everything else on the list changes what a tab looks like.
The distinction matters because the block list is where your internal applications belong. A line-of-business app rendered in Edge is a web page as far as browsing with Copilot is concerned. So is your ticketing system, your HR portal, and whatever internal site holds the data your DLP programme exists to protect.
Worth knowing
This is the same problem as Copilot oversharing in SharePoint, arriving through a different door. I covered that side of it in rolling out enterprise Copilot without breaking your DLP posture. There, Copilot surfaces access a user already had. Here, Copilot reads a page a user already opened. In both cases the capability is not creating exposure, it is making existing exposure reachable by asking a question in plain English.
A block list that reflects your estate
Start from your internal DNS rather than from imagination. The sites worth blocking are the ones that were never designed to be read by anything other than the person signed into them.
- Internal line-of-business applications, including anything on a private hostname.
- Admin portals. Your own tenant’s admin centres, and any third-party console holding customer data.
- HR, payroll and finance systems.
- Anything already covered by a Purview DLP policy. If the content warranted a DLP rule, it warrants a Copilot block. Whether you hold that DLP capability at all is a licensing question, answered in Microsoft Purview cost.
Then decide the default. Blocking everything and allowing exceptions is defensible on a regulated estate, where the same judgement shows up in Conditional Access policy design, and unworkable on most others, because the value of the feature is that people do not have to think about it.
Checking what is deployed
Settings catalog policies are configuration policies in Graph, so you can audit which of these you have actually set rather than trusting memory. If a policy is set and not landing, check the device is syncing before you change it: forcing an Intune sync.
# Requires Microsoft.Graph.DeviceManagement.
Connect-MgGraph -Scopes 'DeviceManagementConfiguration.Read.All'
$needles = @(
'browsingwithcopilot'
'copilotnewtabpage'
'copilotaddressbar'
'm365linksautoopencopilot'
'ntpfeedtab'
)
Get-MgBetaDeviceManagementConfigurationPolicy -All |
ForEach-Object {
$policy = $_
$settings = Get-MgBetaDeviceManagementConfigurationPolicySetting `
-DeviceManagementConfigurationPolicyId $policy.Id -All
foreach ($s in $settings) {
$json = $s.SettingInstance | ConvertTo-Json -Depth 12
foreach ($n in $needles) {
if ($json -match $n) {
[PSCustomObject]@{
Policy = $policy.Name
Setting = $n
}
}
}
}
} |
Sort-Object Policy, Setting -Unique |
Format-Table -AutoSize
An empty result is the answer most tenants will get, and it means browsing with Copilot is running on its defaults everywhere.
One more from the same release
Edge 149 also added MAMWithDeviceDLP, which allows MAM enrolment when a managed device already has a Purview DLP policy configured. If you have been unable to combine app protection policies with device-level DLP without one blocking the other, that is the setting to look at.
What I would do
Set AllowBrowsingWithCopilot deliberately rather than leaving it at the default, whichever way you decide. A default is a decision nobody has written down, and this is not a feature you want to be explaining after the fact.
Then build the block list from the DLP policies you already have. That list has already been through a conversation about what is sensitive, which means you are reusing a decision rather than making a new one, and it will be easier to defend than a list somebody assembled from memory on a Friday.
The rest of the policies are user experience. Set them once, put them in the same profile, and stop thinking about them.
