Connect Microsoft Defender XDR to Copilot Studio

AI agents are particularly useful when they can not only answer general questions but also access a company’s actual security data.

This is exactly where the Model Context Protocol, or MCP for short, comes into play. Using MCP, we can provide an agent with tools that enable it, for example, to query incidents, alerts, devices, users or advanced hunting results from Microsoft Defender XDR.

In this post, I’ll show you how to deploy your own Defender XDR MCP server in your own Azure and Microsoft 365 tenant and then connect it to Copilot Studio using an agent. The server runs on Azure Container Apps. Access is granted within the user’s context and continues to be governed by the logged-in user’s existing Entra and Defender roles. The MCP server therefore does not become a new super-administrator in the tenant.

The deployment comprises the following Az resources:

• Azure Container Registry and Container Apps
• Azure Key Vault
• Log Analytics Workspace and Application Insights
• Server App Registration for the MCP API
• Copilot client app registration for logging in

Copilot Studio logs the user in via Microsoft Entra ID and passes the access token to the MCP server. The server validates the token and calls Microsoft Graph, the Defender for Endpoint API and, optionally, the Defender for Cloud Apps API on behalf of the logged-in user.

Important: The server does not store user tokens. The information a user can access and the actions they can perform continue to depend on their Entra, Defender and, where applicable, Sentinel roles.

First, download the MCP server from this GitHub repository. The organisation-specific settings are located in the file deploy.settings.psd1. When run for the first time, the deployment script automatically generates this file from the template deploy.settings.example.psd1. 

However, I would recommend creating the file yourself before the first deployment:

Copy-Item deploy.settings.example.psd1 deploy.settings.psd1

You can then adjust the settings to suit your environment. The most important settings include:

ResourceGroup = 'rg-defender-mcp-prod'Location = 'westeurope'
ContainerApp = 'ca-defender-mcp-prod'ContainerAppsEnvironment = 'cae-defender-mcp-prod'LogAnalyticsWorkspace = 'log-defender-mcp-prod'
AppRegEnvironment = 'prod'AllowedGroupIds = @()

If you use your own naming conventions, now is the right time to enter them. For Container Registry and Key Vault, the names can be generated automatically. This is useful, as both names must be globally unique.

Next, we log in to the correct tenant using the Azure CLI and select the required subscription:

az login --tenant <tenant-id></tenant-id>az account set --subscription <subscription-id></subscription-id>

The script checks whether the logged-in tenant matches the TenantId Anyone who regularly switches between several tenants or test environments will understand why a check like this is useful.

We start the actual deployment with the following command:

./deploy.ps1 -ConfigureAppRegistration

If you also want to enable actions and write permissions, use the following command:

./deploy.ps1 -ConfigureAppRegistration -GrantWritePermissions

On the first run, the script first checks:

• PowerShell, Azure CLI and Bicep version
• Azure login, tenant and subscription
• Deployment settings
• Required resource providers

The Azure resources, the container image and the two app registrations are then created or configured. The server app’s client secret and the signing key are stored directly in Key Vault and do not appear in the console output.

Finally, the script carries out a smoke test and outputs the values we’ll need for Copilot Studio in the next step. You can also run the script again. Existing resources will be reused and any missing components will be added.

Let’s now move on to the interesting bit: connecting to Copilot Studio. Open the agent you want and navigate to: Tools > Add Tool > Model Context Protocol.

Enter the endpoint generated by the deployment script as the server URL:

https://<container-app>.<domain>/mcp</domain></container-app>

For authentication, we select OAuth 2.0 > Manual. You will find the actual values in the output of the deployment script. Here is an example:

You must generate the client secret manually in the client app and then enter it in the settings in Copilot Studio. Once saved, Copilot Studio will display a redirect URL. You can add this using the following command:

./deploy.ps1 -AddRedirectUri '<redirect-url>'</redirect-url>

We then establish the connection and log in.

AllowedGroupIds = @( 

 '<security-group-id>'</security-group-id>

)

The script assigns the groups to both Enterprise Apps and enables ‘Assignment required’.

Following a successful functional test, network access can also be restricted to the Power Platform Connector ranges:

./deploy.ps1 -RestrictIngressToPowerPlatform

Before doing so, you should check the audit log to see which IP addresses the connector calls are actually coming from.

With the Defender XDR MCP Server, we can make Defender data and administrative security functions available as tools in Copilot Studio.

In my view, what matters here is not just that the agent can access the data. What is crucial is how this access is implemented:

• Sign in via Microsoft Entra ID
• Views in the context of the user
• No storage of user tokens
• Implementation of the existing Entra and Defender roles
• Separate read and write permissions
• Confirmation before carrying out administrative actions
• Restrictions via groups and network rules
• Auditing tool calls

This means we do not end up with a security agent with blanket authorisation, but rather one that operates within the existing structure of roles and permissions. Or to put it another way: the agent can do a great deal. But only what the logged-in user is already permitted to do.