How the Windows MCP Registry & Security Model Works in Windows 11

Microsoft introduced native support for the Model Context Protocol (MCP) in Windows 11 through Windows AI Foundry. A key part of this update is the MCP Registry, which serves as a trusted directory of MCP servers, and a security model that governs which tools agents can access ¹. This registry was designed to ensure only vetted servers are exposed, and to give users control over agent permissions ¹².

Registry and Security Architecture

The MCP Registry for Windows is the central source agents use to discover available MCP servers. Only servers that meet baseline security criteria—such as code signing and fixed tool definitions—are allowed to register ¹³. Agents cannot access any MCP server until the user explicitly enables the feature; agent access is disabled by default ¹.

When an agent requests a tool, Windows routes that interaction through a secure system proxy. The proxy handles centralized policy enforcement, audit logging, and anomaly detection. This allows Windows to block unauthorized access and monitor for threats in real time ¹³.

Security principles are front and center. The system enforces the principle of least privilege—agents receive only the minimal rights needed. The registry prevents supply-chain attacks by excluding unverified servers. Individual agent-tool interactions must be user-approved, which limits the scope of any potential breach ¹².

Implementation (Registry Interaction Example)

Although Microsoft has not published full code for interacting with the MCP registry, the expected registration flow resembles the following pseudocode:

Once registered by an installed application, an agent’s discovery request against the Windows MCP registry will return metadata such as the tool name, capabilities, and required privileges. The OS proxy intercepts calls and ensures that code signatures match expectations before allowing execution.

Behind the Scenes

Here is how a tool invocation typically proceeds:

1. The MCP server is installed and registers with the Windows MCP registry, including metadata and security attributes.
2. The agent queries the registry and sees the registered tools.
3. The user receives a UAC-style consent prompt specifying the agent and tool combination.
4. If the user approves, this consent is recorded.
5. The agent initiates the call to the MCP server.
6. The OS proxy enforces policies on the call—for example, checking that only permitted capabilities are used.
7. The MCP server runs with minimal privileges, and any inputs are checked to prevent injection attacks.
8. The action is logged for audit purposes.

This flow enforces defense in depth, limiting potential damage from compromised agents or tools. It also aims to reduce “shadow MCP” scenarios where unauthorized servers could run unnoticed in enterprise environments ¹⁴.

My Thoughts

The combination of a central registry, user approval, and proxy enforcement is a strong model for agent security. It ensures that developers can safely expose tools without risking uncontrolled access. The user interface for consent prompts will be critical—too many prompts may lead to consent fatigue, but too few could weaken protection. Enterprises should manage server registration policies centrally and consider automated auditing tools to detect shadow servers. Overall, this registry-based model appears to offer a clear, auditable, and secure foundation for MCP usage on Windows.

References