Can you please explain to us how we can connect Azure Copilot to our custom MCP server running in our Azure environment ?

Question

Can you please explain to us how we can connect Azure Copilot to our custom MCP server running in our Azure environment ?

Turic, Mario 0

We are running our own custom MCP server on an Azure Function app service inside our private network architecture all in Azure. We want to connect to this custom MCP server over multiple MCP client application like Azure Copilot.

Can you please give us a proper documentation and/or step by step guide how we can achieve this ?

Thank you,

Mario Turic

Vinodh247-1375 43,911 Reputation points Volunteer Moderator

2026-02-09T15:42:14.69+00:00

Hi ,

Thanks for reaching out to Microsoft Q&A.

MCP is currently a Copilot-internal protocol, not a public extension point. If your goal is “multiple MCP clients including Azure Copilot”, you must treat MCP as an internal abstraction and expose a Copilot-friendly API facade. Until ms officially opens MCP server registration, this is the only viable, enterprise-grade approach.

Today, Copilot cannot directly connect to a custom MCP server that you host inside your Azure private network. There is no supported or doc way to “register” an external MCP server (custom or self-hosted) with Copilot in the same way you register plugins or connectors. Copilot only talks to MCP endpoints that MS explicitly enables and hosts as part of its Copilot runtime.

What is supported is this architecture instead?

You expose your MCP server through a Copilot-supported integration layer, not directly. Practically, this means you wrap your MCP server behind an APIM or HTTPS REST API, secure it with Microsoft Entra ID (OAuth2/MI), and then surface it to Copilot via one of the supported paths: Copilot plugins (for M365 Copilot), Graph connectors, or Azure AI Studio tools / function calling (for custom copilots). Azure Copilot never talks MCP natively; it talks HTTP + auth + schema.

Please 'Upvote'(Thumbs-up) and 'Accept' as answer if the reply was helpful. This will be benefitting other community members who face the same issue.
Anonymous

2026-02-10T10:48:04.7633333+00:00

Hi Turic, Mario

Did you get any chance to review the above response.

Thank you!
Turic, Mario 0 Reputation points

2026-02-10T15:44:50.1166667+00:00

Dear Sridhar and Vinodh,

I need to clarify and point to the fact that we need to connect Azure Copilot (agent) inside our private network with our MCP server inside our private network - currently this is not working and we need to resolve the issue.

Can you please support us to connect all of these resources inside our Azure private network without any public internet exposure ?

Thank you and kind regards,

Mario Turic
Anonymous

2026-02-10T17:06:42.14+00:00

Hi Turic, Mario

You are attempting to connect an Azure Copilot / Azure AI Foundry Agent to a custom MCP server that is deployed inside an Azure private virtual network, with no public internet exposure. This connection is not working, even though networking, DNS, NSGs, and Private Endpoints are correctly configured

This failure is not caused by customer misconfiguration. It is due to a current platform limitation in Azure Copilot / Azure AI Foundry Agents. Agents today run on Microsoft‑managed infrastructure and do not execute inside customer VNets.

Azure Copilot / Foundry Agents initiate outbound calls from Microsoft‑managed public egress. These outbound calls do not originate from your VNet, do not use your route tables, and cannot resolve or reach private IP addresses inside customer networks.

Private Endpoints only work when both sides participate in the same VNet or peered VNets. Since the agent itself is not VNet‑injected, it cannot resolve private DNS zones (privatelink.*), cannot reach internal load balancers, and cannot access private IPs.

This makes direct Agent → MCP private connectivity impossible today.

Azure does not currently support:

• Agent outbound calls through customer VNets

• Agent access to Private Endpoints for custom APIs •

Agent → MCP server communication using only private IP connectivity

• Fully private, zero‑public‑exposure architectures for custom MCP tools

This is a platform capability gap, not a fixable deployment issue.

Supported workaround patterns (current reality):

The only supported architectures today require some form of controlled public endpoint, for example:

• Exposing the MCP server via HTTPS with strong authentication (AAD / Managed Identity) • IP allow‑listing Azure AI service ranges

• Using Azure Application Gateway or Front Door with WAF • A relay pattern where a public Azure Function or API forwards traffic privately to the MCP server inside the VNet

These patterns are commonly accepted in regulated environments, even though they are not “fully private”.

Microsoft has publicly signaled future interest in VNet‑isolated agent execution and private outbound connectivity, but no GA feature, timeline, or SLA exists today. This requirement should be treated as a feature request
Anonymous

2026-02-12T10:51:47.7066667+00:00

Hi Turic, Mario

please find the details requested through private message
Turic, Mario 0 Reputation points

2026-02-12T19:32:31.12+00:00

I did not receive any kind of private message @Sridhar M
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Turic, Mario 0 Reputation points

2026-02-13T10:03:41.1133333+00:00

Additional questions from our side would be @Anonymous - wich IT security threats ? and Security risks ? we will get if we provision an public endpoint to establish the proposed Supported workaround patterns (current reality) from your recommendations in this ticket ?

Can you please also give us an overview about those and what we should be very careful and serious about when provisioning the secured public endpoint ? Thank you
Anonymous

2026-02-13T10:30:50.2533333+00:00

Hi Turic, Mario

If your uisng Azure Copilot to custom MCP please follow the documentation.

https://learn.microsoft.com/en-us/microsoft-copilot-studio/mcp-add-existing-server-to-agent
Anonymous

2026-02-13T16:07:44.4766667+00:00

Hi Turic, Mario

When you expose a public endpoint, the service becomes reachable from the entire internet. Even if authentication is enforced, the endpoint becomes discoverable and potentially targetable by automated bots, scanners, and attackers. This increases your overall attack surface compared to private endpoints, private networks, or VNet‑isolated architectures.

A publicly reachable endpoint can be subjected to Distributed Denial of Service (DDoS) attacks, where attackers overload your service with massive amounts of traffic. This can lead to outages, slow response times, or increased cost consumption. Azure DDoS Protection Standard, traffic throttling, and rate-limiting rules are essential defenses.

Any internet-facing service naturally becomes a target for brute‑force logins, token misuse, API key theft attempts, and credential-stuffing attacks. Even if your service uses token-based or Entra ID-based authentication, attackers will continuously attempt to guess or exploit authentication mechanisms. Strong authentication and short-lived tokens are critical.

Public APIs are frequently probed with malicious payloads attempting SQL injection, command injection, deserialization attacks, or prompt injection (especially in AI workflows). Without strong validation, an attacker may influence backend behavior or extract sensitive data. Strict schema validation and sanitization are mandatory.

API Abuse and Excessive Invocation:

Attackers or misconfigured scripts may send high volumes of legitimate requests at high frequency. Even if authenticated, this can cause unexpected cost spikes, quota exhaustion, or degraded performance of dependent AI/agent systems. Rate limiting, quotas, and usage monitoring are required to prevent uncontrolled API use.

If TLS is misconfigured or outdated cipher suites are enabled, attackers may intercept or manipulate traffic. This can lead to data leakage or credential exposure. Enforcing TLS 1.2/1.3, proper certificate rotation, and disabling legacy protocols greatly reduces this risk.

Public endpoints are continuously scanned by automated tools such as Shodan, masscan, and botnets. These probes attempt to gather information about technologies used, open ports, or configuration weaknesses. Minimizing header information, hiding stack traces, and enabling WAF bot protection mitigates reconnaissance exposure.

Exposing a public endpoint introduces real attack vectors such as DDoS, brute-force attempts, injection attacks, API abuse, and reconnaissance scanning. Operational risks include data leakage, misconfiguration errors, cost spikes, and compliance violations. With proper compensating controls—API gateway, WAF, Entra ID protection, rate limits, monitoring, and zero-trust enforcement—a public endpoint can be secured, but you must treat it as a high-exposure component.

2 answers

Your answer

Vinodh247-1375 43,911 Reputation points Volunteer Moderator

2026-02-09T15:42:14.69+00:00

Hi ,

Thanks for reaching out to Microsoft Q&A.

MCP is currently a Copilot-internal protocol, not a public extension point. If your goal is “multiple MCP clients including Azure Copilot”, you must treat MCP as an internal abstraction and expose a Copilot-friendly API facade. Until ms officially opens MCP server registration, this is the only viable, enterprise-grade approach.

Today, Copilot cannot directly connect to a custom MCP server that you host inside your Azure private network. There is no supported or doc way to “register” an external MCP server (custom or self-hosted) with Copilot in the same way you register plugins or connectors. Copilot only talks to MCP endpoints that MS explicitly enables and hosts as part of its Copilot runtime.

What is supported is this architecture instead?

You expose your MCP server through a Copilot-supported integration layer, not directly. Practically, this means you wrap your MCP server behind an APIM or HTTPS REST API, secure it with Microsoft Entra ID (OAuth2/MI), and then surface it to Copilot via one of the supported paths: Copilot plugins (for M365 Copilot), Graph connectors, or Azure AI Studio tools / function calling (for custom copilots). Azure Copilot never talks MCP natively; it talks HTTP + auth + schema.

Please 'Upvote'(Thumbs-up) and 'Accept' as answer if the reply was helpful. This will be benefitting other community members who face the same issue.
Anonymous

2026-02-10T10:48:04.7633333+00:00

Hi Turic, Mario

Did you get any chance to review the above response.

Thank you!
Turic, Mario 0 Reputation points

2026-02-10T15:44:50.1166667+00:00

Dear Sridhar and Vinodh,

I need to clarify and point to the fact that we need to connect Azure Copilot (agent) inside our private network with our MCP server inside our private network - currently this is not working and we need to resolve the issue.

Can you please support us to connect all of these resources inside our Azure private network without any public internet exposure ?

Thank you and kind regards,

Mario Turic
Anonymous

2026-02-12T10:51:47.7066667+00:00

Hi Turic, Mario

please find the details requested through private message
Turic, Mario 0 Reputation points

2026-02-12T19:32:31.12+00:00

I did not receive any kind of private message @Sridhar M
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Turic, Mario 0 Reputation points

2026-02-13T10:03:41.1133333+00:00

Additional questions from our side would be @Anonymous - wich IT security threats ? and Security risks ? we will get if we provision an public endpoint to establish the proposed Supported workaround patterns (current reality) from your recommendations in this ticket ?

Can you please also give us an overview about those and what we should be very careful and serious about when provisioning the secured public endpoint ? Thank you
Anonymous

2026-02-13T10:30:50.2533333+00:00

Hi Turic, Mario

If your uisng Azure Copilot to custom MCP please follow the documentation.

https://learn.microsoft.com/en-us/microsoft-copilot-studio/mcp-add-existing-server-to-agent

Answer 1

Hi Turic, Mario

We can connect our MCP server via tools from Agents we are creating.

Go to your created Agent, and click on tools

Screenshot 2026-02-16 144515

Select MCP tool and add details of MCP server.

Screenshot 2026-02-16 145141

Ideally to communicate within virtual network, all azure resources need to be virtual network. If you hosted any MCP server, please bring it to Virtual network via Private endpoint or VNET whitelisting.

In case of Bring your own VNET scenarios, you can modify the inbound and outbound rules from your network security group and route table.

https://learn.microsoft.com/en-us/microsoft-copilot-studio/admin-network-isolation-vnet

You can also create a custom MCP connection through PowerApp as discussed in below documentation.

Connect your agent to an existing Model Context Protocol (MCP) server - Microsoft Copilot Studio | Microsoft Learn

Troubleshooting Model Context Protocol (MCP) integration - Microsoft Copilot Studio | Microsoft Learn

Regarding Security aspect

You can follow this document to secure with virtual network.

Use Virtual Network support for agent calls to private endpoints - Microsoft Copilot Studio | Microsoft Learn

We can check content filtering, prompt, Data compliance policies (GDPR) which can be configured from admin center.

You can also audio logs from Microsoft Purview.

Customer can also use customer managed keys

Attached relevant documentation for reference.

Agent runtime protection status - Microsoft Copilot Studio | Microsoft Learn

Data, privacy, and security for web search - Microsoft Copilot Studio | Microsoft Learn

View audit logs for admins, makers, and users of Copilot Studio - Microsoft Copilot Studio | Microsoft Learn (Audit logs from Microsoft purview)

View sensitivity labels in agent responses - Microsoft Copilot Studio | Microsoft Learn (Apply Sensitivity labels on Share point resources)

Please accept this answer as verified one if you appreciated our inputs.

Thank you.

Manas R Mohanty 17,270 Reputation points Moderator

2026-02-17T13:47:39.06+00:00

Hi Turic, Mario,

I have tried to address all your queries in above answer.

Please take a minute to mark this verified if you found it helpful.

Sorry for any inconvenience caused during investigation.

Thank you.

Answer 2

Hi Turic, Mario

Connecting Azure Copilot to a custom MCP server means enabling Copilot (via Copilot Studio, Microsoft 365 Copilot agents, or Azure AI Foundry agents) to call backend tools exposed through the Model Context Protocol (MCP). In this architecture, Copilot acts as an MCP client, while your custom MCP server runs as a secure HTTPS service in Azure and exposes tools that Copilot can dynamically discover and invoke at runtime.

Microsoft Copilot does not directly call internal APIs or databases. Instead, Copilot communicates through MCP servers using the Power Platform connector infrastructure. MCP standardizes tool discovery, invocation, and response formats so that Copilot agents can reason about which tools to call without hard‑coding API contracts. This allows one MCP server to be reused across Copilot Studio agents, Microsoft 365 Copilot agents, Azure AI Foundry agents, and even VS Code Copilot.

Microsoft supports hosting custom MCP servers on Azure App Service, Azure Functions, Azure Container Apps, or Kubernetes, as long as the server exposes an HTTPS endpoint and supports the Streamable HTTP transport. Server‑Sent Events (SSE) are deprecated and no longer supported by Copilot Studio. The MCP server must remain continuously reachable over HTTPS so Copilot can fetch tool metadata and invoke tools on demand.

Copilot services run outside customer virtual networks. Because of this, Copilot cannot directly access private endpoints, private IPs, or internal load balancers. Any MCP server that Copilot connects to must be reachable through a public HTTPS endpoint. This is a critical architectural constraint and often misunderstood when designing “private‑only” deployments.

Recommended enterprise network architecture:

The recommended enterprise pattern is to expose the MCP server publicly while keeping sensitive dependencies private. This is commonly achieved by placing Azure API Management (APIM) in front of the MCP server. APIM provides a public HTTPS endpoint for Copilot while forwarding traffic into a VNet‑integrated backend. Web Application Firewall (WAF), IP restrictions, throttling, logging, and token validation can all be enforced at the APIM layer.

Alternative public endpoint pattern without APIM:

For simpler deployments, the MCP server can be hosted directly on Azure Functions or App Service with a public endpoint. In this pattern, security is enforced using OAuth 2.0 (Microsoft Entra ID) or API keys. Network isolation is achieved by ensuring that only downstream resources (databases, storage, internal APIs) remain private, while the MCP server itself is hardened and monitored.

MCP authentication options supported by Copilot:

Copilot Studio supports two authentication models when connecting to an MCP server. The first is API key authentication, which is simple and suitable for development or internal tools. The second, recommended for production, is OAuth 2.0 using Microsoft Entra ID. OAuth enables per‑user authorization, Conditional Access policies, audit logging, and on‑behalf‑of (OBO) flows for Microsoft 365 Copilot.

MCP server functional requirements:

A valid MCP server must support tool discovery, tool invocation, and structured JSON responses. Tools must include clear natural‑language descriptions, input schemas, and output schemas so Copilot can reason about them. Resources and prompts are optional, but tools are required. The server must implement the Streamable HTTP transport and expose a stable MCP endpoint path.

Copilot Studio connects to the MCP server:

In Copilot Studio, the MCP server is added through the “Add tool → Model Context Protocol” experience. During onboarding, you provide the MCP server URL, a description of its capabilities, and authentication details. Copilot Studio automatically discovers tools from the server and makes them available to the agent without manual schema mapping or connector definitions.

Copilot cannot access private endpoints directly, so MCP servers must be publicly reachable over HTTPS. Security is achieved through OAuth 2.0, APIM, and layered defense rather than network isolation alone. MCP enables clean separation between Copilot reasoning and enterprise business logic, making it the recommended integration model for Azure‑hosted tools.

I Hope this helps. Do let me know if you have any further queries.

Thank you!

Philipp R 1 Reputation point

2026-06-24T07:27:31.2733333+00:00

I just try to get this working, and it is very frustrating.
We have Copilot Enterprise from Microsoft, Azure from Microsoft, Implemented a MCP with the Microsoft template, the PowerAutomate Connection looks like a bad workaround for something that should be two clicks. Now I have to assemble myself Urls for Token, Auth and Refresh this can be the best way.
There should be a MCP Server registry on Azure side and a Connect Wizard on Copilot side.