当团队开始把代码审查、补丁和发布交给 AI 编码代理时，风险常常不在模型本身，而在包裹它的那一圈"容器"：CI 工作流、命令校验器、工作区信任和 WebFetch 权限。2026 年 8 月初，Novee Security 研究员 Elad Meged 在 Black Hat USA 2026 上披露的研究证实了这一判断——一个没有任何仓库权限的 GitHub Issue，就足以接触到 Claude Code、Gemini CLI 与 OpenAI Codex 所接入仓库的 CI runner secrets。配套的云安全联盟（CSA）研究报告、以及一批顶着 CVSS v4 满分评级的 CVE，把"AI 编码代理的供应链"推到了聚光灯下。
一、Claude Code：剥掉单引号的验证器，加一条逐字符外泄通道
Claude Code Action 的问题出在它的命令验证器上：校验逻辑会先剥掉文本里的单引号再做检查，攻击者于是能构造一个在"剥引号前不起眼、剥引号后变成恶意命令"的载荷，绕过验证。随后，工具链中一条被允许访问 Hugging Face 的 WebFetch 通道，成了外泄信号：攻击者可以利用宿主 API 密钥，通过公开的下载计数器把密钥逐字符"数"出来。这个缺陷被记录为 CVE-2026-54316。它不是模型"被骗造出恶意命令"那种直接攻击，而是工具链把"能访问外部网络"和"能读取密钥"这两件事，和一个不够严的口令校验器耦合在了一起。
二、Gemini CLI 与 OpenAI Codex：契约边界的位移
Gemini CLI 的问题指向更深一层：在 headless 模式下，它会自动扩展对工作区的信任，并主动加载 .env 文件——把本应由用户显式同意的信任决策，变成了默认行为；同时所谓 coreTools allowlist 只在校验时检查、执行时并不强制，留下被绕过的余地。相关记录为 CVE-2026-12537，CVSS v4 最高达 10.0。至于 OpenAI Codex，研究者没有为它申请、也没有拿到 CVE——因为 OpenAI 认为其多 pass 架构下"第一个 agent 写入 AGENTS.md、后续 pass 再读取并执行它"属于文档化的设计行为，而非漏洞。但这恰恰引出研究者的担忧：在多个公开仓库里，仍有大量项目沿用这种默认配置，让"用户提供的指令文件"能够反过来定义代理的行为边界。
三、共同的教训：治理的核心是包围它的 harness，而不是模型
把三个案例放在一起，能看到一条清晰的共性：真正的风险来自 Agent 被装进一个"过度信任"的执行环境。Issue 正文、PR、评论、CI 工作流、文件写入和前向网络访问，这些要么被赋予了过大的权限，要么缺少与信任层级匹配的校验。研究者也在 100 多个公开仓库里看到类似默认配置仍在运行，说明这并非个例。对采用 AI 编码代理的组织，需要把"代理能读到什么、能执行什么、能外发什么"当作一套独立的权限边界来专门治理——它值得跟传统 CI/CD 一样严格的凭证管理与最小权限设计。
四、防御建议
- 收敛代理的读取与执行范围：限制 AI 编码代理可访问的仓库、工作区与 .env 文件，避免无差别的自动信任扩展；
- 严格管控前向网络访问与外部工具：对 WebFetch、submit 等可外发通道做白名单，防止密钥借下载计数器、日志或面向公网的端点外泄；
- 审计 CI 集成：为 AI 代理专用的 runner secrets 设最小化、独立的令牌，而不是复用生产环境的高权限凭证；
- 把 Issue / PR / 评论内容视为潜在恶意输入：在它们能触达的自动化路径上加一层独立的校验，不轻信"看起来来自仓库"的指令。
Claude Code、Gemini CLI 与 OpenAI Codex 的这批发现，把"AI 编码代理中毒"的故事讲得比单纯提示注入复杂得多。真正起决定作用的，是代理四周那圈由工具链默认行为堆出来的信任半径。对安全团队而言，与其焦虑模型的"一句话就被攻破"，不如先把 Agent"能看、能写、能发"的边界一条条收住——这才是当下最可落地、也最直接有效的防线。
*参考：云安全联盟（CSA）2026 年 8 月研究报告、Novee Security 在 Black Hat USA 2026 的披露、以及 CVE-2026-54316 与 CVE-2026-12537 的相关记录与最高评分说明。