配置托管 MCP 允许与拒绝列表

按实际服务器身份匹配，理解内置服务器、错误策略和多来源组合。

先启用 MCP servers in Copilot，再在企业 managed-settings.json 设置 allowedMcpServers 与 deniedMcpServers。服务器、MDM和文件的分发方式见托管部署。

从 Registry 限制迁移

如果已有自建Registry限制，官方建议将 Restrict MCP access to registry servers 改为 Allow all，并可清空 MCP Registry URL，以避免与新允许列表冲突。

该建议涉及两类独立政策。应先核对并准备正确的托管列表及客户端覆盖，不能把关闭Registry限制本身当作已经部署了替代限制。

配置示例

下面保留官方示例的服务器身份写法。允许远程URL或精确命令，拒绝以根目录为参数的filesystem服务器：

{
  "allowedMcpServers": [
    { "serverUrl": "https://api.githubcopilot.com/*" },
    { "serverCommand": ["npx", "@playwright/mcp@latest"] },
    { "serverCommand": ["cmd", "/c", "uvx", "markitdown-mcp"] }
  ],
  "deniedMcpServers": [
    {
      "serverCommand": [
        "npx",
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/"
      ]
    }
  ]
}

这是政策定义，不是要求执行这些命令。实际配置需匹配你部署的命令与参数顺序；增加 -y 或更换launcher可能改变身份，不能假设同一包名始终匹配。

Matcher的精确语法、URL规范化和serverName边界见托管扩展参考。

判定顺序

允许内置默认服务器，例如内置 GitHub MCP server。
命中任意 deniedMcpServers 则阻止。
存在 allowedMcpServers 时，未命中则阻止。
URL或命令仍有 ${VARIABLE} / $VARIABLE 等未解析变量时，因为无法确认服务器身份而阻止。

此处指匹配时仍未解析的变量，不是所有带环境变量配置的服务器都永远不可用。内置默认服务器的豁免也意味着空允许列表不是关闭全部MCP功能的同义操作。

多来源与错误

多种部署渠道同时提供政策时，任意来源的deny都阻止；每一层声明allowlist时，服务器必须在每层都匹配。因此allow取交集，deny取并集。

列表格式错误（例如无效JSON）时，客户端按空 allowedMcpServers 处理，除内置默认服务器外均阻止。

如果因获取或设备发现错误无法确定某层政策，官方说明保留此前已执行政策，有效政策可以更严格，不能因此变宽松。这里描述已有政策的保留行为，不应推导首次启动、完全无缓存时也必然拥有未曾取得的服务器设置。