How to Disable Custom Connectors in Copilot Studio: 8 Steps

Disable custom connectors in Copilot Studio with one data policy rule. Block unapproved MCP servers and APIs, allow vetted hosts and prove it works.

TL;DR: To disable custom connectors in Copilot Studio, edit your tenant-level data policy in the Microsoft Power Platform admin center and set the custom connector * URL pattern to Blocked. Model Context Protocol (MCP) servers connect through the same connectors, so the rule stops unapproved MCP servers too. Then allow vetted hosts, block HTTP and test.

Any maker in Microsoft Copilot Studio can connect an agent to almost any API. On the Tools page, Add a tool > New tool offers Custom connector and Model Context Protocol, and the MCP onboarding wizard asks for a server name, a description and a URL, with authentication preselected as None. If you want to disable custom connectors in Copilot Studio, the control isn't in Copilot Studio. It's in your Power Platform data policy.

A custom connector is a maker-built wrapper around an API, identified by its host URL, that Power Apps, Power Automate and Copilot Studio can call like any other connector. Copilot Studio uses the same plumbing for MCP. Microsoft's documentation says access to MCP servers relies on Power Platform connectors, so a data policy that governs connectors also governs MCP servers and their tools.

One tenant rule closes both doors. Unreviewed connectors are how agent sprawl becomes the new shadow IT.

Who is this guide for, and what will you have at the end?

This guide is for Power Platform administrators, Copilot Studio platform owners and security architects. By the end you will have a tenant rule that blocks every custom connector by default, an allowlist of approved hosts, the HTTP request route closed, a clear message for makers and a test that proves it works.

New to MCP? Start with how the Model Context Protocol works. Then pair this guide with your decisions on Copilot Studio agent accounts versus service accounts, since a connector's sign-in decides whose data an agent reaches.

What do you need before you block custom connectors?

You need the Power Platform Administrator role, an inventory of existing custom connectors and an owner for approvals.

Swipe horizontally to view each prerequisite and why it matters.

Prerequisites for disabling custom connectors in Copilot Studio with a Power Platform data policy
Prerequisite	What you need	Why it matters
Admin role	Power Platform Administrator for tenant-level policies. Environment Admin (System Administrator with Dataverse) for environment-level ones.	Only tenant-level policies have the Custom connectors URL pattern page.
Licenses	No add-on license for classic data policies. Managed Environments only if advanced connector policies must block connectors classic policies can't.	The core control works on the licenses you have.
Tools	Power Platform admin center and the Microsoft.PowerApps.Administration.PowerShell module.	PowerShell lists custom connectors and sets the message makers see.
Inventory	Every custom connector and MCP server in use, with host URL and owner.	Agents that use a blocked connector can't be published until the host is approved.
Approval path	A named owner and a request form for new APIs.	Makers need a clear yes path, or they look for a way around the block.

How do you disable custom connectors in Copilot Studio?

Edit your tenant-level data policy, set the * custom connector pattern to Blocked, allow approved hosts above it and block the HTTP connector. The policy change takes about 30 minutes; in 2toLead's experience the inventory and testing take a day across a few environments.

Inventory the custom connectors and MCP servers you already have. Run Get-AdminPowerAppConnector, then open Power Apps > Custom connectors in each environment where agents are built; MCP servers added through the Copilot Studio wizard appear there too. Record each host URL, owner and the agents that use it. Expected result: A list of host URLs to approve or retire before anything is blocked.
Open your tenant-level data policy. In the Power Platform admin center, go to Security > Data and privacy > Data policy. Select the tenant-wide policy that already holds your Business connectors and choose Edit Policy, or select + New Policy if you have none. Expected result: The policy wizard opens, starting with the policy name and then Prebuilt connectors.
Block the HTTP connector. On the Prebuilt connectors page, search for HTTP, select the three dots and choose Block. If some agents need specific endpoints, choose Configure connector > Connector endpoints instead and allow only those URLs. Expected result: HTTP appears in the Blocked list, or its endpoint list is saved, so makers can't rebuild a blocked API with the HTTP request node.
Set the wildcard custom connector rule to Blocked. Select Next to reach the Custom connectors page. Select the * row, which is always last and set to Ignore on new policies, choose Edit and change it to Blocked. Expected result: The last row reads * | Blocked. Every custom connector, and every MCP server added through the onboarding wizard, is now blocked in scope.
Add a pattern for each approved host. Select Add connector pattern, enter the approved host, for example https://api.contoso.com*, and classify it in the same data group as the connectors it works with, usually Business. Use Order, Move up or Move down so specific patterns sit above broader ones. Expected result: Approved patterns sit above the * rule, so vetted APIs keep working.
Set the scope and save the policy. On the Scope page, choose Add all environments, or Exclude certain environments to keep one governed developer environment open for approved pro developers. Select Next, review and select Update policy or Create policy. Expected result: The policy appears in the list with Applied to showing all environments, or all environments except the ones you excluded.
Give makers a contact and a next step. Run New-PowerAppDlpErrorSettings (or Set-PowerAppDlpErrorSettings to update it) with your Power Platform team's email address and a link to your request process. The setting applies to every Power Platform app in the tenant. Expected result: Policy errors in Copilot Studio show your admin email and a Learn more link instead of a dead end.
Test it in Copilot Studio. In an in-scope environment, open a test agent and go to Tools > Add a tool > New tool > Model Context Protocol. Enter an unapproved server URL and select Create, then repeat with Custom connector. Expected result: Copilot Studio blocks both with a data policy message, and an approved host still works.

For step 1, Agent Inventory V2 in the Copilot Agent Kit helps you find every agent first, and the kit's Power Shield feature gives makers a request workflow for custom connector patterns.

In healthcare, financial services and government, keep any excluded developer environment behind a security group.

How should you plan your custom connector URL patterns?

Plan URL patterns as a short, ordered allowlist: specific approved hosts first, each in the same data group as the connectors it works with, and * set to Blocked last. Use HTTPS and end each pattern with *.

Use this rule plan as your decision record and give every row an owner.

Swipe horizontally to view each rule, its data group and when to use it.

Custom connector URL pattern rule plan: order, pattern, data group and when to use each rule
Order	URL pattern	Data group	When to use it
1	`https://api.contoso.com/hr*`	Business	A reviewed internal API that agents combine with SharePoint, Dataverse or Microsoft 365 data.
2	`https://mcp.contoso.com*`	Business	Your own reviewed MCP server that uses OAuth 2.0, never None for authentication.
3	`https://api.approvedvendor.com*`	Non-business	A reviewed public API that never touches business data.
Last	`*`	Blocked	Everything else, including any MCP server a maker adds through the onboarding wizard.

Before you approve a host, check four things: a named owner, HTTPS only, OAuth 2.0 or API key authentication instead of None, and a data classification that matches the group you chose.

What are the most common mistakes, and how do you fix them?

The most common mistake is saving a policy with the * rule still on Ignore, which blocks nothing. Most of the others leave a side route open.

Leaving the wildcard on Ignore. New policies default to it, so custom connectors fall through. Set * to Blocked.
Blocking custom connectors but not HTTP. Makers can call the same API from the HTTP request node. Block HTTP or use endpoint filtering.
Putting approved hosts in the wrong data group. Connectors in different groups can't share data. Put approved hosts in the group of the connectors they work with.
Writing patterns that are too broad. https://*.azurewebsites.net* approves every maker's Azure app. Name the exact host.
Classifying custom connectors by name in a tenant policy. Name-based entries added with PowerShell override URL patterns. Remove them.
Trusting the host alone. Data policies evaluate a connector before its Set Host URL policy runs, so it can redirect elsewhere. Review connector policies during approval.

An MCP server with no authentication is also an easy route for prompt injection against Copilot Studio agents, which is why None should never pass review.

How do you check that blocking custom connectors worked?

You know the block works when Copilot Studio refuses unapproved connectors, approved hosts still work and the rule order is correct in PowerShell. Check all three right after saving.

In Tools > Add a tool, blocked connectors appear disabled with a cross icon; hover to see the policy reason.
An agent that uses a blocked connector shows an error banner. On Channels, expand the error and select Download to list violations; Publish is unavailable.
A test agent using an approved host saves and publishes normally.
Get-PowerAppPolicyUrlPatterns returns your approved patterns in order, with * last as Blocked.

How do you measure the value of blocking custom connectors?

Measure it by the review hours it saves and the exposure it removes. Track custom connectors per environment, unapproved hosts, MCP servers without authentication, new requests per quarter and the days it takes to approve one.

Here is a 2toLead illustrative model; swap in your own numbers. Without a block, a 2,000-person healthcare network adds about 30 custom connectors a quarter, 12 of them MCP servers from the wizard. Reviewing each after the fact takes about four hours: 120 hours, or $14,400 at a loaded $120 an hour.

With custom connectors blocked by default, makers request only what they need, say six a quarter at two hours each: 12 hours, or $1,440. After a one-day setup, that returns about 100 hours in the first quarter and more than 400 a year, and the network knows every API its agents can call.

Report approved hosts next to your agent count. When your agent estate doubles while controls stay flat, this number shows the controls kept up.

Every custom connector is a door into your data. Block by default, open on purpose.

What do IT leaders ask about blocking custom connectors in Copilot Studio?

Does blocking custom connectors also block MCP servers in Copilot Studio?

Yes, for MCP servers added through the onboarding wizard or built as custom connectors. Microsoft states that MCP servers in Copilot Studio rely on Power Platform connectors, so a policy that blocks those connectors blocks the server and its tools. Servers registered in Agent 365 can also be blocked under Agents > Tools in the Microsoft 365 admin center.

What happens to agents that already use a blocked custom connector?

Copilot Studio enforces data policies in real time. Makers see an error banner, Publish becomes unavailable, and users can see errors until the tool is removed or its host is approved. Inventory first and allow the hosts you need before you save.

Will this block Microsoft's own connectors and MCP servers?

No. The custom connector rule only matches custom connectors by host URL. Prebuilt and certified connectors, including Microsoft's MCP connectors, are governed on the Prebuilt connectors page or with advanced connector policies, which can block an entire MCP server.

Do advanced connector policies replace custom connector URL patterns?

Not yet. Advanced connector policies currently cover certified connectors only, and Microsoft lists custom connector and HTTP support as planned. Keep your classic data policy rule in place and run both in the default mixed mode, where the most restrictive setting wins.

How can 2toLead help?

2toLead helps organizations in healthcare, financial services, education, nonprofit and government turn Copilot Studio into a governed, measurable platform. In a fixed-scope, two-week Connector Guardrails Sprint, our Microsoft MVP team will: