Best ways to scope Copilot Cowork connectors to only the workflows you approve

Table of Contents

The Direct Answer

Scope Copilot Cowork connectors by building a spending policy that grants only the agents and services a workflow needs, disabling the “allow new services automatically” toggle, and mapping each approved connector to a named use case. Assign users to that policy by security group so unapproved plugins never enter a task’s plan.

Deeper Explanation

Connector scoping is a spending decision, not only a security one, because Cowork is agentic and bills by usage. Since general availability on 2026-06-16, Cowork runs multi-tool tasks end-to-end rather than drafting suggestions, and every connector it can reach is a candidate the planner may call. When a catalog is wide open, the model retrieves context and makes tool calls across systems you never intended, and each of those actions consumes Copilot Credits at $0.01 apiece. Narrowing the connector surface to approved workflows therefore narrows the credit surface at the same time it narrows the data surface. For an application owner, that dual effect is the whole argument: the same control that keeps a task from wandering into an unrelated system also keeps its cost in the tier you budgeted for.

The control itself lives in Microsoft’s spending policies rather than inside Cowork. As Microsoft documents, admins select which agents and services a policy can access and choose whether new services are added automatically as they ship. The practical framing is to treat each policy as an “approved workflow bundle”: Dynamics 365 Sales connectors for the revenue team, Fabric for analysts, and nothing more. Users outside a policy cannot reach those connectors at all, which converts an open plugin catalog into an allow-list you curate deliberately. Because policies attach to security groups, the same mechanism lets you run several narrow bundles side by side instead of one permissive tenant default, so scoping scales with your org chart rather than fighting it.

Scoping is also what makes a rollout defensible after the fact. An approved-workflow allow-list gives you a clean answer to the question every audit and every budget review eventually asks, which is why a given connector was reachable and who signed off. Without it, Cowork’s autonomy means you are accountable for tool calls no human explicitly chose. With it, every connector in a policy traces back to a named workflow, an owner, and a review date, so the configuration reads as an intentional design rather than an accident of defaults left switched on since the day Cowork was enabled.

The Research

Strategy and Actionable Steps

Start from workflows, not connectors. List the two or three Cowork tasks each team is actually approved to run, then work backward to the minimum connector set each requires. This inverts the default posture, where every enabled plugin is fair game, and it forces a named business reason to sit behind each connector before it is allowed. Owners who skip this step tend to approve connectors defensively “just in case,” which is exactly how catalogs sprawl and credits leak.

Create one spending policy per approved bundle, scope its agents and services to that connector set, and turn off automatic inclusion of new services so a future connector launch cannot silently widen the catalog. Assign the policy to a security group, set a monthly limit, and add a usage alert so drift shows up before the invoice does. Route any request for a connector outside the bundle through a lightweight review, so additions are deliberate and traceable rather than accreted. Revisit each bundle quarterly against real usage and prune connectors that no approved task has touched.

Reinforce the approved list where people work. Tightening the tenant policy stops the wrong connector from running, but users still need to know which Cowork tasks are sanctioned and why, or they will improvise around the guardrails. A structured enablement program such as VisualSP’s Copilot Catalyst builds that governance habit through coached, real-workflow sessions and in-app reinforcement, turning approved patterns into default behavior instead of a rule people route around. Pair it with a written Copilot adoption plan and an in-app guidance layer so scoping decisions are documented rather than tribal knowledge, and so a new application owner can inherit the rationale, not just the settings.

FAQ

Can I scope connectors per team instead of tenant-wide?

Yes. Each spending policy is scoped to a security group and carries its own access list and monthly limit, and policy-level limits do not inherit the tenant default. That lets you give the analytics team Fabric while the sales team gets only Dynamics 365 connectors, without one broad policy having to satisfy everyone.

What happens when Microsoft ships a new connector?

If the “allow new services and agents as they become available” toggle is on, the new connector is added to the policy automatically. Turn it off for any policy where you want an explicit review before a connector can be called, then add approved ones by hand. This keeps launches from quietly expanding what Cowork can reach.

Does scoping connectors actually reduce credit cost?

Indirectly but meaningfully. Fewer reachable connectors means fewer tool calls and less cross-system context retrieval, two of the four factors that determine a task’s credit cost. A tight allow-list keeps routine tasks in the light tier of roughly 100 to 300 credits instead of ballooning into heavy ones.

Who can change connector scope for a policy?

Global and billing administrators manage spending policies, including which agents and services are allowed and the billing method per policy. Application owners typically define the approved workflow-to-connector mapping and hand it to those admins to enforce, keeping business intent and technical control aligned.

How do users request a connector that is not scoped in?

Microsoft supports credit and access requests that administrators review. Route connector additions through the same request flow so every new plugin has a named workflow behind it before it joins a policy. That single habit prevents most catalog sprawl.

Should I start restrictive or permissive?

Start restrictive. It is far easier to add a connector after a team proves a workflow needs it than to claw back credits already spent through plugins no one approved. For usage-based billing, an allow-list is safer than a block-list because the default state costs you nothing.

How is this different from blocking connectors in individual apps?

App-level blocks stop a plugin in one surface; spending-policy scoping governs which connectors Cowork can call across every task a group runs. Because Cowork plans autonomously, the policy layer is the reliable place to enforce an approved list rather than chasing each app separately.

What should I document once scoping is in place?

Record each policy’s approved workflows, its connector list, its owner, and the review cadence. That documentation lets you defend the configuration in an audit, onboard a successor cleanly, and evaluate future connector requests against a stated standard rather than ad hoc.

Table of Contents