GitHub 在 2026 年 8 月 3 日的 changelog 公布 Enterprise team specialization for managed settings。企業管理者現在可以把 Copilot 的 managed settings 指向特定 team，讓不同團隊使用不同模型、權限或外掛設定；沒有被下放的設定仍由企業層級統一控制。
這項功能使用 team-mappings.json 把設定檔對應到團隊 slug，團隊設定檔放在 copilot/teams/ 目錄。GitHub 文件列出的適用客戶為 Business 與 Enterprise，支援範圍包括 VS Code、Copilot CLI、Copilot App 與 cloud agent。
GitHub team-mappings.json 把 Copilot 政策拆到團隊
企業可以在 managed settings 中標記可由 team 覆寫的設定鍵，再透過 team-mappings.json 指定團隊使用哪一份設定檔。這讓同一個 Enterprise 內的工程、資料、資安或客服團隊，能依工作內容採用不同的 Copilot 組態。
設定檔的分層依賴 GitHub Enterprise 的團隊成員關係。使用者加入或離開 team 後，系統會依企業設定與 team 對應結果決定適用值，管理者不必為每位使用者各自維護一份檔案。
Copilot managed settings 只讓標記 overridable 的鍵下放
GitHub 的設計不是讓 team 任意改寫企業政策。只有被標記為 overridable 的鍵可以使用團隊值，未開放覆寫的鍵仍維持 Enterprise 設定；文件列出的例子包括 permissions.model 與 permissions.disableBypassPermissionsMode。
這個限制讓企業可以先固定安全與合規底線，再把模型選擇或特定開發流程交給團隊調整。若企業層級沒有允許某項權限，team 設定檔不能藉由自己的值解除這個限制。
GitHub 把 Copilot 外掛與 marketplace 設為加法層
Plugins 與 extra known marketplaces 的 team 設定採加法方式處理。團隊可以在企業已核准的範圍內加入額外項目，企業層級提供的項目不會因為套用 team 設定而消失。
對需要管理 MCP、外掛或內部 marketplace 的企業而言，這種配置能把共同工具放在 Enterprise，再為個別團隊補上工作所需的資源。實際可用項目仍受 GitHub 支援的客戶端與企業政策控制。
GitHub Copilot team policy 仍受企業基線限制
GitHub 此次公布的是管理設定的分層能力，不是新的模型服務或權限繞過方式。企業仍需維護 managed settings、團隊 slug 與設定檔對應，並確認各支援客戶端已套用相同政策。公開 changelog 沒有另外公布一個獨立的結束日期或強制遷移時程。
消息來源：GitHub Changelog：Enterprise team specialization for managed settings、GitHub Docs：Enterprise managed settings reference。
