Copilot Cowork Browser Governance: 5 Controls
Copilot Cowork’s browser is not a cloud robot with its own identity. It acts through the user’s local Microsoft Edge session – including the access that user already has.
That makes Copilot Cowork browser governance an identity, endpoint, compliance, and cost decision. Before enabling it broadly, admins need to understand exactly where the control boundary sits.
The Problem
Cowork can complete web tasks in a hidden Edge tab while the user remains in the conversation. The tab uses the user’s existing single sign-on, cookies, and sessions. Credentials, cookies, and session tokens stay on the device, but the agent can reach the same sites the user can reach – no more and no less.
The risk is therefore not a new privileged service account. It is faster, delegated use of an existing human identity. Over-permissioned users, weak browser policy, or unclear approval expectations become automation risks.
The Nugget
Treat browser use as delegated user action and apply five layers before rollout:
Control What to configure
Tenant access Enable Cowork Browsing only for an intentional pilot
Browser surface Require an up-to-date Edge work profile with the same work account
Site reach Apply Edge allowlists, blocklists, web filtering, and view-only rules
Data and identity Keep Conditional Access and Microsoft Purview DLP in scope
Operations Review approvals, unified audit events, and Copilot Credit consumption
The feature is disabled by default. Today, browser tasks work in Cowork on the web with Microsoft Edge, not in the desktop app, mobile client, or other browsers.
Why This Matters
Existing controls still matter. Microsoft states that local browser tasks inherit browser-management policy, Conditional Access, web filtering, and Purview DLP. A blocked action should remain blocked when Cowork attempts it.
But inheritance is not the same as readiness. Teams should decide which actions require user approval, which sites are safe for automation, and how interrupted tasks are handled. CAPTCHA, multifactor authentication, expired sessions, and password resets can hand the browser back to the user.
There is also a cost boundary. Browser tasks count toward usage-based billing, so the same rollout needs both security scope and a consumption limit. Pair this control model with Copilot Credits Cost Management instead of treating security and spend as separate projects.
What Admins Should Do
-
Create a small pilot group with representative business roles.
-
Review each pilot user’s effective site access before enabling Cowork Browsing.
-
Test allowed, blocked, view-only, DLP-protected, and approval-required actions.
-
Search the unified audit log for the resulting Cowork browser activity.
-
Set Copilot Credit limits and define who reviews consumption anomalies.
Document a supported-task catalog for the pilot. “Use Cowork for travel research” is too broad; “compare public travel options without submitting a booking” gives users and reviewers a clear boundary.
Verification Path
Use Cowork on the web in Edge with the same work account as the Edge profile. Run one approved task on an allowed site, one task against a blocked site, and one action that changes data. Confirm that policy enforcement, approval behavior, hand-back, audit visibility, and consumption reporting match your design.
Pro Tip
Test the denied path first. If a blocked site, DLP policy, or approval boundary fails quietly, the pilot is not ready – even when the happy-path demo looks perfect.