『这个值安全』由谁在动作前重验：三家 coding agent 的信任交接断裂

一条任何人都能发的 GitHub issue——零权限、零账号信任——从 Anthropic、Google、OpenAI 自家仓库的默认 CI 工作流里抽走了密钥。Novee Security 在 Black Hat USA 2026 的演示里，模型每一步都表现得完全正常：被利用的不是智能，是包在模型外面那层叫 harness 的代码。漏洞不在模型，在信任交接——一层把值标记为『安全』，另一层带着更高权限直接信任它，中间没有任何复核。

一个 GitHub issue，三家厂商的默认配置

Novee 的方法是把每家厂商自己的 agent、自己的仓库、默认 workflow 当作测试对象；攻击入口是 GitHub issue 或 PR 的文本，任何人都能提交。三家厂商三套代码，同一类失败（来源：Novee Security 原始披露）。

Claude Code（CVE-2026-54316，修复于 2.1.163）：命令校验器先剥离单引号内容，再对剩余命令做 23 项安全检查——这在 bash 语义上是对的，但藏在 git push --receive-pack='sh -c …' 引号值里的 payload 因此绕过校验，在宿主执行。随后 tac、rev、fold 被硬编码为只读却从不检查路径，能读 /proc/self/environ；输出默认写入公开的 GitHub Actions Step Summary，反转字符串就能绕过 secret masking。最后一轮不再需要任何『写』动作：huggingface.co 在预批准域名列表，攻击者创建 64 个模型仓库，用公开下载计数器逐字符外泄密钥。三轮 patch-and-bypass，一轮比一轮安静（来源：GitHub Advisory GHSA-fg94-h982-f3mm）。

Gemini CLI（CVE-2026-12537，CVSS 10.0，修复于 0.39.1 / run-gemini-cli 0.1.22）：headless CI 模式自动信任工作区，加载 .gemini/.env 里的配置与环境变量——恶意 .env 在沙箱启动前注入 OS 命令，以宿主权限执行。Google 的『进程隔离』实际只是环境清理：子进程环境被过滤，父进程仍持有全部秘密，cat /proc/$PPID/environ 直接读出。同时 --yolo 模式下，settings.json 里细粒度工具 allowlist 从未在运行时生效——一个被解析却从未执行的 allowlist，比没有更糟（来源：GitHub Advisory GHSA-wpqr-6v78-jr5g）。

Codex（无 CVE，设计问题）：openai/codex 的自动化流程在一个 job 里跑两段式 review，共享同一 checkout 目录。AGENTS.md 是 Codex 每次启动都会读取的操作指令文件。第一段——被 issue 内容注入控制——写入恶意 AGENTS.md；第二段读取它，以完整 job 权限执行攻击者的指令。OpenAI 的回应是结构性的：两段拆成独立 job 与独立 checkout、只读沙箱 + drop-sudo，并把 AGENTS.md 在自动化工作流中正式定义为不可信输入（来源：Novee Security 原始披露）。

外泄预言机：不绕过边界，而是利用边界

三项研究里最值得记住的是最后那步：Claude Code 的 Hugging Face 通道。HuggingFace 的下载计数器对每个 HTTP 请求（含 GET/HEAD）计数，且公开可读。攻击者创建 64 个仓库，一个对应密钥的每个可能字符；通过注入，指示 Agent 读取密钥第 N 位，再 fetch 对应字符的仓库（如 attacker/char-a/resolve/main/config.json）。恰好一个仓库的下载计数器 +1；攻击者轮询全部 64 个计数器，按时间戳排序，逐字符还原完整 API key。全程没有指向攻击者服务器的连接、没有写操作、没有日志异常——一个只读 GET 就把秘密带出去了。

它揭示的边界问题比技术本身更重要：allowlist 回答的是『允许连哪些服务』，不是『允许向每个服务发送什么内容』。Meged 没有绕过 allowlist，他使用它——被批准的域名可以被指示发送任何内容。限制 agent 能到达哪些服务是必要但不充分的；边界必须定义到动作级与内容级。

我们的判断：信任必须在消费点重验

Novee 自己的总结一针见血：『harness 在某一层把值标记为安全，后一层带着更高权限信任这个标记，中间没有复核。』三个案例同一个形状：校验器正确剥离了引号（标记安全），被剥离的值流向了更特权的执行步骤；allowlist 正确记录了条目，执行时从未校验；沙箱按文档运行，第一段的输出成了第二段的指令。防御层都在，缺的是标记与执行之间的重验点。我们的判断是：『这个值安全』的判断必须由执行侧在动作发生前独立重验，而不是被前端决策层标记一次就永远有效；边界在动作级，不在服务级。

两个推论。第一，对每个 agent 集成点，找到『标记安全 → 更高权限执行』的交接，在交接处插入来源绑定与动作前授权验证——问『这个值来自哪里、它被允许做什么』，而不是继续信任早先的标记。第二，把 allowlist 的审查从『允许连哪些域名』扩展为『agent 被允许向每个服务发送什么』；公共计数类服务（下载计数器、指标 API）本身就是潜在外泄通道，只要 agent 可以被指示往上面写内容。

这与我们对 Agent 治理的整体判断一致：模型不是安全边界，动作才是。厂商会把『沙箱按文档运行』当作挡箭牌；但文档化的不安全行为仍然是攻击面。买家的采购清单里，应该要求厂商明确『标记为安全的值，在执行时是否被重新验证』。

对买家意味着什么

AI App lead：CI 里跑 coding agent 的团队，先 pin 版本——Claude Code ≥2.1.163、Gemini CLI ≥0.39.1、run-gemini-cli ≥0.1.22；多段式 agent job 必须拆独立 checkout；按任务分配最小 secret，不给整仓库 token；把 issue/PR body、AGENTS.md、任何用户可控文本当不可信输入。

安全团队：审查服务 allowlist 时，把『允许发送什么内容』加进评审清单；对 agent 的输出通道（Step Summary、日志）做反向字符串等绕过模式的检查；假设自己仓库里的 agent 工作流也存在同样的交接缺口，逐条排查『标记安全 → 执行』路径。

给你的行动建议

立即：确认 CI 里 agent 版本并 pin 到修复线以上；检查是否有 fork/issue 触发的工作流会把用户可控文件写入 AGENTS.md 等指令文件。本周：把『allowlist 允许发送的内容』加入评审；对使用公共计数类服务的 agent 动作加限制。长期：为每个 agent 集成点建立『标记安全 → 动作执行』之间的重验机制（来源绑定 + 动作前授权），并把『执行时是否重验安全标记』写进 agent 工具的采购评估。

参考来源: Novee Security：Black Hat 2026 原始披露（2026-08-06） · GitHub Advisory：CVE-2026-54316（Claude Code 外泄通道） · GitHub Advisory：Gemini CLI 信任模型更新（CVSS 10.0）。注：Google 漏洞的 CVE 编号归属存在公开歧义（CSA 与 The Hacker News 关联为 CVE-2026-12537，GitHub advisory 本身未分配 CVE），本文按 Novee 与厂商 advisory 口径引用。