当 AI 编码智能体能够自主修改代码、运行测试并提交合并请求时，研发效率会显著提升，但风险也从“生成的代码是否正确”扩展到权限滥用、依赖投毒、流水线篡改与制品来源不明。🔐 因此，企业不能把智能体视为普通开发者，也不能仅靠人工看一遍差异，而应建立覆盖身份、审查、构建、制品和部署的分层防线。
一、先明确原则：智能体可以提议，不能自行获得信任
AI 智能体提交的合并请求应默认属于“不可信输入”。无论它是否通过单元测试，均不应自动合并到受保护分支，更不能直接触发生产发布。合理的职责边界是：智能体负责生成候选变更、解释修改理由和补充测试；人类与安全策略负责确认业务意图、风险范围和最终授权。
仓库应启用分支保护或规则集，禁止直接推送、强制推送和绕过审查；高风险目录还应配置代码所有者审批。涉及身份认证、权限控制、支付、加密、部署脚本、基础设施即代码及 CI/CD 工作流的变更，建议要求至少一名对应领域维护者参与审查，而不是只检查“测试是否变绿”。
二、为智能体建立最小权限身份
不要让智能体共享员工账号、长期访问令牌或拥有仓库管理员权限。应为其创建独立的机器身份，限制可访问的仓库、分支和操作类型，并优先使用短期凭据。智能体通常只需要创建分支、提交代码和发起合并请求，不需要修改保护规则、读取生产密钥或批准自己的变更。
- 身份隔离：提交记录、审计日志和合并请求中明确标识智能体身份及其调用来源。
- 权限隔离：将“写代码”“批准合并”“发布制品”“部署生产”拆分给不同主体。
- 环境隔离：在临时沙箱中运行智能体，不挂载开发者个人凭据和生产配置。
- 密钥隔离：来自外部贡献或不可信分支的流水线不得读取高权限密钥。
三、让合并请求具备可审查性
代码审查的前提是变更足够小、理由足够清楚。应限制单次任务的文件数量、代码行数和可修改目录，要求智能体在合并请求中列出需求来源、主要改动、测试结果、依赖变化、潜在风险及回滚方式。发现大规模格式化、无关重构或生成文件混入时，应拆分后再审。
审查者不能只阅读智能体生成的说明，因为说明本身也可能遗漏问题。应从原始需求反向核对代码，重点检查权限边界、异常处理、输入验证、日志中的敏感信息、网络访问、文件操作以及默认配置。同时关注“被删除的保护措施”，例如校验逻辑、速率限制、安全响应头或审计事件。
审查目标不是判断 AI 写得像不像人，而是确认这项变更是否符合真实意图、是否引入不可接受的攻击面，以及失败后能否快速恢复。
四、把安全检查设置为不可绕过的合并门禁
自动化检测应作为必需状态检查运行，包括构建、单元测试、集成测试、静态应用安全测试、密钥扫描、许可证检查、依赖漏洞扫描和基础设施配置扫描。对于关键模块，还可增加模糊测试、属性测试和针对历史漏洞的回归用例。🚦 检查失败时应阻止合并，而不是允许智能体通过修改测试或忽略规则来“消除红灯”。
安全规则本身也应受到保护。若合并请求修改测试、扫描配置、工作流文件、依赖锁文件或排除列表，应提高风险等级并触发专项审批。可以利用 OpenSSF Scorecard 检查分支保护、危险工作流、依赖固定和令牌权限等项目实践，但评分只能作为风险信号，不能代替具体审查。
五、重点防范依赖与构建链路被污染
智能体可能为了快速完成任务而引入名称相似、维护不足或来源不明的组件。新增依赖必须说明用途、版本、许可证和替代方案，并检查维护状态、已知漏洞及发布来源。依赖要通过锁文件固定版本；CI 中引用的外部自动化组件宜固定到不可变提交摘要，避免可变标签被替换。
构建环境应使用经过批准的基础镜像和集中维护的流水线模板，默认关闭不必要的外网访问，并记录构建输入。生产制品必须由可信 CI 根据已审查的提交重新构建，不能直接采用智能体沙箱中生成的二进制文件。OpenSSF 指出，源代码仓库中的二进制制品难以像源码一样审查，相关风险和检查方式可参考 Scorecard 检查说明。
六、用 SBOM、签名和来源证明连接提交与制品
通过代码审查并不代表最终发布物一定来自该代码。构建流水线应为制品生成软件物料清单，也就是 SBOM，并记录提交摘要、构建器身份、工作流和依赖材料。SLSA 软件证明模型将证明描述为针对软件制品的已认证元数据，可供自动化策略引擎验证。
容器镜像、安装包和二进制文件还应进行签名。Sigstore支持使用临时密钥和短期证书签名，并记录可审计的签名事件。若团队采用 GitHub Actions，也可参考 GitHub 制品证明文档，将仓库、提交、工作流和构建制品关联起来。关键不只是“生成证明”，还要在发布或部署入口强制验证签名者身份、来源仓库、工作流和制品摘要。
七、建立风险分级与事件响应闭环
并非所有 AI 变更都需要相同强度的流程。文档、注释和低风险测试可采用常规审批；依赖升级、公共接口和数据结构变更需要增强验证；认证授权、密钥处理、构建发布及生产配置则应采用双人审批、隔离构建和部署前证明验证。风险等级应由目录、文件类型、权限变化和依赖变化自动判定，而不是由智能体自行声明。
- 保存智能体任务输入、工具调用、提交摘要、审批记录和流水线结果。
- 为异常依赖、敏感文件修改、大规模删除和安全配置降级建立告警。
- 准备快速回滚、撤销凭据、隔离制品和暂停机器身份的操作手册。
- 定期抽查已合并变更，通过误报、漏报和返工原因持续优化门禁。
总结
保障 AI 编码智能体自主提交合并请求后的安全，核心不是增加一次形式化审批，而是构建“智能体提出、人类授权、策略验证、可信环境构建、部署入口验真”的完整链路。✅ 当最小权限、受保护分支、强制检查、依赖治理、SBOM、制品签名和来源证明共同生效时，团队才能在提升开发效率的同时，让每一项变更可审查、每一个制品可追溯、每一次发布可阻断并可回滚。
