你以为 Copilot 只会提意见？今天它把 PR merge 这件事也接过去了

你以为 Copilot 只会提意见？今天它把 PR merge 这件事也接过去了。

2026 年 9 月 1 日，GitHub 给 Copilot code review 加了一个新能力：它可以 approve PR 了。不是提建议，而是直接签字说「这个可以合并」。目前是公开预览版，管理员必须手动开启才会生效。但这个功能一出来，安全圈的讨论就没断过——因为 Copilot 写的代码，40% 带漏洞。

它是怎么「点头」的

Copilot code review 的默认行为没变：提完意见就完事，approval assessment 只是告诉你它觉得这个 PR 能不能合并，不会自动计入合并人数。

想让 Copilot 的 approval 真正算数，管理员得在三个层级里手动打开：

• Enterprise：关掉全企业，或者让下面组织自己定
• Organization：开全组织 / 让仓库自己定 / 只给特定仓库 / 全关
• Repository：开关 + 限定文件路径白名单（最多 15 个 glob）

关键细节：Copilot approve 之后如果有人新 push 了代码，这个 approval 会自动消失——和人类 reviewer 的行为一样，不会留下过期的安全签字。

GitHub 画了哪些安全护栏

Copilot Cloud Agent 本身有六层约束：

• 只能在 copilot/ 前缀的分支上操作 → 想进 main/master？必须 human review
• Agent 凭证只能 simple push，不能 force-push
• Actions workflow 在 Copilot 推送后仍需 human 点击「Approve and run workflows」才能跑
• 请求者不能审批自己的 PR → 绕不过 required approvals 规则
• internet 访问默认防火墙隔离，可按策略定制
• 提交记录会标注 coauthor，归属清晰

这些约束让 Copilot 的「写代码 + 批 PR」能力被锁在一个明确的爆炸半径内。

但数据在说另一件事

GitGuardian 2026 年报告显示：启用 Copilot 辅助的仓库，secret 泄漏率达 6.4%，而全量仓库基准是 4.6%——高了 40%。研究还发现 62% 的 AI 生成程序包含可利用漏洞，2026 年 3 月一个月就有 35 个 CVE 直接溯源到 AI 生成代码。

这不是说 Copilot 不能用。Copilot 生成的代码功能上往往是对的，风格也通常不错。但安全漏洞是结构性问题，不是语法错误——Copilot 写的 SQL 查询可能少个参数，Copilot 建议的依赖可能是个已知漏洞包，这些不会体现在「approval assessment」里。

怎么用才能既开又不翻车

基于数据，建议四步走：

第一步：保守起步，先看数据。 先只让 Copilot 审批文档类 PR（.md/.json/.yaml），跑一个月看它的判断准确率，再决定要不要扩围。

第二步：路径白名单。 生产核心代码（涉及认证、支付、数据写入的）保持 human only；Copilot approval 只开启测试文件和纯配置类文件的权限。

第三步：安全门禁必须补上。 这是最关键的一条——secrets scanning + push protection 必须在 Copilot approval 开启之前跑熟。SAST 扫描未通过的 PR，无论 Copilot 怎么说，都应该阻断。

第四步：每月审计。 对比 Copilot approval 的 PR 和 human approval 的 PR 在漏洞密度、代码质量问题上的差异，作为调整覆盖范围的依据。

真正的问题是「谁在负责」

Copilot PR approval 本质上是把「谁来承担责任」这个问题抛给了团队。开启之前先问自己：你的安全门禁真的完整了吗？

如果 SAST 扫描还没跑熟，secret scanning 还没全开，Copilot approval 就只是一个看起来省事的幻觉。Copilot approval 只是在说「这个 PR 看起来没问题」——它不检查安全漏洞，不查依赖风险，不看你这段代码三个月后会不会让你吃一个 CVE。

核心门禁 = SAST + secrets scanning + human review。Copilot approval 是对 approval 这个动作的自动化，不是对安全责任的替代。