Edge for Business Browsing with Copilot: Admin Allow Lists, DLP and Preview Requirements

WinCentral's latest roundup says Microsoft's answer is to put the controls in the browser itself. Admins decide where the agent can go, existing data-loss prevention rules keep working, and a person still has to approve sensitive steps. Most of these features are not new this week, though. Microsoft announced agentic browsing in limited preview on May 20, 2026, and some of the related capabilities date back to Ignite in November 2025. The useful questions now are what is actually available, what it needs, and how admins can configure it without regretting it later.

What Browsing with Copilot actually does​

Microsoft's deployment documentation says that, when enabled, Copilot can browse websites on a user's behalf, following their instructions to complete multi-step workflows and reduce repetitive tasks. Microsoft's May announcement gives examples such as moving through pages, filling in information and completing workflows. Think of filling out forms, working through internal portals, or gathering information spread across several sites.

It does not take over the browser on its own. According to the policy reference, when browsing with Copilot is enabled, users can explicitly invoke it for a query. It isn't invoked automatically. In the Copilot sidepane, users choose "Browse with Copilot" from the menu above the input box. Microsoft's FAQ adds that Copilot decides whether a prompt calls for a chat answer or an action, and that action verbs like "open," "post," or "complete" help it recognize a task request.

Who can use it right now​

The preview has several limits that will rule out many readers:

Meeting the version requirement does not get you in. A tenant on Edge 148 without preview approval or Copilot licenses will not see the feature.

Section summary: Browsing with Copilot is a desktop-only, user-started agent in limited preview. It is open to licensed tenants outside the EEA that apply for access.

The admin controls: allow lists come first​

The most important design choice here is that the agent can't browse anywhere until an admin says where it may go. Microsoft's documentation states that Copilot can only browse on domains that you authorize through policy, and it respects existing DLP and policy configurations. Copilot requests user input for steps requiring authentication, and final saving and submitting actions.

Three policies control the feature:

• AllowBrowsingWithCopilot turns the feature on or off.
• BrowsingWithCopilotAllowList lists the sites where Copilot may browse.
• BrowsingWithCopilotBlockList carves out exceptions.

The defaults deserve attention. Per the policy reference, if you enable this policy, browsing with Copilot is turned on for all users who receive the policy, and users can't turn it off. If you disable this policy, browsing with Copilot is turned off for all users who receive the policy, and users can't turn it on. If you don't configure this policy, browsing with Copilot is off by default, and users can turn it on.

That third case can catch admins out. Leaving the policy unconfigured does not disable the feature. It leaves the choice to users. The allow list provides a backstop: if you disable or do not configure this policy, browsing with Copilot is unavailable on all sites, even if the AllowBrowsingWithCopilot policy is enabled. Without an allow list, the agent has no permitted sites.

Allow-list mechanics worth knowing​

The allow-list documentation includes several details that affect how you write site lists:

• Browsing with Copilot supports only HTTP and HTTPS protocols. Wildcards (*) are supported, and subdomains are matched even without wildcards. This policy applies only to the site origin; any path specified in the URL pattern is ignored.
• When multiple filters apply, the most specific match determines whether a URL is allowed or blocked. The block list takes precedence over the allow list.
• You can use a broad wildcard and then exclude specific sites. Microsoft notes you can include '*' to allow all sites, and then use the block list to restrict access to specific URLs.

The path rule matters most. Because paths are ignored, you can't allow only /expenses on an intranet host and keep the agent out of /payroll on the same origin. If the two areas need different treatment, they need separate origins. Plan site lists with that in mind.

Microsoft also offers a curated list of "commonly used sites for work" that admins can switch on, with block-list exceptions as needed. Users can see in Edge Settings which sites Copilot is allowed to access. It's sensible to review the curated list before enabling it so you know what you're approving.

Section summary: Nothing happens until an allow list exists, and the block list always wins. Allow-list entries work at the origin level, so URL paths can't be used to limit the agent.

Step by step: enabling it in the Edge management service​

Here is Microsoft's documented procedure for preview tenants:

1. Prepare a target group. Create a Microsoft Entra security group containing the pilot users in the Microsoft 365 admin center.
2. Open the Edge management service and select the Copilot tab.
3. In the Browse with Copilot row, click Configure.
4. Optionally turn on Allow Copilot to browse commonly used sites for work to use Microsoft's curated list.
5. On the Allowed sites tab, add domains under Add a site or domain and click Add.
6. On the Blocked sites tab, add any exceptions the same way, then click Done.
7. Click Assign configuration. Either add it to an existing configuration policy, or create a new one and assign it to All users or One or more groups.

Verifying the rollout​

• Sign in to Edge with an account in the targeted profile. Microsoft warns that updates may take up to 90 minutes to be downloaded to devices targeted by the configuration profile.
• Go to edge://policy, click Reload Policies, and check that AllowBrowsingWithCopilot, BrowsingWithCopilotAllowList and BrowsingWithCopilotBlockList appear. Then restart Edge.
• Open the Copilot sidepane from the toolbar. "Browse with Copilot" should appear above the input box.

Troubleshooting: "The option is missing"​

Microsoft's FAQ lists three conditions that all have to be met:

• AllowBrowsingWithCopilot is enabled
• BrowsingWithCopilotAllowList contains values
• Microsoft365CopilotChatIconEnabled is enabled

The third one is the most likely to be missed. If an earlier policy hid the Copilot Chat toolbar icon, the browsing option won't appear even when the other two policies are set correctly. Also check the user's license, the tenant's preview approval and region, and that Edge is version 148 or later.

Shops that use Group Policy rather than the cloud service will find the same settings in the ADMX templates. The policy reference lists GP unique name: AllowBrowsingWithCopilot under Administrative Templates/Microsoft Edge.

What users see, and where humans step in​

Microsoft says users get visual indicators while Copilot is acting and can pause or stop a task at any point. For sensitive actions such as entering passwords or credit card numbers, the agent stops and waits for the user. At RSAC in March, Microsoft also said the agentic mode would not have access to saved passwords or payment methods. The configuration documentation adds that Copilot asks for input before authentication steps and before final save or submit actions.

That last point does a lot of work. When an agent fills in a form wrongly, the damage normally happens when the form is submitted. Requiring a person to approve the final submission is a sensible checkpoint. It is also Microsoft's description of its own design, not an independent audit. Your pilot should test real workflows and confirm that the pauses happen where you expect.

DLP and Purview carry over to AI​

WinCentral's main point holds up: Microsoft is extending existing data protection to AI rather than creating a separate security model for it. In its March RSAC post, Microsoft said existing DLP configurations automatically apply to contextual and agentic browsing, including multi-tab reasoning. In May, it said Purview continues to enforce protections such as blocking copy and paste of sensitive data while Copilot browses.

In practice, behavior depends on your policies. A page protected by DLP may be off-limits for Copilot to read or summarize, and copy, paste or upload restrictions may also apply. If your Purview setup is patchy, AI browsing will be patchy in the same places. Test with real sensitive content before broad rollout.

The other Edge AI features in the story​

WinCentral groups several capabilities together. Their availability differs:

• Multi-tab reasoning. Microsoft said in March that it can analyze up to 30 open tabs, including websites, PDFs and Microsoft 365 apps. In May it said Purview policies keep sensitive content out of that reasoning. It now runs on desktop and mobile.
• YouTube summarization. Pulls out key points and answers questions about a video. Also on desktop and mobile. Agentic browsing, by contrast, remains desktop-only.
• Copilot-inspired new tab page. Combines search and chat in one box, with calendar, files and suggested prompts. Microsoft declared it generally available on desktop and mobile in May, with more personalization for Microsoft 365 Copilot license holders.
• Daily Briefing. Microsoft described it in November 2025 as a summary of meetings, tasks and priorities drawn from browsing tabs and Microsoft Graph, requiring a Microsoft 365 Copilot license. WinCentral says Microsoft is "working on" it. The available evidence doesn't confirm its current rollout status.
• Natural-language history retrieval. Also announced in November 2025: users describe a page they visited in the past three months instead of digging through history. WinCentral lists it as "coming soon," but no newer confirmation was found, so treat its status as unconfirmed.

A related capability is Microsoft's shadow AI protection, which uses Purview to audit or block sensitive prompts and uploads on popular consumer AI sites. It works on managed and unmanaged devices when users sign in to Edge for Business with an eligible Entra ID. It requires Microsoft 365 E5 plus pay-as-you-go pricing. It is not a prerequisite for agentic browsing.

Analysis: a sensible approach, with caveats​

From an IT perspective, Microsoft's three layers are sound: admin control over where the agent runs, existing policies that keep applying, and a human approving sensitive steps. Browser management has always been mostly about policy, and pointing those policies at an AI agent is a natural next step.

Some caveats are worth weighing:

• Vendor framing. Phrases like "safe from day one" are Microsoft's marketing. The guardrails reduce risk, but they don't remove it. An agent on an allowed site can still misread a page or make a mistake before it reaches the approval step.
• Lock-in. The full experience assumes Microsoft 365 Copilot, Purview, Entra and, for some protections, E5. That suits organizations already on Microsoft's stack and is a harder sell for everyone else.
• Geography. EEA tenants can't join the preview at all, which delays European organizations.
• Default behavior. An unconfigured AllowBrowsingWithCopilot lets users turn the feature on. Admins who want it off should set the policy to disabled rather than assume an empty allow list will always cover them.

Bottom line for admins​

If you're eligible, run a small pilot. Start with a narrow allow list of internal or low-risk sites, assign it to a dedicated Entra group, check DLP behavior against real sensitive content, and confirm users actually get the approval prompts before authentication and submission. If you're not ready, set AllowBrowsingWithCopilot to disabled explicitly. Leaving it unconfigured passes the decision to users.

The agent can click buttons, but under this design, admins still decide where it is allowed to go.