Microsoft’s Build developer conference is under way in Seattle, where the company has revealed plans to make the Model Context Protocol (MCP) a native component of Windows, despite concerns over the security of the fast-expanding MCP ecosystem.

MCP is a protocol introduced by Anthropic just 6 months ago. It was originally presented as a means for AI-powered applications to access data in diverse systems, but soon evolved into a protocol for more general automation. Based on JSON-RPC 2.0, the protocol allows MCP servers running locally or remotely to report their capabilities and to accept commands to perform them.

In the context of Windows, it is easy to see the value of a standardised means of automating both built-in and third-party applications. A single prompt might, for example, fire off a workflow which queries data, uses it to create an Excel spreadsheet complete with a suitable chart, and then emails it to selected colleagues.

Microsoft is preparing the ground for this by previewing new Windows features. 

• First, there will be a local MCP registry which enables discovery of installed MCP servers. 
• Second, built-in MCP servers will expose system functions including the file system, windowing, and the Windows Subsystem for Linux. 
• Third, a new type of API called App Actions enables third-party applications to expose actions appropriate to each application, which will also be available as MCP servers so that these actions can be performed by AI agents. According to Microsoft, “developers will be able to consume actions developed by other relevant apps,” enabling app-to-app automation as well as use by AI agents.

Microsoft named Anthropic, Figma and Perplexity among those who are integrating MCP functionality into their Windows apps, and for App Actions, third-party developers including Zoom, Todoist and Spark Mail.

MCP servers are a powerful concept but vulnerable to misuse. Microsoft corporate VP David Weston noted seven vectors of attack, including cross-prompt injection where malicious content overrides agent instructions, authentication gaps because “MCP’s current standards for authentication are immature and inconsistently adopted,” credential leakage, tool poisoning from “unvetted MCP servers,” lack of containment, limited security review in MCP servers, supply chain risks from rogue MCP servers, and command injection from improperly validated inputs.

According to Weston, “security is our top priority as we expand MCP capabilities.” Microsoft plans the following security controls:

1. A proxy to mediate all MCP client-server interactions. This will enable centralized enforcement of policies and consent, as well as auditing and a hook for security software to monitor actions.
2. A baseline security level for MCP servers to be allowed into the Windows MCP registry. This will include code-signing, security testing of exposed interfaces, and declaration of what privileges are required.
3. Runtime isolation through what Weston called “isolation and granular permissions.” 

Microsoft is promising an early preview of Windows MCP capabilities to developers following the Build event, use of which will require Windows to be developer mode. Not all security features will be in the preview.

The company, along with GitHub, has also joined the official MCP steering committee, and is collaborating with Anthropic and others on an updated authorization specification as well as a future public registry service for MCP servers.

We should also mention the new project, also unveiled at Build, called NL (Natural Language) Web, which enables web sites and applications to expose content via natural language queries. NLWeb was conceived by Ramanathan V. Guha, formerly at Google but now a technical fellow at Microsoft, who is credited with the creation of the RDF (Resource Description Framework) standard. It is relevant here because Microsoft said that “every NLWeb instance is also an MCP server.”

One way to think about MCP and App Actions in Windows is as a new way to automate both Windows and other applications. DevClass may not be alone in finding some aspects reminiscent of COM (component object model) and all its derivatives, which already enables app-to-app communication and automation in Windows, but via a binary interface rather than JSON-RPC, and at a lower level of abstraction. COM is powerful but has also proved a security problem during its long history, most notably with ActiveX in Internet Explorer, and with OLE Automation in Office, both of which were widely abused.

While it is reassuring that Microsoft has put security at the top of its MCP agenda, both developers and enterprises will be wary. As Weston put it, “MCP opens up powerful new possibilities – but also introduces new risks.”