GitHub 于 2026 年 8 月 6 日宣布，GitHub Copilot enterprise managed settings 的 MCP allowlists 已正式一般可用。企业 owner 现在可以集中控制哪些 Model Context Protocol（MCP）servers 允许 Copilot clients 执行，也可以把不受信任或不符合规范的 server 加入 deny list。
设置位置是 copilot/managed-settings.json，政策可以使用 allowedMcpServers、deniedMcpServers，或同时使用两者。每个 matcher 可以按 serverUrl、serverCommand 或 serverName 识别 MCP server。serverUrl 对应 remote HTTP/SSE servers，并支持 wildcard 和 URL canonicalization；serverCommand 对应 local stdio servers，会按 exact command 和 arguments 比对。
serverName 只是便利用法，不应被当成 security control，因为用户可以重新命名 server。这个区分很重要：企业政策需要依据较难被用户改写的 endpoint 或 command，而不是 UI 上显示的 label。
GitHub 表示，政策采用 fail closed 行为。配置格式 malformed 或无法验证时，server 会被 block，而不是在不确定的情况下放行；如果政策来自多个 layers，MCP server 必须通过每一层才可以执行。这种默认对企业安全比较保守，但也代表配置错误可能直接造成工具不可用，需要配合测试和 rollout 流程。
在 server-managed deployments 中，两个 key 都可以标记为 overridable，让 enterprise team 在既有 baseline 之上定义自己的 allow 和 deny lists。GitHub 目前表示，MCP allowlists 会在 GitHub Copilot app、Copilot CLI 和 VS Code enforced。
开始使用的步骤也偏向 repository-based governance：在 source organization 的 .github-private repository 中加入配置，然后 commit 到 default branch。这使政策可以通过 code review、版本记录和组织管理流程维护，而不是只依赖每台开发者电脑的本地设置。
MCP 让 agent 可以接触外部数据和工具，因此 allowlist 的价值不只是封锁某几个 server，而是把「agent 可以使用什么」变成一个可审核的企业政策。实际安全仍取决于 matcher 是否写得足够精确、remote server 是否可信、local command 的依赖是否安全，以及政策变更是否经过测试。GA 提供的是集中控制面，不是对每个 MCP server 的安全保证。
这次更新反映 Copilot agent governance 正在由功能设置走向 execution boundary。当企业开始允许多个 agent app、MCP tools 和不同 client 共存，allow、deny、fail-closed 和多层继承会成为部署前必须清楚定义的条件。
