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。对采用团队而言，最值得验证的是政策是否真正覆盖所有入口、变化多久生效，以及遇到意外行为时能否快速停用和追踪。
