Skip to main content

Microsoft Copilot Studio

How to make Behavry the only sanctioned MCP server that Copilot Studio agents can reach — across every environment in the tenant, including ones created tomorrow.

The short answer

You cannot put Behavry in the network path. Copilot Studio is SaaS, and Microsoft's cloud makes the outbound tool calls.

What you can do is make Behavry the only sanctioned MCP connector in the tenant and block everything else with a tenant-scoped Power Platform data policy. That is an authorization chokepoint, not a network one — but Microsoft enforces it in real time at author and publish time, and it applies to every environment, including ones created later.

Why the connector layer is the lever​

In Copilot Studio, adding an MCP server is structurally a Power Platform custom connector add. Microsoft states this directly:

Blocking Power Platform connectors also blocks access to tools in connected MCP servers, which rely on Power Platform connectors for connectivity.

— Configure data policies for agents

So every governance control that already exists for connectors applies to MCP servers for free. There is no separate MCP admin surface to learn.

The enforcement recipe​

1. Register the Behavry MCP proxy as a custom connector​

Behavry's proxy speaks Streamable HTTP, which is what Copilot Studio's MCP support consumes. Publish the connector inside a managed solution so it deploys to every environment through your normal ALM pipeline, rather than being hand-created per environment.

The connector's OpenAPI definition must expose a POST at the root path carrying the protocol marker:

x-ms-agentic-protocol: mcp-streamable-1.0
Transport

SSE was deprecated for MCP and is no longer supported by Copilot Studio. Streamable HTTP is the transport — which is what Behavry's MCP proxy already serves at https://<tenant>.behavry.ai/mcp/v1.

2. Authenticate with Entra ID on-behalf-of — not an API key​

This is the part that makes or breaks the value.

With OAuth 2.0 on-behalf-of (OBO), the invoking human's UPN reaches Behavry, so the Decision Trace records who the agent was acting for. With an API key — or an agent-principal OAuth flow — every call arrives as one shared service identity, and you lose the identity binding the entire product depends on.

Don't use a shared API key

An API key collapses every user into one service identity. Your Decision Traces will attribute every action to "the connector" instead of to a person. See Agent Identity.

3. Set the default data group for new connectors to Blocked​

This is the single highest-leverage control, and the one most tenants miss. Any MCP server a maker registers tomorrow is dead on arrival until an admin explicitly classifies it.

Without this, new connectors land in Non-business, which many organizations leave permissive. Admins can configure the default group at the data policy level.

4. Create a tenant-scoped data policy​

In the Power Platform admin center: Security → Data and privacy → Data policy. On the Define scope page, choose Add all environments. Microsoft: "This policy automatically applies to any new environment created in the tenant."

That is what makes it genuinely org-wide, instead of a per-environment game of whack-a-mole.

Put the Behavry connector in Business, and block the rest.

5. Close the side doors​

The connector allowlist is not sufficient on its own — a maker can reach an external system several other ways. Block or endpoint-filter each of these:

To prevent makers from…Connector to block
Calling arbitrary URLs from an HTTP request nodeHTTP (supports endpoint filtering)
Extending agents with skillsSkills with Copilot Studio
Publishing an agent anyone can chat with anonymouslyChat without Microsoft Entra ID authentication in Copilot Studio
Reading SharePoint / OneDrive as a knowledge sourceKnowledge source with SharePoint and OneDrive in Copilot Studio
Reading public websites as a knowledge sourceKnowledge source with public websites and data in Copilot Studio
Reading uploaded documents as a knowledge sourceKnowledge source with documents in Copilot Studio

Decide deliberately on the three knowledge-source connectors: they read data without ever invoking a tool, so nothing about them appears in a tool-call audit.

6. Watch the Business / Non-business trap​

In a data policy, the connectors must be in the same data group because data can't be shared among connectors that are in different groups.

If Behavry sits in Business and some Microsoft connector you meant to allow sits in Non-business, agents combining them fail to publish — and your makers will read that as "Behavry broke it."

Put Behavry and every co-permitted connector in the same data group

This is the most common self-inflicted outage when rolling this out.

7. Restrict who can create connectors at all​

A data policy classifies connectors; it does not stop someone from standing one up. Turn on Managed Environments, lock down the default environment, and restrict maker sharing.

What this does not cover​

Be honest with stakeholders about the boundaries.

  • Copilot Studio's DLP is connector/server-level, not tool-level. You can allow or deny an entire MCP server. You cannot say "this agent may call read_file but not delete_file."
  • MCP tool surfaces drift. A maintainer who adds delete_user to a previously read-only server has silently added it to every agent that mounted that server — and no Power Platform control notices.
  • Scope. This governs what Copilot Studio agents reach through connectors and MCP. It does not govern Microsoft 365 Copilot's built-in Graph access, and it does not govern declarative agents built in Agent Builder. Those are different surfaces and belong to Purview. See Integrations & Connectors for Behavry's Purview integration.

Where Behavry earns its place​

Everything Microsoft gives you is an authorization control at the door. Behavry is what happens once the traffic arrives:

Microsoft-native controlBehavry adds
Allow / deny an entire MCP serverPer-tool, per-action policy — read_file allowed, delete_file blocked or escalated
No visibility into the tool surfaceA registry that pins and reviews the tool surface, so silent drift is caught
No per-action recordA tamper-evident Decision Trace per action, bound to the invoking human via OBO
No data inspectionDLP redaction and inbound injection detection on the traffic itself

That distinction — server-level versus tool-level — is precisely why the Microsoft-native control alone is not sufficient for a regulated buyer.

Sources​

Verified against Microsoft Learn on 2026-07-10. Microsoft changes this surface frequently; re-check before relying on specifics.