MCP is no longer experimental. Microsoft has published an official MCP server catalog and Copilot Studio now supports MCP tools natively. This significantly expands both the capability and the attack surface of enterprise agents.
Microsoft publishes a formal catalog of official MCP server implementations at github.com/microsoft/mcp. These include servers for Azure, GitHub, SharePoint, Teams, Outlook, SQL Server, and more. Copilot Studio agents can now use MCP tools directly — each tool added extends the agent's action surface to everything that MCP server can reach. The security implications scale with the permissions of the MCP server's connected services.
MCP defines how AI agents discover, connect to, and invoke tools, data sources, and services across a standard protocol. With Microsoft's official server catalog, MCP is now enterprise infrastructure — not a prototype technology.
When a Copilot Studio agent is configured with MCP tools, the agent authenticates to those MCP servers using maker credentials by default. This means:
| Attack | How It Works | Impact | Primary Control |
|---|---|---|---|
| Tool Poisoning | Malicious MCP server returns poisoned tool descriptions. Agent reads descriptions to decide which tool to invoke — poisoned descriptions redirect agent to attacker-controlled tools. | CRITICAL Full agent hijack | Foundry Guardrails (whitelist); Defender for Cloud Apps (MCP server governance) |
| MCP Server Impersonation | Attacker substitutes a malicious MCP server (DNS hijack, supply chain, local server swap). Agent connects to attacker's server and receives malicious tool outputs. | CRITICAL Data exfiltration, action hijack | Defender for Cloud Apps (MCP server registry); no cryptographic binding standard in MCP spec |
| Indirect Prompt Injection via MCP | Malicious instructions embedded in data returned by an MCP tool. Agent treats the embedded text as legitimate instruction and acts on it using maker credentials. | CRITICAL Data exfiltration, lateral movement | Prompt Shields (XPIA detection); Entra Internet Access Prompt Injection Protection (GA Mar 31 2026) |
| OAuth Scope Abuse | Agent inherits overly broad OAuth scopes from maker credentials when connecting to MCP-backed SaaS. Broad token enables lateral movement across multiple services. | HIGH Lateral movement across SaaS | Defender for Cloud Apps OAuth governance; enforce end-user auth per agent |
| Unauthenticated MCP Server | Many community MCP servers have no authentication. Any agent or attacker on the network can call them without credentials. | HIGH Unauthorised tool execution | Network segmentation; Entra Internet Access; security review of MCP server implementations |
| MCP Supply Chain Attack | Malicious package in MCP server registry. Enterprise deploys a compromised MCP server — attacker gains persistent access to the agent's tool layer. | HIGH Persistent backdoor in agent tooling | Defender for Cloud (supply chain scanning); Security Dashboard AI Inventory; GitHub Advanced Security |
| Unreviewed MCP Tool in Copilot Studio | Developer adds a community MCP server to a Copilot Studio agent without security review. Agent runs with maker credentials against unvetted tool surface. | HIGH Uncontrolled action surface | "MCP Tool Configured" Advanced Hunting query; enforce MCP tool lifecycle reviews |
The MCP specification (as of early 2026) does not mandate strong cryptographic authentication for MCP server-to-client binding. Microsoft's official MCP catalog servers use standard OAuth where supported, but third-party and community servers vary widely. There is no platform-enforced way to guarantee the MCP server an agent connects to is the legitimate, unmodified server it expects. This requires defence-in-depth at the network, CASB, and orchestration layers — no single product closes it.
| Layer | What It Covers | Microsoft Control | Status |
|---|---|---|---|
| Catalog governance | Vetting which MCP servers are approved for use; lifecycle reviews | Internal policy + "MCP Tool Configured" Advanced Hunting query | Process control — no product enforcement |
| Network | Control which MCP servers agents can reach; block malicious prompts | Entra Internet Access | GA Mar 31 2026 |
| Identity | Authenticate which agents can invoke which MCP tools; prevent maker credential blast radius | Enforce end-user auth (Power Platform admin) | Available now |
| Orchestration | Whitelist allowed tools per agent (Foundry only) | Foundry Guardrails | Preview · Foundry only |
| Content Inspection | Detect adversarial instructions in MCP tool outputs | Prompt Shields | GA |
| Runtime Protection | Block tool invocations during suspicious Copilot Studio agent activity | Defender for Cloud Apps real-time protection | Preview · Copilot Studio only |
| SaaS Governance | OAuth scope governance; anomalous API usage detection | Defender for Cloud Apps | GA |
| Inventory & Posture | Discover all MCP servers; assess risk | Security Dashboard for AI | Now GA |
| Investigation | NL querying of MCP entity relationships in Sentinel | Sentinel MCP Entity Analyzer | GA April |
While MCP governs how agents connect to external tools and data sources, A2A (Agent-to-Agent) is an emerging protocol for authenticated communication between agents themselves. Microsoft's Entra Agent ID platform now supports A2A for agent-to-agent discovery and authorisation — enabling orchestration agents to delegate tasks to sub-agents with verified identities. This is separate from MCP and addresses a different attack surface: the communication channels between agents in multi-agent architectures.
Copilot Studio agent chains, Power Automate flows that call agents, and custom orchestration built on Microsoft Foundry typically have no formal A2A authentication. This means a compromised orchestrator can issue malicious delegations to sub-agents without any identity check. Until A2A becomes standard, treat every inter-agent boundary as an untrusted boundary and apply least-privilege scoping per agent.
As of late 2025, Microsoft has shipped or previewed several first-party MCP servers, each with different security boundaries and trust models. Understanding what each one is — and where the authoritative auth/audit lives — is critical for designing safe MCP integrations.
| MCP server | What it provides | Auth / boundary | Status |
|---|---|---|---|
| Microsoft Sentinel MCP server | Scenario-focused collections of security tools — query Sentinel data lake and Defender in natural language, build security agents, automate triage and threat hunting. Includes Security Copilot agent creation tools. | Fully hosted by Microsoft. Microsoft Entra for identity. No infrastructure deployment needed. | Available |
| Microsoft Learn MCP server | Three tools: microsoft_docs_search, microsoft_docs_fetch, microsoft_code_sample_search. Searches official Microsoft docs. | Hosted by Microsoft. Authless. | Available at learn.microsoft.com/api/mcp |
| Foundry MCP integration (client side) | Foundry agents consume remote MCP servers. Each tool added with unique server_label + server_url. Some pre-validated MCP servers (e.g. Azure DevOps) are in the Foundry Add Tools catalog. | Custom headers (including auth tokens) pass per-run only — not persisted. Foundry approval and audit mechanisms apply. | Available |
| Windows On-device Agent Registry (ODR) | Local registry of MCP servers on Windows endpoints. Apps and agents discover MCP servers via the ODR. Includes built-in connectors (e.g. File Explorer MCP). | MCP servers run in contained environment by default. User and IT admin control via Windows Settings and Intune. Logging and auditing for client↔server interactions. | Preview |
| Copilot Studio MCP onboarding wizard | Add existing MCP servers to Copilot Studio agents via guided OAuth wizard. Generates callback URLs for identity provider registration. Handles authorization code → access token → refresh token flow. | Per-agent OAuth 2.0 configuration. Identity provider remains the trust anchor. | Available |
| Microsoft Agent Framework MCP tools | .NET/Java/Python SDKs for connecting custom agents to MCP servers, including local MCP servers. Used to build framework-based agents. | Developer chooses transport and auth; Microsoft provides SDK primitives. | Available |
Microsoft repeatedly cites two sources across all MCP-related docs: (1) MCP Security Best Practices on the Model Context Protocol website, and (2) the Microsoft Security Community Blog post Understanding and mitigating security risks in MCP implementations. Both are required reading for anyone integrating MCP into an enterprise estate.
From Microsoft's own Agent Framework documentation: "The remote MCP servers that you decide to use with the MCP tool described in this article were created by third parties, not Microsoft. Microsoft hasn't tested or verified these servers. Microsoft has no responsibility to you or others in relation to your use of any remote MCP servers." This is the framing to use when third-party MCP servers come up in governance discussions — Microsoft treats them as supply-chain risk you own. Recommended: track every MCP server added to any agent in your estate, rely on servers hosted by trusted providers (not proxies), and log all data shared with remote MCP servers for auditing.
The Windows On-device Agent Registry is the local equivalent of what Entra Agent Registry does for cloud agents — it tracks MCP servers on Windows endpoints. Key security properties: MCP servers run contained by default (separate environment, can only access approved resources), users and IT admins control access per agent via Windows Settings or Intune, and interactions between MCP clients and servers are logged and auditable. The odr.exe command-line tool lets users and admins view and manage MCP servers. For endpoints where users may install MCP-enabled apps, this is the control point to manage centrally.
Until June 2026, MCP clients running on developer endpoints — GitHub Copilot CLI, Claude Code, OpenAI Codex, OpenClaw — were largely outside the reach of Microsoft's central security tooling. Activity happened on a developer's laptop and stayed there. Purview's local & endpoint agents preview (June 2026) changes this. The same DSPM, DLP, and Insider Risk capabilities that govern cloud-side agents now extend to these local agents, with full interaction context flowing back to Purview.
Four protections come together: (1) DSPM visibility into prompts, responses, and actions taken by the local agent; (2) real-time DLP enforcement during execution — sensitive content can be blocked mid-flow; (3) Insider Risk signal generation from risky local-agent behaviour (data being moved out of policy boundaries); (4) full interaction logs in the unified audit log for forensics. This is the same governance plane that already covers cloud Copilot and Foundry agents — extended to the build environment.
Why it matters: developers using Claude Code or GitHub Copilot CLI to ground an agent against sensitive source code, internal docs, or production data were a real gap. The data left the corporate perimeter via the agent and Purview had no view. This closes that gap for any MCP client Microsoft supports as a local-agent endpoint. See Purview for Local & Endpoint Agents on the product map for full details.
Build 2026 introduced a new agent-runtime vocabulary worth knowing for any security architect designing for local AI agents.
| Concept | Definition | Security implication |
|---|---|---|
| OpenClaw | A self-hosted agent runtime that runs on a workstation, VM, or container. Loads skills and interacts with local and cloud resources. Open-source. | Inherits the trust (and risk) of the machine and the identities it can use. Same operational model as installing a desktop application with elevated privileges. |
| Claws | Skills loaded into OpenClaw. Each claw is a discrete capability — read files, query a database, call an API, write code. Composed by the user to build a working agent. | Installing a skill is basically installing privileged code. The skill operates inside the OpenClaw runtime with the user's permissions to local apps, files, and accounts. |
| ClawHub | Public skills registry for OpenClaw. Skills are discovered and installed through ClawHub — by search, by recommendation, by community channels. | Supply chain attack surface. Microsoft Threat Intelligence has already observed attackers publishing malicious skills disguised as utilities, and promoting them through community channels. Skills can also be discovered organically via search and installed by users who don't recognise the risk. |
| OpenClaw on Windows via MXC | Windows node and gateway for OpenClaw run inside Microsoft Execution Containers (MXC). Windows companion app available to set up and connect claws. Available open-source. | Containment is now native to the platform on Windows — the OpenClaw runtime can't reach beyond what MXC policy permits. Compare to running OpenClaw bare on a developer's machine where the runtime has whatever permissions the user has. |
The same threat model applies as for npm, PyPI, VS Code Marketplace, or any other third-party code source. Microsoft's February 2026 OpenClaw security research documented the pattern: malicious skills disguised as utilities, organic discovery via search, social engineering via community channels. Recommended controls before any developer team adopts OpenClaw: maintain an approved-claws list, prefer skills from verified publishers, run OpenClaw inside MXC on Windows (not bare), and ensure Purview's local-agent observability is enabled so risky behaviour at skill execution time generates Insider Risk signals.
MXC SDK is a new layer introduced at Build 2026 that sits between the agent runtime and the OS. Developers declare what an agent can access (files, network, processes) and MXC enforces those declarations at runtime. The model is similar to seccomp on Linux or App Container on Windows, but designed specifically for agentic workloads where behaviour is non-deterministic.
MXC offers a spectrum of isolation semantics — light containment when an agent's task is low-risk, full sandboxing when it touches sensitive data or invokes high-impact tools. Composition is dynamic: a single agent can run light when summarising a doc and switch to strict containment when invoking a connector that could exfiltrate data. The point: containment policy follows the operation, not the agent identity.
Agent 365 + MXC integration (Preview, July 2026) brings Defender, Entra, Intune, and Purview protections through MXC so agents start secure and stay secure. This is the moment when the four governance pillars (identity, threat, device, data) converge at the runtime boundary for local agents — not just cloud agents.
Microsoft Threat Intelligence identified a prompt injection pathway in the Claude Code GitHub Action that allowed access to workflow secrets under specific conditions (research published February 2026). The attack pattern: untrusted content (e.g., an issue body) becomes input to the agent's prompt; the injected prompt redirects the agent to dump secrets.* values or call out to attacker-controlled endpoints. The fix in CI/CD: treat any LLM agent invocation as a trust boundary — never pass untrusted content directly into prompts that have access to secrets, and scope GITHUB_TOKEN permissions to the minimum the agent actually needs. This is the same threat class as Threat Scenario 6 (XPIA via untrusted data sources), manifesting in a code-automation context.
Microsoft Defender for Endpoint now discovers and protects local AI agents on Defender-onboarded Windows endpoints — treating each agent as a first-class security asset rather than just an OS process. Per the authoritative Microsoft Learn local agent discovery page, Defender currently identifies five categories of local AI agents. Many of these are MCP clients — the inventory is the central place to see what agents users have installed and what MCP server configurations they've added.
| Category | Agents discovered today |
|---|---|
| CLI agents | Claude Code · Codex CLI · Gemini CLI · GitHub Copilot CLI · OpenCode · Antigravity CLI |
| Desktop apps | ChatGPT Desktop · Claude Desktop · Codex Desktop · Ollama Desktop · Poe Desktop |
| Agentic IDEs | Cursor · Antigravity IDE · Windsurf |
| VS Code extensions | Claude Code · Cline · Codex · Gemini Code Assist · GitHub Copilot · Roo Code |
| Claw-based agents | OpenClaw · Clawpilot · Claw/Nanobot |
An agent is the combination of user + device + agent type. So if Claude Code runs in 15 different project folders on the same user/device, it's one agent in the inventory — not 15. This keeps the inventory tractable while still giving SOC analysts the dimensions they need to pivot during investigation (which user is running what on which machine).
Three views available in the Microsoft Defender portal:
Discovery surfaces what's running; runtime protection stops malicious instructions before the agent acts on them. Per the AI agent runtime protection overview, Defender inspects three points in the agent loop where content enters or leaves reasoning:
| Hook point | What Defender inspects | What's caught |
|---|---|---|
| ① User prompt | The prompt submitted to the agent | Direct prompt injection via user input |
| ② Pre-tool call | The tool invocation request before execution | Hidden instructions in fetched content (file, web page, repo) attempting to redirect a tool call |
| ③ Post-tool response | The tool response after execution completes | Tool output containing injection payload aimed at the next reasoning step |
Defender uses each agent's published hooks framework (Claude Code hooks, GitHub Copilot CLI hooks) — Defender registers as a hook consumer at the three inspection points. This means added latency is minimal because each scan is a fast inline check, not continuous monitoring of the agent process.
Modes: Block (Defender stops the action, notifies the user via agent UI + Windows toast, raises an alert correlated into Defender incidents; the detection is also recorded in Defender protection history on the device); Audit (action continues, alert still raised — recommended starting mode); Disabled. The setting is protected by Tamper Protection so it can't be silently disabled. Alert name: Suspicious AI prompt injection. Once enabled, Defender inspects supported agents at their hook points without changing how users run the agent — no wrapping, no interception of the agent process, no behavioural change to the developer workflow.
Currently supported agents for runtime protection: Claude Code, GitHub Copilot CLI. Coverage expanding — any agent that exposes a hooks framework can in principle be added. Worth noting: until coverage broadens, runtime protection is a meaningful capability only for organisations whose developers actually use these two specific tools. Discovery (above) covers the much broader 20+ list.
"A coding agent fetches a project's documentation to answer a question, and the page contains hidden text that instructs the agent to read the local .env file and post its contents to an external URL. The agent treats the instruction as part of the page and is about to comply, but Defender detects the prompt injection in the tool response and blocks the action before any data leaves the device."
This is the canonical local agent threat — and the canonical case for why runtime protection earns its place in any tenant where developers use Claude Code or GitHub Copilot CLI against real production data.
Per the configuration guide, enabling runtime protection isn't a single switch — it has prerequisites, a recommended phased rollout, and PowerShell-only enablement today.
The most important constraint: runtime protection is currently available only on devices configured to receive Beta platform and engine updates. Production fleets on the standard ring won't see the capability. Other prerequisites are routine — devices onboarded to Defender for Endpoint, Defender Antivirus in active mode, supported local AI agent installed, agent natively supports a hooks framework (Claude Code or GitHub Copilot CLI today). Minimum AntivirusSignatureVersion is 1.451.224.0.
In Audit mode, alerts are Informational severity — your team can review what would have been blocked without triaging it as an active threat. In Block mode, alerts carry a Critical / High / Medium / Low severity based on assessed risk. Plan SOC capacity accordingly.
There is no native Intune configuration profile for runtime protection at present. Single-device enablement is via PowerShell:
# Switch to Beta channel
Set-MpPreference -PlatformUpdatesChannel Beta
Set-MpPreference -EngineUpdatesChannel Beta
# Force signature refresh (run 3 times per Microsoft's guidance)
Update-MpSignature; Update-MpSignature; Update-MpSignature
# Verify signature version >= 1.451.224.0
Get-MpComputerStatus | Select-Object AntivirusSignatureVersion
# Enable runtime protection (Disabled / Audit / Block)
Set-MpPreference -AiAgentProtection Audit
# Verify current setting
Get-MpPreference | Select-Object AiAgentProtection
For fleet deployment, wrap this in a PowerShell script and deploy via Intune's PowerShell scripts feature (not a configuration profile). Same command, scaled to device groups.
Two notifications appear in parallel:
Users can also review detections under Windows Security > Virus & threat protection > Current threats / Protection history — same surface as other Defender detections. This means runtime protection events look familiar to users who've seen any other Defender intervention.