GitHub Copilot 内容排除覆盖 App 与 CLI：敏感代码真的安全了吗

GitHub Copilot 内容排除覆盖 App 与 CLI：敏感代码真的安全了吗

GitHub 在 9 月 2 日宣布，Copilot App 与 Copilot CLI 已正式支持内容排除策略。企业、组织或仓库管理员配置规则后，被排除的文件不会被这两个 Agent 客户端拿来充当模型上下文。此前只在编辑器里考虑敏感文件的团队，需要重新检查命令行和独立 App；Agent 能跨文件搜索、调用工具以后，入口已经不止代码补全窗口。

这项能力目前面向 Copilot Business 与 Copilot Enterprise。它适合处理一个很具体的问题：仓库中有些内容允许开发者读取，却不应进入 AI 会话，例如客户交付目录、生产配置模板、授权受限的第三方代码，或尚未公开的产品资料。管理员用统一策略表达边界，比要求每位开发者记住“这次不要附上某个文件”可靠得多。

内容排除管的是上下文，不是整个工作区

GitHub 的公告措辞很克制：Copilot 不会把排除文件用作上下文。它没有说这些文件从仓库消失，也没有把内容排除描述成数据防泄漏系统。开发者原有的 Git 权限、终端权限和本地文件权限仍然存在；脚本可以读取什么、Agent 能执行哪些命令，仍由运行环境决定。若一段敏感代码被复制进未排除文件、终端输出或工单描述，单靠路径规则也拦不住它。

因此，内容排除应当与访问控制分工。仓库权限决定谁能看文件，分支保护决定谁能改主线，Secret Manager 保存真实凭据，短期令牌限制调用时效，内容排除只负责减少进入模型上下文的材料。把 API Key 写进仓库，再指望排除规则兜底，顺序已经反了；密钥仍可能被 Git 历史、构建日志或普通命令读取。

另一个容易漏掉的范围是多工具并用。GitHub 的策略约束 Copilot 产品，不会自动同步到 Codex、Claude Code、IDE 插件或自建 Agent。团队若允许多个编程助手，需要为每个客户端确认支持范围，并在工作区权限、容器挂载和网络出口上设置共同底线。模型网关可以统一模型调用和用量记录，却无法替代本地文件系统的授权判断。

上线前用一份假敏感文件做验收

策略是否生效，最好用可观测的测试验证。可以在测试仓库放入一份无真实秘密的“诱饵文件”，写入唯一字符串，再分别从 App、CLI 和 IDE 询问相关内容。正确结果应是客户端不能从该文件回答，同时正常源码仍可用于任务。测试后还要看审计记录、策略继承关系和分支差异，避免仓库级设置被组织规则覆盖，或新目录没有进入匹配范围。

企业还应记录一次任务究竟经过哪些边界：Agent 读取了哪些文件，调用了什么工具，向哪个模型发送多少 Token，最后产生了哪些变更。文件上下文与模型 API 是两条不同的风险链。前者靠工作区隔离和内容策略，后者靠凭据、网络、供应商条款与网关日志。把两条链画在同一张数据流图上，安全评审才不会把“排除了文件”误解成“整个任务没有外发”。

对于需要同时比较多种编码模型的团队，AnyAIS 的统一模型接口可以承担模型接入和用量观察；仓库内容排除仍应在 Copilot 或相应 Agent 客户端内配置。两层各管一段，出现问题时也更容易判断是文件选择、工具权限，还是模型调用链路出了偏差。

来源：[GitHub Changelog：Content exclusions generally available in Copilot app and CLI](https://github.blog/changelog/2026-09-02-content-exclusions-generally-available-in-copilot-app-and-cli/)。