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 和多層繼承會成為部署前必須清楚定義的條件。
