The first building blocks of an agentic Windows OS

One concern many users have about AI is that often their data leaves their PC and their network, with inferencing happening in the cloud. They have big questions about data protection. That’s one of the main drivers for Microsoft’s Copilot+ PCs; the neural processing units that are built-in to the latest CPU systems on a chip run inferencing locally using small language models (SLMs) and other optimized machine-learning tools.

Uptake has not been as fast as expected, with delays to key development frameworks preventing users from seeing the benefits of local AI acceleration. However, in 2025 Microsoft has slowly taken its foot off the brake, rolling out more capabilities as part of its Win App SDK and the related Windows ML framework. As part of that acceleration, tools like Foundry Local have provided both an easy way to access local AI APIs and a way to test and examine SLM prompting.

At Ignite 2025, Microsoft announced further development of the Windows AI platform as part of its intention to deliver a local agentic AI experience. This includes a preview of support for native Model Context Protocol (MCP) servers, along with agents that work with the Windows file system and its settings. These support a private preview of a separate Agent Workspace, which uses a virtual desktop to host and run agents and applications without getting in the way of day-to-day tasks.

Microsoft sees the future of Windows as an “agentic OS” that can respond to user requests in a more flexible way, working with local and remote resources to orchestrate its own workflows on demand. Using agents on Windows, the local Copilot will be able to link applications in response to your requests.

Adding MCP support to Windows is a key building block for the future of Windows. Microsoft is giving us a feel for how it will deliver security and trustworthiness for the next generation of on-device AI.

Using MCP inside Windows

The Model Context Protocol is a standard API format that gives agents access to data and functions from applications. If you’ve used the GitHub Copilot Agent in Visual Studio Code, you’ve seen how it allows access to tools that expose your Azure cloud resources as well as service best practices. However, it requires you to find and install MCP server endpoints yourself.

That’s fine for developers who are already used to finding resources and adding them to their toolchains as needed. However, for consumers, even power users, such an approach is a non-starter. They expect Windows to keep track of the tools and services they use and manage them. An MCP server for a local agent running in Windows needs to install like any other application, with Windows managing access and security.

Microsoft is adding an MCP registry to Windows, which adds security wrappers and provides discovery tools for use by local agents. An associated proxy manages connectivity for both local and remote servers, with authentication, audit, and authorization. Enterprises will be able to use these tools to control access to MCP, using group policies and default settings to give connectors their own identities.

Registering an MCP server is handled by installing via MSIX packages, with the MCP server using the standard bundle format. Bundles are built using an NPM package, so you need to have NodeJS installed on your development system before downloading and installing the MCP bundle (mcpb) package, and then initializing and building your bundle, targeting your MCP server code. This can then be included in your application’s installer and wrapped as an MSIX file.

You can manually install MCP bundles, but using a Windows installer and MSIX makes sure that the server is registered and will run in a constrained agent session. This limits access to system resources, reducing the risks of complex prompt injection attacks. Servers need to be binaries with a valid manifest before they can be registered. They are included as a com.microsoft.windows.ai.mcpserver extension in the MSIX package manifest, which registers the server and removes it when the host application is uninstalled.

As they run in a separate session, you need to give explicit permission for file access, and they are blocked from access to the registry and from seeing what you are currently using. That doesn’t stop them from running code in their own session or from accessing the internet. Access to user files is managed by the app that hosts the MCP server, and if access is granted to one server, all the other servers that run under the same host automatically get access. The requested capabilities need to be listed in the app manifest, used by the system to prompt for access.

The link between Windows agents and MCP servers

MCP servers are only part of the Windows agent platform. They need hosts, which provide the link between your agents and registered MCP servers. Microsoft provides a sample JavaScript application to show how to build and use a host, parsing the JSON provided by a server and then connecting. You can then list its available tools and call them. The sample code can be adapted to other languages relatively easily, allowing an agent orchestration framework like Semantic Kernel to work with local MCP servers.

MCP servers provide a bridge between AI applications and other services, in many cases offering connectors that can be used for AI models to query the service. As part of its initial set of Windows agent tools, Microsoft is delivering an MCP-based connector for the Windows File Explorer, giving agents the same access to the Windows file system as users. Both users and system administrators can block access to files or specific project directories.

The connector provides agents with a set of file tools, which include basic access, modification, and file and directory creation capabilities. As there’s no specific file deletion capability, agents can use the connector to write new files and move existing ones, as well as to edit text content. These are classed as destructive operations as they change the underlying Windows file system.

Be careful when giving agents access to the Windows file system; use base prompts that reduce the risks associated with file system access. When building out your first agent, it’s worth limiting the connector to search (taking advantage of the semantic capabilities of Windows’ built-in Phi small language model) and reading text data.

This does mean you’ll need to provide your own guardrails for agent code running on PCs, for example, forcing read-only operations and locking down access as much as possible. Microsoft’s planned move to a least-privilege model for Windows users could help here, ensuring that agents have as few rights as possible and no avenue for privilege escalation.

Along with tools for building and running MCP servers in Windows, Microsoft provides a command-line tool for working with its agent registry. This will allow you to test that your own servers have been installed. The tool will also list any third-party servers that may have been registered by applications running on your PC. It’s a good idea to use this regularly to check for new servers that may have been installed by software updates.

The road to an agentic OS

Building an agentic OS is hard, as the underlying technologies work very differently from standard Windows applications. Microsoft is doing a lot to provide appropriate protections, building on its experience in delivering multitenancy in the cloud. Microsoft’s vision for an agentic OS appears to be one where each agent and its associated servers are treated as a tenant on your PC, where it operates in a restricted, locked-down environment to reduce the risk of interactions with your applications and data.

We’ve seen this before, where services like Windows log-on are kept in their own virtual machines using the Krypton hypervisor. Virtualization-based security is a key part of Windows 11, so it’s no surprise that this model is at the heart of delivering autonomous agents as part of Windows. As I noted in an earlier look at Microsoft’s agent visions, one of the showstoppers for the first generation of agent technologies was that they required running arbitrary code on remote computers. Redmond has clearly learned from the lessons of Kaleida and General Magic and is sandboxing its agent support from the very start.

It is still early, but it’s promising to see tools to help build complex agentic applications that can use a mix of local and remote resources to handle many different tasks, without leaving a secure sandbox. If Microsoft can deliver and developers can take advantage, the results could be very interesting.