系列位置：进阶篇第 8 篇（总第 19 篇）
承接： 从 MCP 到 A2A 的 Agent Gateway 治理 · Copilot Code Review 的 Agent Skills 与 MCP
调研日期：2026-08-01
本文目标：用 enterprise managed settings 把 Copilot App、CLI、VS Code 与 cloud agent 的插件/市场信任面纳入同一份可评审策略，同时明确哪些控制并不适用于 cloud agent。

        2026-07-27，GitHub 宣布 enterprise managed settings 已覆盖 GitHub Copilot App 和 Copilot cloud agent。企业可以把策略放进一份 managed-settings.json，统一约束开发者可以使用的插件和插件市场；对于受支持的键，企业托管值会优先于开发者的本地设置。

        这不是“有了一个 JSON 文件就拥有了所有 Agent 的控制权”。公告同时写明：cloud agent 会读取插件和市场控制，但绕过审批提示的控制只适用于交互式客户端——Copilot App、Copilot CLI 与 VS Code。把这两类能力混为一谈，容易形成一条没有真正生效的云端防线。

        适用前提： 服务器托管设置由 Enterprise owner 配置，面向使用该企业 Copilot plan 的成员。先在企业 AI Controls 中选定负责 AI standards 的源组织，再使用该源组织的 .github-private 仓库；把同名文件放进任意业务仓库或任意 .github-private 仓库，并不会自动成为企业策略来源。

---

一、先确认控制面、适用面和不可替代的边界

维度	已核验事实	团队要自己决定
策略来源	服务器托管方式使用企业 AI standards 源组织的 .github-private 仓库中的 copilot/managed-settings.json	哪个团队拥有该源组织与仓库、谁能批准变更、怎样保留审计记录
优先级	MDM 托管值高于服务器托管值，服务器托管值高于文件与用户级设置	哪些策略必须只由 MDM 下发，哪些可以在 GitHub 中以 PR 管理
插件与市场	cloud agent 会遵循适用的插件和插件市场控制，只使用获批的范围	哪些插件值得默认启用，哪些市场可被信任，谁负责复审插件更新
绕过审批	禁止 bypass/YOLO 模式可约束 App、CLI、VS Code 的交互式会话	cloud agent 的工具权限、仓库权限和外部写操作该如何单独收紧
生效时机	App 重启或重新登录会读取更新；cloud agent 在下次任务分配时观察更新；常规更新约一小时内生效	灰度窗口、回滚阈值和如何证明所有客户端都已收到同一版本策略

        从治理角度看，managed settings 是客户端和扩展信任面的控制平面；它不取代仓库权限、MCP 服务端授权、部署凭据隔离、PR 保护规则或上一篇所说的只读审查边界。

---

二、先画清楚“谁读策略、谁执行动作”

一个可维护的策略链路应当把策略本身当代码对待：

.github-private / copilot/managed-settings.json
  └─ 受保护分支上的策略 PR
       ├─ JSON 语法、支持键与适用客户端校验
       ├─ 安全、平台和开发体验共同评审
       └─ 变更记录与回滚提交

托管策略分发
  ├─ Copilot App / CLI / VS Code：插件、市场与交互式权限限制
  └─ Copilot cloud agent：适用的插件与市场限制

执行层仍独立控制
  ├─ 仓库角色、分支保护、Actions 环境审批
  ├─ MCP 服务端的工具 allowlist、Token 和数据域
  └─ 云端 Agent 的任务工具、写入权限与 PR 审核

        这里最关键的设计原则是：策略源只有一个，执行授权不止一层。 一个市场被允许，不代表其中每个插件都该获得内部数据访问权；一个插件被启用，也不代表 cloud agent 应自动拥有合并或发布权限。

---

三、从最小市场白名单开始，而不是先开放“所有已知插件”

        下面是一份教学用的最小示例。它把一个企业自有市场列为唯一可安装来源，显式启用一个经过审查的插件，并阻止交互式客户端进入“允许全部”的绕过模式。请把组织名、仓库和完整提交 SHA 替换成真实且已审查的值；不要把令牌、内部 URL 或业务密钥写进此文件。

{
  "enabledPlugins": {
    "corp-review@corp-market": true,
    "experimental-network@corp-market": false
  },
  "extraKnownMarketplaces": {
    "corp-market": {
      "source": {
        "source": "github",
        "repo": "ORG/copilot-plugin-marketplace",
        "ref": "0123456789abcdef0123456789abcdef01234567"
      }
    }
  },
  "strictKnownMarketplaces": [
    {
      "source": "github",
      "repo": "ORG/copilot-plugin-marketplace",
      "ref": "0123456789abcdef0123456789abcdef01234567"
    }
  ],
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  }
}

这个例子体现了四个不同的意图：

1. enabledPlugins 是明确启用或阻止某个插件，而不是对市场的泛泛信任。
2. extraKnownMarketplaces 定义额外可识别的市场；它本身不是“只准从这里安装”的开关。
3. strictKnownMarketplaces 才把可安装市场限制为列出的集合；空数组的语义是完全锁定，因此不要把它当成无害的默认值。
4. disableBypassPermissionsMode 能阻止交互式客户端开启 allow-all 类模式；它不应被当作 cloud agent 的权限策略。

        若需要让云端 Agent 使用某项扩展，应先确认该插件/市场键是否在 cloud agent 的支持面内，并在隔离仓库跑一条无敏感数据的任务。不要仅因为 App 能安装成功，就推断 cloud agent 已经、或应该使用它。

---

四、用 PR 交付策略，再做跨客户端的闭环验证

建议按以下顺序推广：

1. 盘点扩展面。 收集开发者、App、CLI、VS Code 和 cloud agent 当前使用的插件、市场、MCP 入口与任务类型；先删除没有明确 owner 的项目。
2. 定义最小白名单。 先放一个企业自有市场和少量明确用途的插件。对每项记录来源、版本固定方式、数据权限、负责人和失效日期。
3. 选择正确的策略源并提交 PR。 由 Enterprise owner 在 AI Controls 选定 AI standards 的源组织；在该组织的 .github-private 仓库中创建 copilot/managed-settings.json，并通过受保护分支提交。至少要求平台、安全和实际使用团队各一名审阅者。
4. 分开做语法与策略校验。 jq 只能验证 JSON 语法；PR 审查或 CI 还应逐项检查官方支持键、值类型、目标客户端是否支持，以及是否意外新增了市场或插件。最小语法检查如下：

jq empty copilot/managed-settings.json

1. 按客户端验收。 App 可通过重新登录或重启加速验证；cloud agent 要在下一次任务分配后用一个低风险任务检查。不要把“文件已合并”当作“所有策略已生效”。
2. 保存回滚点。 用一次明确的反向 PR 回滚策略，而不是依赖用户本地覆盖；服务器托管值的优先级本来就会压过用户设置。

        建议把“策略提交 SHA、批准人、试点仓库、验证时间、失败现象和回滚提交”写入变更记录。示例中的市场引用应使用完整不可变提交 SHA；若因发布流程必须使用 tag，则需保证 tag 受保护、不可改写，并在每次变更时重新完成准入审查。这样插件或市场发生信任事件时，团队能快速回答：谁在哪个时间段可能受影响、应该撤回哪一份策略。

---

五、验收矩阵必须区分 App/CLI 和 cloud agent

        不要测试一次插件安装就宣布治理完成。下面的矩阵能发现最常见的“策略本来只对一半客户端生效”问题。

验收场景	预期结果	特别要看什么
从未列入的市场安装插件	交互式客户端拒绝；cloud agent 不把它作为可用扩展	strictKnownMarketplaces 是否真正受管，策略源是否正确
已允许的插件	只在已批准的客户端/任务中可用	插件版本、实际请求的数据域和是否引入额外工具
交互式会话尝试 allow-all	App、CLI、VS Code 不能绕过审批	不要把这一项的成功误写成 cloud agent 的安全结论
cloud agent 执行低风险任务	只使用允许的扩展，提交产物仍走 PR 与仓库规则	任务工具、仓库角色、Secrets 和外部写权限是否另有收紧
策略回滚	新任务/新会话在预期时间内恢复到上一版本	回滚是否有审计记录，旧会话是否需要重新分配

        验收中不要使用生产数据、真实发布凭据或宽权限机器人令牌。策略是防止信任面扩张的工具，不是让测试环境获得生产级能力的理由。

---

六、把扩展准入和执行授权拆成两个审查问题

        给每个插件、市场或 cloud agent 工具至少问两遍问题：

审查问题	需要的证据
它是否可以进入环境？	来源仓库、固定的版本/引用、维护者、漏洞响应、许可和代码审查记录
它进入后可以做什么？	可调用工具、网络目的地、文件/仓库范围、Token scope、日志和人工审批点

这能避免两种相反的失误：

• 只审市场，不审插件。 一个可信市场中的新插件或新版本仍可能扩大网络、文件或数据访问面。
• 只审工具，不审分发。 即使 MCP 服务端做了 allowlist，客户端若能随意安装新的市场或插件，新的工具面仍可能绕过原来的治理假设。

        对有内部数据访问的插件，建议固定到完整提交 SHA；若必须使用 tag，则应保证其受保护且不可改写，分离读/写 Token，并保留服务端审计。对 cloud agent，还要把它能被分配的仓库、可使用的任务工具和 PR 合并权限作为独立配置审查，不能从“市场已允许”推导出来。

---

七、五个常见误区

1）把 extraKnownMarketplaces 当成市场白名单

        它只是添加额外可识别市场。要限制安装来源，应配置 strictKnownMarketplaces，并确认数组内容符合企业的实际信任策略。

2）以为 disableBypassPermissionsMode 会保护 cloud agent

        公告明确说明绕过审批控制只适用于交互式客户端。cloud agent 仍要靠任务工具、仓库权限、环境保护和 PR 审核形成自己的边界。

3）把策略 JSON 存到普通业务仓库或客户端设置中

        企业默认的服务器托管位置是选定组织的 .github-private 仓库。策略源、审阅人和默认分支都应与一般业务代码的权限模型分开设计。

4）允许市场后不固定版本、不安排复审

        市场是分发渠道，不是永恒的信任证明。插件升级、来源转移和维护者变化都应再次经过准入审查。

5）只验证 App，不验证云端的下一次任务

        App 可以在重启/重新登录后读取更新，而 cloud agent 在下次任务分配时才观察更新。两条生效路径不同，验收记录也应分开。

---

结语

        将 Copilot App 和 cloud agent 纳入 enterprise managed settings，真正的价值不是多了一份配置，而是第一次可以把插件和市场的信任规则作为可审计的企业策略来管理。

        从一个严格的市场白名单、几个低风险插件和一条云端低风险任务开始。只有当策略来源、客户端生效、云端任务权限和 PR 合并门禁都经过独立验证时，Agent 的扩展能力才会成为可控的生产力。

---

来源与延伸阅读

• Enterprise managed settings in the GitHub Copilot app and Copilot cloud agent：GitHub 官方公告，发布于 2026-07-27。
• Enterprise managed settings reference：优先级、插件/市场键、锁定语义与绕过模式边界。
• Configuring enterprise-managed settings：Enterprise owner、源组织、.github-private 路径与生效验证。
• Enterprise managed-settings.json is generally available：.github-private 中的服务器托管路径与Agent Governance兼容性说明。
• 代码审查进阶：Copilot Code Review 的 Agent Skills 与 MCP 已 GA，如何接入并守住只读边界：为代码审查维持仓库规则、只读 MCP 和最小权限。
• 依赖供应链深度实践：Dependabot 发现恶意依赖后：Agent CI/CD 的告警、冷却与合并门禁清单：把依赖供应链信号接到同一条人机协作流程。