导语：当 AI 编程智能体从“代码建议工具”升级为能够读取仓库、安装依赖、运行测试并自动提交拉取请求的执行者，软件开发的效率边界正在被重新定义。然而，自动化能力越强，攻击者可借用的权限与传播路径也越多。过去主要围绕开发者账号和 CI/CD 流水线展开的供应链防护，如今必须把智能体的输入、身份、工具调用、提交记录和运行环境一并纳入审计。🤖🔐
一、自动提交代码为何改变了风险模型
传统代码助手通常只生成片段，是否复制、修改和提交由开发者决定。智能体则可能根据 Issue、仓库文件、评论或外部文档自主制定计划，再执行编辑文件、调用命令、更新依赖和创建分支等操作。此时，风险不再局限于“生成了一段不安全代码”，而是扩展为“一个能行动的数字身份是否被恶意内容误导”。
以云端编程智能体为例，平台通常会通过沙箱、受限网络、分支保护和人工合并降低风险。GitHub 的安全说明指出，其云端智能体只能由具备写入权限的用户触发，推送范围会受到分支限制，生成的草稿拉取请求仍需人工审查后才能合并。平台还可使用代码扫描、密钥扫描和依赖漏洞检查发现部分问题，相关行为能够在会话日志中查看。[1]
这些机制提供了基础防线，但不能替代企业自身的权限治理。尤其需要警惕，某些团队为了追求“全自动交付”，可能允许智能体触发 CI/CD 工作流、读取构建密钥或修改流水线配置。官方文档明确提醒，若取消工作流运行前的人工批准，未经审查的代码可能获得仓库写权限或接触 GitHub Actions 密钥。配置说明
二、供应链投毒可能从哪些入口发生
1. 仓库内容中的提示注入
智能体会把源代码、Issue、评论、README、测试输出和配置文件当作任务上下文。攻击者可能在这些内容中植入诱导性指令，例如要求关闭安全检查、上传环境变量或执行经过伪装的脚本。如果智能体不能区分“项目资料”和“可信命令”，普通文本就可能变成间接控制入口。🧪
2. 恶意依赖与名称混淆
当智能体为解决编译错误而自动搜索并安装软件包时，可能选中名称相似、维护状态异常或来源不明的依赖。攻击者还可以通过安装脚本、构建插件和传递依赖影响开发环境。即使新增包本身没有公开漏洞，也不代表其发布流程、维护者账号和构建产物可信。
3. 工作流与构建脚本被篡改
修改应用代码通常容易引起审查，而对工作流文件、容器配置、包管理脚本和发布任务的微小改动更容易被忽略。例如扩大令牌权限、把第三方 Action 从固定提交版本改为浮动标签，或在测试命令中加入网络请求，都可能为后续投毒打开通道。
4. 自动提交形成可信外观
智能体提交往往具有规范的说明、测试结果和机器人身份标识，容易产生“平台已验证”的心理暗示。实际上，代码通过静态扫描只能说明未发现特定模式，并不能证明业务逻辑、依赖来源和权限变化完全安全。因此，机器人创建的拉取请求不应获得天然更高的信任级别。
三、权限审计正在出现哪些新趋势
第一，权限审计从账号扩展到任务级授权。过去常问“这个机器人能访问哪些仓库”，现在还应追问“它在本次任务中能执行哪些动作”。理想模式是为每次任务签发短期凭据，仅允许读取指定仓库、写入临时分支，并在任务结束后立即失效。生产密钥、发布权限和组织级管理能力不应进入通用智能体环境。
第二，审计对象从提交结果扩展到完整行动链。企业需要记录任务发起人、原始指令、读取的上下文、调用的工具、网络目标、命令输出、修改文件、凭据使用情况和最终提交哈希。这样才能在发生异常时回答“智能体为何这样做”，而不仅是看到“它改了什么”。🧭
第三，审批策略从统一门禁转向风险分级。仅修改文档或测试用例的任务可以采用轻量审批；涉及依赖锁文件、身份认证、基础设施配置、工作流、权限策略和发布脚本时，则应自动提升审查等级，并要求代码所有者或安全人员批准。高风险目录还可以禁止智能体单独修改。
第四，验证重点从代码扫描转向来源证明。SLSA 提供了可逐步采用的软件供应链安全框架，强调构建过程、产物来源和防篡改能力，帮助生产者与使用者判断软件制品是否来自预期源代码和受控构建环境。OpenSSF SLSA 项目 与 SLSA 规范网站 都强调，供应链安全不仅要检查成品，还要验证从源代码到构建产物的完整路径。
第五，AI 规则开始成为安全策略本身。团队会逐步把禁止读取敏感目录、不得关闭测试、不得自行扩大网络权限等要求写入仓库级智能体规则。但这类规则也必须受到版本控制、代码所有者审批和防篡改保护，否则攻击者可能先修改规则，再让智能体执行危险操作。
四、可落地的防护与审计清单
- 限制身份：为智能体使用独立服务身份，禁止共享开发者个人令牌，并启用短期凭据和自动轮换。
- 限制仓库：默认只开放经过评估的项目，不允许智能体跨组织、跨租户或批量读取私有仓库。
- 限制分支：仅允许写入专用临时分支，保护默认分支，禁止绕过必需检查和强制审批。
- 隔离运行：在一次性沙箱中执行任务，默认关闭公网访问，通过域名白名单控制包仓库和必要服务。
- 保护密钥：不要把生产凭据注入智能体环境；确需使用时，应按任务、环境和资源范围精确授权。
- 审查敏感变更：对依赖清单、锁文件、工作流、容器文件、部署脚本和权限配置设置强制人工复核。
- 验证依赖：检查包来源、版本固定、维护状态、签名、校验值和已知安全公告，并生成或更新 SBOM。
- 保留证据：集中保存会话日志、工具调用、网络访问、审批记录及构建证明，设置合理留存期限。
- 持续检测：将静态分析、密钥扫描、恶意依赖检测和策略即代码检查放入合并门禁，而不是仅依赖智能体自检。
- 准备回滚：确保智能体提交可单独撤销，发布产物可追溯，并为令牌泄露和依赖投毒建立应急流程。
一个实用原则是：把 AI 编程智能体视为“速度很快、会读取大量上下文、但判断仍需验证的外部协作者”，而不是拥有隐性信任的正式管理员。
NIST 的安全软件开发框架将相关实践归纳为组织准备、软件保护、安全软件生产和漏洞响应等方向，并强调把安全实践嵌入软件开发生命周期。NIST SSDF 同时为软件生产者和采购者提供共同语言，可作为企业制定智能体接入基线、供应商评估和审计证据要求的参考。
总结
AI 编程智能体自动提交代码并不必然带来供应链投毒，但它显著缩短了恶意输入转化为仓库变更的路径，也放大了错误权限配置的影响。新的安全重点不是简单禁止自动化，而是建立“最小权限、任务隔离、来源验证、风险分级审批、完整行为留痕”的闭环。只有让每一次读取、执行、提交和发布都可限制、可解释、可追溯，团队才能在享受智能体效率红利的同时，避免把软件供应链的钥匙交给未经验证的自动决策。🛡️
