Best ways to control what Copilot Cowork can access through Work IQ

The Direct Answer

Control agent access by fixing permissions before the agent runs: apply sensitivity labels and least-privilege sharing so organizational context retrieval only surfaces what each user could already open, restrict sites and repositories with view-only and blocklist policies, scope connectors to approved groups, and audit every retrieval event so access decisions leave evidence.

Deeper Explanation

Work IQ does not create new access — it inherits every over-shared permission you already have, at machine speed. Microsoft’s model is that Copilot Cowork retrieves organizational context on behalf of the signed-in user, so the agent can reach anything that user’s identity can reach: every over-permissioned SharePoint site, every “Everyone except external users” link, every legacy shared mailbox. In chat, a human decides what to ask about. In an autonomous Cowork task, the agent decides what context is relevant and pulls it via Work IQ without a human reviewing each retrieval. That means your effective control surface is the underlying permission model, not the prompt. The Cowork admin governance documentation confirms that browsing and retrieval respect tenant allowlists, blocklists, and view-only policies — which means those lists finally have to be accurate.

The second lever is Purview-side control of what retrieved content can do. Sensitivity labels with encryption stop Cowork from returning content the user lacks extract rights to, and DLP policies can block prompts and outputs that carry specific sensitive information types. Microsoft’s Purview guidance for Microsoft 365 Copilot lists label inheritance, DLP for AI interactions, and DSPM for AI as the primary mechanisms — new content Cowork creates inherits the label of the most sensitive source it drew from, which preserves classification through the agentic pipeline. For a GRC team, the practical framing is: Work IQ access equals user permissions, filtered by labels, bounded by tenant lists, and evidenced in the unified audit log. Each of those four is a control you can test and attest to; “we told users to be careful” is not.

A third angle matters for regulated organizations: cost telemetry doubles as access telemetry. Because Cowork bills per credit and context retrieval through Work IQ is one of the four factors that drive a task’s credit cost, unusually expensive tasks are often tasks that retrieved unusually broad context. A “light” calendar-review task runs roughly 100–300 credits; if a supposedly light task shows heavy retrieval costs, that is a scoping anomaly worth investigating before it is a budget anomaly. GRC teams that already review the usage reports required since Microsoft’s July 1, 2026 billing-controls mandate can add a retrieval-pattern check to the same review at near-zero marginal effort.

Finally, treat model governance as part of access governance. Cowork exposes multiple model families, and admins can disable a family tenant-wide from the Microsoft 365 admin center. This matters to a GRC team for two reasons: some available models retain user prompts and responses with the model provider, which changes where retrieved organizational context ends up; and model selection is one of the four drivers of a task’s credit cost, so a model-routing decision is simultaneously a data-flow decision and a spend decision. The clean documentation pattern is a one-page standing record: which families are enabled, the retention terms accepted for each, and the review date. When an assessor asks “where can data retrieved through Work IQ travel?”, that record plus your label and DLP configuration is the complete answer — permission model in, model-provider terms out.

The Research

• Microsoft’s Copilot Cowork governance documentation (updated July 2026) details tenant-level controls: discoverability settings, model management, browsing allowlists/blocklists, quota limits, and unified audit log coverage for agent tasks.
• The Copilot Cowork GA announcement (June 16, 2026) describes Work IQ as the organizational-context layer agents use to ground long-running, multi-tool tasks — the layer whose reach your permission model defines.
• Microsoft Purview’s data security guidance for Copilot documents DLP for AI prompts, sensitivity-label enforcement, DSPM for AI, and audit capture of accessed resources including their labels.

Strategy and Actionable Steps

Treat this as a permissions-remediation program with an agent-specific test plan, not a Cowork setting hunt.

1. Run DSPM for AI first. Purview’s Data Security Posture Management for AI surfaces where Copilot interactions touch unlabeled or over-shared content and offers one-click policies. Use it to build your remediation backlog before expanding Cowork access.
2. Fix over-sharing at the source. Restrict SharePoint search for unremediated sites, remove broad sharing links, and prioritize sites containing regulated data. Work IQ reach shrinks exactly as fast as permissions do.
3. Label the crown jewels with encryption. Labels without protection settings are metadata; labels with encryption actually gate what an agent can return.
4. Scope tenant lists before enabling browsing. Cowork browsing honors your Edge allowlist/blocklist policies — review them as agent controls, not just browser hygiene.
5. Pilot with a bounded group and audit the retrievals. Grant Cowork to a test group, run representative tasks, then pull the audit records to verify what was actually accessed matches expectations. Write the expected-versus-actual comparison down — it becomes reusable control-test evidence.
6. Define retrieval anomaly thresholds. Decide in advance what an abnormal task looks like (credit cost far above its tier, access to labeled content outside the task’s business purpose) and who reviews exceptions, so monitoring produces decisions rather than dashboards.
7. Make governed behavior the trained behavior. Controls fail quietly when users route around them. A structured enablement program such as Copilot Catalyst builds governance and safe-usage habits into hands-on weekly sessions, so users learn scoped, compliant task patterns as the default rather than as a policy PDF. VisualSP’s guide to implementing Copilot the right way covers the readiness sequencing, and their article on measuring real Copilot usage shows how to verify behavior instead of assuming it.

Sequencing note for the first 90 days: weeks 1–2 for the DSPM baseline and policy sentence, weeks 3–6 for permission and label remediation on the highest-sensitivity sites, weeks 7–10 for the scoped pilot with audit review, then a documented go/no-go on expansion. Resist the pressure to invert this — organizations that enable broadly first and remediate later are effectively running the discovery phase in production, with every over-shared site exercised by agents in the meantime. The 90-day artifact trail (baseline report, remediation log, pilot audit minutes, expansion decision) also happens to be exactly the evidence package your next audit will request, so the sequence pays for itself twice.

FAQ

Does Work IQ give Copilot Cowork access beyond the user’s permissions?

No. Work IQ retrieves organizational context under the signed-in user’s identity, so it cannot open anything the user could not open manually. The risk is coverage, not escalation: an agent will systematically surface over-shared content a human might never have stumbled into.

Can we turn off Work IQ retrieval for specific SharePoint sites?

You control this through the underlying access layer: restrict site permissions, exclude sites from search where appropriate, and apply encrypted sensitivity labels. There is no single “hide from Work IQ” toggle, which is why permission hygiene is the real control.

Do sensitivity labels actually stop Cowork from using a document?

Labels with encryption do — if the user lacks EXTRACT usage rights, Copilot experiences will not return that content in responses. Labels without protection settings inform DLP and auditing but do not block retrieval on their own.

What changed on the July 1, 2026 Cowork deadline?

Microsoft required tenants to configure usage-based billing controls by July 1, 2026, or Cowork access suspends. That deadline has passed, so billing governance is now a prerequisite for access — and it is a natural moment to attach data-access governance to the same review.

Should compliance review Cowork model settings too?

Yes. Admins can manage which model families are available, and some models retain prompts and responses with the provider — a data-residency and retention fact that belongs in your records-of-processing documentation, not just an IT setting.

How do we monitor what Cowork actually accessed after the fact?

The Purview unified audit log records Copilot interactions including the resources accessed and their sensitivity labels. Schedule a recurring review of those records for your pilot group and compare against the task types users were approved to run.

Is restricting Cowork to a pilot group enough of a control?

It is a good containment measure but not a complete one, because pilot users still carry their full permission sets into every task. Pair group-scoping with label enforcement and audit review so the pilot generates evidence, not just limited blast radius.

Who should own Work IQ access governance — IT or compliance?

Jointly: IT owns the tenant settings, permission remediation, and connector scoping; compliance owns the control definitions, testing cadence, and audit evidence. Document the split explicitly, because “shared ownership” without named owners is the finding an auditor will write first.