AI权限写进JSON就安全了吗？真正缺的是配置生效验证
内容提要
GitHub 新增 Copilot 企业配置校验器，可检查托管设置 JSON、团队映射及引用文件，定位语法、结构、引用错误。但校验通过不等于终端生效，策略需经本地预检、审批、平台验证和客户端抽样四层闭环。建议用 CI 检查映射引用，区分“可覆盖”与“未管理”，并设计回滚与正反例验收，确保高风险策略真正到达用户端。
延伸解读
校验器能查什么，不能查什么
GitHub 新增的 Copilot 企业配置校验器可检查托管设置 JSON、团队映射及引用文件，定位语法、结构、引用错误。但官方明确其检查配置而非终端行为，且并非所有客户端支持所有属性。校验通过只代表文件合法，不代表策略已到达用户端。
从合法 JSON 到有效策略的四层
文章将策略生效分为四层：语法解析、结构支持、引用解析、终端效果。只做第一层易出现“提交成功、护栏失效”的绿色假象。例如团队 slug 拼错时，基础 JSON 仍合法，但高风险团队可能继承默认策略。
最小实践：本地检查映射引用
文章提供 Python 脚本示例，检查映射值是否为团队数组、目标设置文件是否存在、团队 slug 是否在允许清单。该脚本仅用标准库，可在 CI 中提前发现引用错误，但不能替代平台校验，也不覆盖 GitHub 支持键全集。
落地要点与风险边界
建议为 .github-private 设置 CODEOWNERS 和分支保护，将本地检查放入 CI，平台校验后抽样验证终端行为。需区分“可覆盖”与“未管理”，后者不等于安全默认值。产品内校验器无法证明插件安全或沙箱无逃逸，仍需身份、终端和运行时审计。
Q&A
GitHub Copilot 企业托管设置新增的校验器能检查哪些内容？
该校验器会检查 copilot/managed-settings.json、copilot/team-mappings.json 以及映射引用的团队设置文件，可发现畸形 JSON、不支持的配置、无效团队映射等问题，并把错误定位到文件和 JSON path。
为什么说 JSON 校验通过不等于策略在终端生效？
因为校验器只检查配置文件的语法、结构和引用是否正确，并不验证策略是否真正到达用户端并产生预期效果。策略生效需要经过本地预检、审批、平台验证和客户端抽样四层闭环，服务器托管策略通常约一小时内到达用户端，但客户端支持情况各异。
从合法 JSON 到有效策略需要经过哪四层验证？
第一层是语法：文件能否解析；第二层是结构：键和值是否被平台支持；第三层是引用：团队 slug、文件名和覆盖关系能否解析到真实对象；第四层是效果：指定用户在指定客户端上是否真的得到预期限制。
如何用本地脚本提前发现团队映射引用错误？
可以编写 Python 脚本检查三件事：映射值必须是团队数组、目标设置文件必须存在、团队 slug 必须来自允许清单。脚本读取仓库文件并解析 JSON，输出错误列表。例如检查 team-mappings.json 中引用的团队是否在已知团队集合中，能提前发现未知团队等引用错误。
在 AI 策略治理中，如何区分“可覆盖”和“未管理”？
“可覆盖”指团队文件可以改变默认值，例如 { "overridable": "auto" }；“未管理”表示移除该项控制，例如团队设置 "unmanaged"。未管理不等于安全默认值，高风险属性应明确谁能覆盖、覆盖范围以及验证不可用时的处理方式。
AI 策略变更的验收测试为什么需要同时包含正例和反例？
正例证明普通研发仍能完成日常任务，反例则验证受限团队无法关闭沙箱、安装未批准插件或使用被禁模型。只测“应该允许”的路径会让治理看起来稳定，却漏掉最重要的拒绝语义，无法确保策略真正生效。
AI 策略治理中回滚机制应该如何设计？
应保存上一版已验收配置和对应提交，在新策略出现大面积阻断时恢复旧版，再重新走平台校验与客户端抽样。不要通过临时开放全部设置来救火，因为这种改动最容易在事后遗忘。变更日志应回答谁改了什么、影响谁、何时生效、如何撤销。
