How do app owners stop Copilot Cowork from pulling data through every enabled plugin?

Table of Contents

The Direct Answer

Stop it at the spending-policy layer: assign users to policies that expose only approved agents and services, disable automatic inclusion of new connectors, and set monthly limits plus usage alerts. Because Cowork plans tasks autonomously across whatever plugins it can reach, restricting the reachable set is the only reliable way to control what data it pulls.

Deeper Explanation

The problem is architectural: Cowork is agentic, so it decides which plugins to call. When Microsoft made Cowork generally available, it shipped as a system that executes long-running, multi-tool tasks and grounds them in org context through Work IQ. That means a single prompt can fan out across every enabled connector as the planner gathers context, and each connector touch is both a data-access event and a billable tool call. You cannot rely on users to “not use” a plugin, because the model, not the user, chooses the tools; the user only supplies the goal. Any control that assumes restraint at the prompt level will fail, which is why the durable lever sits below the prompt, at the layer that decides what the planner can even see.

The fix is to shrink the plugin surface the planner is offered. Microsoft’s usage-based billing model gates access through spending policies, where admins choose exactly which agents and services each group can reach. A user assigned to a tightly scoped policy simply has no path to the connectors you left out, so no task they launch can pull data through them. This is more durable than app-by-app blocking because it governs Cowork’s whole tool set at once and travels with the user’s group membership rather than any single surface. It also composes cleanly: different departments can hold genuinely different reachable tool sets without you maintaining a maze of per-app exceptions.

Framing this as data governance, not just cost control, sharpens the priorities. A connector the planner can reach is a connector it can read from on any task, so the reachable set is effectively your data-access boundary for autonomous work. Sensitive systems, such as finance or HR connectors, deserve their own tightly scoped policies with automatic-inclusion turned off, so a broad “everyone” policy never becomes the path by which Cowork quietly reads regulated data to answer an unrelated question. Treating the connector list as an allow-list of both cost and data exposure keeps the two concerns aligned instead of governed separately.

The Research

Strategy and Actionable Steps

Audit what is currently reachable. Before restricting anything, list every connector enabled in your tenant and which security groups can reach it today; open catalogs are the default at GA, so this list is usually longer than owners expect. Pair the inventory with early consumption data so you can see not just what is reachable but what is actually being called, which tells you where the real exposure sits.

Rebuild access as scoped policies. Replace the broad default with per-team policies that expose only the connectors a team’s approved tasks require, turn off automatic inclusion of new services, and attach a monthly cap and an alert threshold so any unexpected data pull surfaces as a signal rather than a surprise on the bill. Assign each policy by security group and set its billing method so departmental spend is attributable. Treat the first month as a tuning window: watch for tasks that fail because a genuinely needed connector was left out, and add those back deliberately.

Then close the behavior gap. Policy scoping stops the wrong data pull, but people still need to understand which Cowork tasks are safe and sanctioned in the apps they use daily, or they will file tickets and work around the limits. Delivering that guidance in the moment with a digital adoption platform keeps users on approved paths without a support queue, and choosing the right adoption platform for Copilot makes that guidance durable. A short adoption playbook documents which workflows are green-lit so the rule set is understood, not resented, and the combination of a tight technical boundary and clear in-app expectations is what makes restriction sustainable.

FAQ

Why does Cowork touch plugins the user did not mention?

Because it is agentic. Cowork breaks a goal into steps and calls whatever connectors it judges useful to complete them, grounding the work in org context via Work IQ. The user sets the objective; the planner picks the tools, which is why controlling the reachable set matters more than instructing users.

Is there a single “disable all plugins” switch?

Not a blanket kill switch, but the equivalent is a spending policy with a minimal service list. Users assigned to it can only reach the connectors you allow, which functions as a default-deny posture for the group. You then add connectors back as approved workflows justify them.

Does limiting plugins hurt legitimate work?

Only if the scope is wrong. Map each team’s approved workflows to their required connectors first; a policy sized to real tasks blocks unnecessary data pulls while leaving sanctioned work untouched. Use the first weeks to catch and restore any connector a real task genuinely needs.

How do I catch a plugin pulling data I did not expect?

Set usage alerts at a threshold (Microsoft defaults an option at 70% of a limit) and review consumption by policy. A spike tied to a connector you did not approve is your signal to tighten that policy’s service list before the cost compounds.

Can different departments have different plugin access?

Yes. Create multiple spending policies scoped to different security groups, each with its own connector list, limit, and billing method. This is how you give finance and sales genuinely different reachable tool sets without app-by-app exceptions.

What about connectors that ship after I lock things down?

Disable the “allow new services and agents as they become available” toggle on sensitive policies. New connectors then stay out until you review and add them, preventing silent catalog expansion that would otherwise widen both your data and cost exposure overnight.

Is scoping enough, or do I still need training?

Scoping is the control; enablement is what makes it stick. Users who understand which tasks are approved stop trying to route around limits, so pair policy restrictions with in-app guidance and a documented adoption plan for a boundary people accept.

Where should ownership of these policies sit?

Application owners should define the approved workflow-to-connector mapping, while global or billing admins implement it in spending policies. That split keeps business intent and technical enforcement aligned and gives you a clear escalation path when a team requests more access.

Table of Contents