AI权限写进JSON就安全了吗？真正缺的是配置生效验证

把 AI 工具权限写进仓库，只解决了“有人声明过策略”，没有证明策略能被解析、映射到正确团队并到达客户端。9 月 25 日 GitHub 新增的产品内校验器提醒了一个常被忽略的事实：AI 治理也需要像代码一样编译、审查、发布和验收。

发生了什么

GitHub Copilot 企业托管设置现在会在 AI controls 页面检查 copilot/managed-settings.json、copilot/team-mappings.json 以及映射引用的团队设置文件。官方称它可以发现畸形 JSON、不支持的配置、无效团队映射等问题，并把错误定位到文件和 JSON path。管理员修复后提交到 .github-private 仓库默认分支，再刷新页面确认结果。

官方文档给出的范围也很重要：支持 Copilot CLI、VS Code、Copilot app、云端 Agent 与 JetBrains IDE，但不是每个客户端都支持每个属性。服务器托管策略通常在约一小时内到达用户端，重启客户端或重新登录可触发立即刷新；若验证服务暂时不可用，现有设置继续生效。换句话说，校验器检查配置，不是终端行为的实时证明。

从“合法JSON”到“有效策略”有四层

第一层是语法：文件能否解析。第二层是结构：键和值是否被平台支持。第三层是引用：团队 slug、文件名和覆盖关系能否解析到真实对象。第四层才是效果：指定用户在指定客户端上是否真的得到预期限制。只做第一层，很容易出现“提交成功、护栏失效”的绿色假象。

具体场景是安全团队要求研发 Agent 必须运行在沙箱内，并只安装批准插件。若 team-mappings.json 把 payments-core 拼成已不存在的 slug，基础 JSON 仍完全合法，但高风险团队可能继承默认策略。配置校验应在合并前尽量发现引用错误，平台校验和客户端抽样再确认真实传播链。

最小实践：本地检查映射引用

下面用内存样本检查三件事：映射值必须是团队数组、目标设置文件必须存在、团队 slug 必须来自允许清单。真实 CI 中应读取仓库文件，并通过受控来源同步企业团队清单。

import json

files = {
    "copilot/managed-settings.json": '{"model":"auto"}',
    "copilot/team-mappings.json":
        '{"restricted.json":["payments-core","ghost-team"]}',
    "copilot/teams/restricted.json":
        '{"model":"unmanaged"}',
}
known_teams = {"payments-core", "platform"}

def validate(repo_files, teams):
    errors = []
    parsed = {}
    for path, raw in repo_files.items():
        try:
            parsed[path] = json.loads(raw)
        except json.JSONDecodeError as exc:
            errors.append(f"{path}: invalid JSON at {exc.pos}")

    mappings = parsed.get("copilot/team-mappings.json", {})
    for filename, slugs in mappings.items():
        target = f"copilot/teams/{filename}"
        if target not in parsed:
            errors.append(f"{filename}: referenced file missing")
        if not isinstance(slugs, list):
            errors.append(f"{filename}: team mapping must be a list")
            continue
        for slug in slugs:
            if slug not in teams:
                errors.append(f"{filename}: unknown team {slug}")
    return errors

problems = validate(files, known_teams)
print("\n".join(problems))
assert problems == ["restricted.json: unknown team ghost-team"]

依赖只有 Python 标准库。保存为 policy_check.py 后运行 python policy_check.py。本次在 Python 3.9 实际运行，准确报告未知团队 ghost-team，断言通过。这个脚本没有覆盖 GitHub 支持键全集，也不能代替平台校验；它的价值是把最便宜的错误提前到拉取请求阶段。

开发者和管理者该怎样落地

先为 .github-private 设置 CODEOWNERS 和分支保护，限制管理员与 AI 管理者修改；每次变更附上影响团队、预期客户端行为和回滚提交。再把本地 JSON/Schema 检查放进 CI，避免语法与引用问题进入默认分支。平台显示无错误后，至少用一个默认用户和一个覆盖团队用户抽查模型选择、沙箱与插件权限，并记录时间和客户端版本。

还要区分“可覆盖”和“未管理”。官方示例中的 { "overridable": "auto" } 允许团队文件改变默认值，而团队设置 "unmanaged" 表示移除该项控制。它不等于安全默认值。高风险属性应明确谁能覆盖、覆盖到什么范围，以及验证不可用时采用继续运行还是暂停变更。