Microsoft just did something that no other OS vendor has attempted: they embedded the Model Context Protocol directly into Windows. Not as a third-party extension. Not as an optional SDK. As an operating system feature, complete with its own registry, security model, and CLI tool. Starting with Insider Preview Build 26220.7344 (December 2025), Windows 11 includes native MCP support, an on-device agent registry called ODR, and isolated agent workspaces where AI agents operate with their own user accounts, separate from yours.
This is a fundamentally different approach from what Apple, Google, or Linux distributions are doing. While others treat AI as an application-layer concern, Microsoft is making agents a first-class OS primitive. The implications for enterprise IT are significant: agents become manageable through the same tools (Intune, Group Policy, Entra) that IT already uses for devices and users.
The On-Device Registry: How Windows Discovers Agent Connectors
The Windows On-Device Agent Registry (ODR) is a secure, locally managed catalog of MCP servers that AI agents can discover and connect to. Think of it as a local app store, but for agent capabilities. Instead of agents needing hardcoded server URLs or manual configuration files, they query the ODR to find available tools at runtime.
Every MCP server registered in the ODR is called an “agent connector.” These connectors are the bridge between AI agents and local applications, system features, or remote services. Microsoft currently ships two built-in connectors: File Explorer (agents can manage, organize, and retrieve local files) and System Settings (agents can adjust Windows configuration). On Copilot+ PCs, the File Explorer connector supports natural language search based on file descriptions, content, metadata, and image classification.
How odr.exe Works
The odr.exe command-line tool is the primary interface for managing the on-device registry. It provides three core operations:
# List all registered MCP servers
odr mcp list
# Register an MCP server from a manifest file
odr mcp add --manifest path/to/manifest.json
# Register a remote MCP server by URI
odr mcp add --uri https://your-server.example.com/mcp
Before you can use odr.exe, you need to enable experimental agentic features in Settings > System > AI components. This toggle is off by default, a deliberate choice by Microsoft to ensure organizations control the rollout.
Every connector registered through ODR must be packaged as an MSIX package and signed by a trusted source. This is the same packaging format Windows uses for Store apps, which means IT admins can deploy connectors through Microsoft Intune, apply Conditional Access policies, and use Managed Installers. No rogue MCP servers running from unpackaged scripts.
ODR vs. Cloud-Based MCP Registries
The key difference between ODR and cloud-based registries like the official MCP Registry or Kong’s MCP Registry is scope. Cloud registries catalog thousands of public MCP servers for discovery across the internet. ODR catalogs only the servers that a specific Windows device is authorized to use. It is a local, policy-controlled subset.
This makes ODR complementary to cloud registries, not a replacement. An enterprise might use the public MCP registry to evaluate new connectors, then deploy approved ones to devices via Intune, where they appear in each machine’s local ODR.
Agent Workspace: Isolated Environments for AI Agents
The most architecturally significant feature is not the registry itself but what runs on top of it: Agent Workspace. This is an isolated, policy-controlled, and auditable environment where AI agents operate in their own Windows session, parallel to your primary session.
Each agent gets its own dedicated user account, separate from the human user account. This is not a container or a VM (though it provides some similar guarantees). It is a separate Windows session where agents interact with apps and system resources without affecting the user’s active session.
Why a Separate Session Matters
This architecture solves three problems that every enterprise deploying agents faces:
Isolation. If an agent misbehaves, crashes an app, or creates garbage files, it happens in the agent’s session, not yours. Your running applications, open documents, and system state are unaffected.
Auditability. Every action performed by an agent runs under its dedicated user account. Windows event logs capture exactly what each agent did, when, and through which connector. IT teams can use existing account and event log management tools to monitor agent activity.
Least privilege. Each agent accesses resources only when explicitly authorized. What one agent can access does not automatically apply to others. If your file management agent has access to Documents, that does not mean your email drafting agent does too.
The MCP Proxy Layer
Between agents and connectors sits a built-in MCP proxy layer that enforces consent, governance, auditing, and containment. When an agent requests access to a connector, the proxy checks whether the user has granted consent, whether IT policy allows the operation, and whether the agent has the required capabilities declared in its manifest. Only then does the request reach the actual MCP server.
This proxy approach is different from external MCP gateways like Strata or Kong, which sit between agents and cloud-hosted MCP servers. The Windows proxy operates at the OS level, which means it can enforce controls even for local connectors that never touch a network.
Building MCP Servers for Windows
Developers who want their applications to be agent-accessible have two paths: build an MCP server that registers automatically through MSIX, or manually register a local or remote server via odr.exe.
The MSIX path is more enterprise-friendly. Microsoft’s quickstart guide walks through creating an MCP host that discovers connectors through the ODR, processes tool calls, and handles the consent flow. The manual path is faster for development: point odr.exe at a remote URI or local manifest and the server appears in the registry immediately.
What Connectors Must Declare
Every agent connector must explicitly declare the minimum capabilities it requires. This is enforced at registration time, not at runtime. If a connector’s manifest says it needs read-only file access, it cannot later request write access without a manifest update and re-registration.
This is the same principle behind Android’s permission model or iOS’s entitlements system, but applied to AI agent tool access. The connector declares what it can do; the OS enforces that boundary.
Microsoft has published sample code on GitHub for building Windows-native MCP servers, including examples for File Explorer integration and custom connectors.
What Enterprise IT Teams Should Prepare For
The agentic features are currently experimental and opt-in. But Microsoft’s Windows Developer Blog and Ignite 2025 announcements make the trajectory clear: agents managed through Intune, governed by Entra ID policies, and auditable through existing security tooling.
Here is what IT teams should be thinking about now:
Connector governance. Decide which MCP servers your organization will allow. The MSIX packaging requirement means you can use existing app deployment pipelines, but you need a review process for evaluating connector manifests and their declared capabilities.
Agent identity policies. Each agent runs under its own account. That means your Entra ID tenant will have agent identities alongside human identities. Plan your naming conventions, group memberships, and Conditional Access policies for agent accounts before the first connector ships to production.
Audit infrastructure. Agent actions generate Windows event logs under dedicated agent user accounts. Ensure your SIEM or log aggregation pipeline captures these events and that your security team knows what agent activity looks like in the logs.
Network controls. Remote MCP servers registered through odr.exe require network access. Your firewall and proxy rules need to account for agent-to-MCP-server traffic, which may look different from typical user browsing patterns.
Microsoft has committed to additional enterprise manageability controls later in 2026, including more granular Intune policies and Group Policy controls for agent workspaces.
The Bigger Picture: Windows as Agent Infrastructure
What Microsoft is building is not just “MCP support in Windows.” It is a complete agent execution environment at the OS level: discovery (ODR), isolation (Agent Workspace), identity (dedicated accounts), governance (MCP proxy + Intune), and auditing (event logs). No other operating system has this stack.
Apple’s approach to on-device AI focuses on Apple Intelligence, a closed system with no equivalent of MCP or agent registries. Google’s Android has on-device ML through TensorFlow Lite but no agent infrastructure. Linux distributions have nothing comparable, though the Agentic AI Foundation under the Linux Foundation is working on cross-platform standards.
The risk, of course, is platform lock-in. If Windows becomes the only OS where agents can discover tools through a managed registry, interact with local apps through sanctioned connectors, and operate under policy-controlled identities, then the operating system becomes the agent platform. That is exactly what Microsoft wants, and it is exactly what enterprises running Windows-heavy fleets will find hard to resist.
Frequently Asked Questions
What is the Windows On-Device Agent Registry (ODR)?
The Windows On-Device Agent Registry (ODR) is a local, secure catalog built into Windows 11 that allows AI agents to discover and connect to MCP servers (called agent connectors) on the device. It is managed via the odr.exe command-line tool and integrates with enterprise management tools like Microsoft Intune.
How does Windows Agent Workspace provide security for AI agents?
Agent Workspace runs AI agents in isolated Windows sessions with their own dedicated user accounts, separate from the human user’s session. Each agent operates under the principle of least privilege, only accessing resources that have been explicitly authorized. An MCP proxy layer enforces consent, governance, and auditing before any tool call reaches its target.
How do I register an MCP server on Windows?
You can register MCP servers using the odr.exe command-line tool. Use odr mcp add --manifest path/to/manifest.json for local servers with a manifest file, or odr mcp add --uri https://server-url for remote MCP servers. First, enable experimental agentic features in Settings > System > AI components.
Can enterprises manage Windows AI agent connectors through Intune?
Yes. Agent connectors packaged as MSIX can be deployed and managed through Microsoft Intune, Conditional Access, and Managed Installers. IT admins can control which connectors are available on devices, apply policies to agent workspaces, and audit agent activity through Windows event logs. Additional Intune controls are planned for later in 2026.
What built-in agent connectors does Windows 11 include?
Windows 11 ships with two built-in agent connectors: File Explorer (allowing agents to manage, organize, and retrieve local files) and System Settings (allowing agents to adjust Windows configuration). On Copilot+ PCs, the File Explorer connector also supports natural language search using file content and image classification.