让AI代码代理审查PR：如何在不放开合并权限下确保安全

AI编程代理正在快速渗透进软件开发的日常流程，从生成代码到审查Pull Request（PR），它们承担的职责越来越多。但一个核心矛盾也随之浮现：既想让AI代理帮忙审查代码、加速评审流程，又不敢把无限制的合并权限交给它们。原始素材围绕这一议题，提出了一套通过GitHub权限控制、Airlock治理机制来约束AI代理行为的思路。

为什么不能直接给AI代理合并权限

把代码合并进主分支是一个高风险操作。一旦AI代理拥有无限制的merge权限，它就可能在缺乏充分人工把关的情况下将代码推入生产分支。更棘手的是一种特定风险：代码在获批之后又发生了变更。

设想这样的场景——一个PR经过审查获得批准，但随后有人（或另一个代理）向该分支追加了新的提交。如果AI代理只认"已批准"这个状态就执行合并，那么实际被合入的代码与当初被审查通过的代码已经不是同一份。这类"审批后篡改"是供应链攻击和意外错误的常见入口。

因此，让AI代理参与代码审查的关键不在于"给不给权限"，而在于"如何精细地划分权限边界"，把审查能力与合并能力解耦。

**供应链攻击（Supply Chain Attack）**是近年来软件安全领域的重大威胁之一。典型案例包括2020年的SolarWinds事件——攻击者在构建流水线中注入恶意代码，最终影响数万家下游用户。在AI代理参与代码审查的场景下，"审批后篡改"制造了一个类似的攻击窗口：恶意行为者可以故意在PR获得批准后、代理执行合并前的间隙，快速向该分支追加一个看似无害的提交，将有害代码夹带进主干。由于这段窗口期极短，人工审查往往难以察觉。这也是为什么光靠事后审计不够——必须在合并动作触发前，以技术手段强制验证代码快照的一致性。

用GitHub权限精细控制AI审查角色

素材给出的第一层防护是在GitHub层面配置权限。核心思路是让AI代理只获得代码审查（review）所需的最小权限，而不授予直接写入或合并主分支的能力。

具体做法通常包括：

• 为AI代理创建独立的身份（如GitHub App或专用账号），而非复用人类开发者的高权限凭证
• 通过分支保护规则（branch protection rules）限制谁能合并到受保护分支
• 允许代理提交审查意见、发起评论，但把"最终合并"这一动作保留给人类或受控的自动化流程

这样即便AI代理判断某个PR"看起来没问题"，它也无法自行完成合并，必须经过额外的治理关卡。

GitHub App 是实现AI代理独立身份的推荐方式。与Personal Access Token（PAT）相比，GitHub App拥有独立的身份标识、细粒度的权限范围（repository permissions），并支持按仓库级别安装，权限可精确控制到"只读内容+提交Pull Request Review"而不授予任何写入或合并能力。分支保护规则（Branch Protection Rules）是另一道关键防线：管理员可以要求合并前必须通过若干"required status checks"、指定数量的人工批准，以及启用"Require approvals from code owners"等选项。这些规则在服务器端强制执行，即使一个代理在客户端具备技术上的写入权限，若不满足保护规则也无法将代码推入受保护分支。两者结合，即便AI代理的凭证泄露，攻击面也被限制在审查权限范围内，而非整个仓库的写入控制。

Airlock：为合并动作设立治理关卡

素材中特别提到用 Airlock 来治理合并（govern merges）。Airlock在这里扮演的是一个"气闸"式的控制层——正如其名字所暗示的，它在批准与真正合并之间插入一道可控的隔离屏障。

Airlock机制的价值主要体现在两个方面：

强制校验审批后的代码状态

最重要的一条规则是：阻止代理合并那些在批准之后发生了变更的代码。换句话说，Airlock会校验当前待合并的代码是否与被审查、被批准时的代码保持一致。一旦检测到审批之后有新的改动，合并动作就会被拦截，需要重新审查。

这直接堵住了前面提到的"审批后篡改"漏洞，确保"审查了什么，就合并什么"。

把自动化限制在可控范围内

通过Airlock这样的治理层，团队可以让AI代理承担繁琐的审查工作、给出反馈，同时把关键的合并决策纳入统一的策略引擎。这既保留了自动化带来的效率，又不至于让代理越权。

Airlock 这一命名来自航天与生物安全领域的"气闸舱"概念——进入下一个环境之前必须经历一个受控的中间状态，两侧的门不能同时打开。在软件供应链安全语境中，类似的机制也出现在其他领域：SLSA（Supply-chain Levels for Software Artifacts）框架要求构建产物从源码到发布的每一步都有可验证的来源证明；GitHub 原生的"Required Deployments"和部分第三方 Policy-as-Code 工具（如 OPA/Conftest）也能在合并前插入校验逻辑。Airlock 的核心价值在于将"批准"与"执行"在时间和逻辑上解耦：批准记录的是某一特定代码快照被认可，而执行时必须重新验证当前代码与该快照的一致性，防止中间人攻击或竞态条件导致"批准A、合并B"的安全漏洞。

这套思路对团队意味着什么

从工程治理的角度看，这套方案传递出一个清晰的原则：能力授予应遵循最小权限，敏感操作应设独立关卡。AI代理进入研发流程的趋势不可逆，但"信任但要验证"依然是底线。

对于正在评估AI代码审查工具的团队，可以从这几个维度考量：

• 代理的身份和权限是否可独立配置、可审计
• 是否能在审批与合并之间设置强制校验
• 能否检测并阻止审批后代码变更这类隐蔽风险

需要说明的是，原始素材信息较为简略，更多是提出框架性思路而非详尽的实现教程。实际落地时，仍需结合团队自身的CI/CD流程、分支策略以及所选工具的具体能力进行配置。

小结

AI代理审查PR是提升研发效率的有效手段，但合并权限必须谨慎对待。通过GitHub层面的最小权限配置，加上Airlock这样的治理关卡强制校验审批后的代码一致性，团队可以在享受自动化红利的同时，守住代码安全的底线。核心在于把"审查"和"合并"这两件事拆开——让代理帮你看，但让受控机制来把最后一道关。