GitHub 於 2026 年 7 月 27 日宣布，GitHub Copilot app 和 Copilot cloud agent 現在可以使用 enterprise managed settings。企業可以用同一份 managed-settings.json 管理不同 Copilot client 的政策，將原本在 Copilot CLI 和 VS Code 使用的部分治理設定帶到桌面 app 和雲端 agent 任務。
可管理的範圍包括哪些 plugins 可以使用、哪些 plugin marketplaces 可以安裝，以及 Copilot 執行 command、讀取 files 或 fetch URLs 前是否可以繞過 approval prompts。文件也列出把 auto model selection 設為新對話預設值的選項。這些設定處理的是工具和模型的使用邊界，不等於已經完成代碼安全或資料治理。
GitHub 表示，Copilot app 會讀取企業現有的 managed-settings.json；cloud agent 會套用適用的 managed settings，並只使用已批准的 plugins 和 marketplaces。對支援的設定，企業託管值優先於開發者本地設定，而 bypass-prompt 控制只適用於互動式 client，包括 app、CLI 和 VS Code。
首次部署可以在 enterprise 的 .github-private repository 建立 copilot/managed-settings.json，加入政策後提交到 default branch。GitHub 說支援的 client 通常會在大約一小時內套用更新，也可以在開發者重新啟動 client 或再次登入後立即讀取；cloud agent 則會在下一次 task assignment 觀察變更。實際延遲仍應在自己的組織測試。
這次變更的核心不是新增一個 agent 能力，而是把治理覆蓋面補齊。當同一團隊可以從 IDE、desktop app、CLI 和 cloud session 啟動 agent，任何沒有套用相同政策的入口都可能成為 plugin、外部 marketplace 或高權限 command 的例外路徑。
仍然需要保留其他控制。企業要繼續檢查 repository permissions、pull request review、CI checks、secret scanning、MCP 工具、網絡出口和 audit logs。集中政策可以降低設定漂移，但不能證明 agent 產生的修改安全，也不能取代對資料來源和輸出結果的人工覆核。
GitHub Copilot 的更新反映 agent 開始進入多個工作面後，產品治理會由單一 client 設定轉向跨 client 的 policy distribution。對採用團隊而言，最值得驗證的是政策是否真的覆蓋所有入口、變更多久生效，以及遇到意外行為時能否快速停用和追蹤。
