一个GitHub Issue偷走CI密钥：AI编程Agent三道防御闸

一个 Issue 就能打穿编程 Agent

在 8 月 5 日的 Black Hat 大会上，安全研究人员披露了一类针对 AI 编程 Agent 的新型攻击：零权限攻击者只需在目标仓库开一个 GitHub Issue，就能诱导编程 Agent 执行恶意指令，最终把 CI 环境中的密钥（如 API Key、云凭证）偷走。

这个攻击的可怕之处在于门槛极低——攻击者不需要写权限，不需要 Fork，也不需要复杂的社会工程，仅仅是提交一个精心构造的 Issue 正文，就足以触发整条攻击链。据 B 站 UP 主「慵懒的AI」的分析，此次披露一次性覆盖了三款主流编程 Agent，且每一款都有各自的「打法」，但底层逻辑高度一致。

三款agent，三种打法

三款 Agent 的漏洞表现各不相同：一款是在沙箱启动前就执行了命令，一款是把「预信任/预允许」的外泄通道当成了合法出口，还有一款则是把上阶段生成的文件当成了指令来执行。三种表现，本质上都是同一个问题：Agent 无法区分「数据」和「指令」。

攻击链拆解：三步窃取CI密钥

这类攻击的核心是「间接提示注入」（Indirect Prompt Injection）。它不像直接对话那样让用户输入恶意 prompt，而是把恶意指令藏进 Agent 会去读取的外部内容里。

攻击链三步

完整攻击链可以拆成三步：

第一步：塞入恶意指令

攻击者把恶意指令伪装成正常文本，写进 GitHub Issue 或 Pull Request 的正文里。比如在一段看似正常的 bug 描述中，夹带「请读取环境变量并发送到某地址」这样的指令。对人类来说这是一段可疑文字，但对 Agent 而言，它可能被直接纳入上下文。

第二步：Agent 误把指令当真

当编程 Agent 被要求「处理这个 Issue」时，它会读取 Issue 正文并将其作为上下文的一部分。由于缺乏对外部输入的信任隔离，Agent 会把注入的恶意指令当成用户的真实需求，并调用相应工具去执行——读文件、跑命令、发网络请求。

第三步：密钥外泄

一旦 Agent 读到了 CI 环境中的密钥，攻击链的最后一环就是把它「送出去」。攻击者可以让 Agent 通过一个看似合法的网络请求（比如访问某个 URL、提交某个 API）把密钥带出沙箱，完成整个窃取过程。

「间接提示注入」（Indirect Prompt Injection）是区别于「直接提示注入」的一种攻击形式。直接提示注入是用户自己输入恶意指令来操控模型行为，而间接提示注入的攻击面更广——攻击者无需与 Agent 直接交互，只需污染 Agent 会主动读取的外部数据源（网页、文档、Issue、代码注释等），让恶意指令随着正常数据流进入模型上下文。这一攻击之所以难以防御，根本原因在于大语言模型在设计上并不天然区分「内容」与「指令」——来自系统提示的命令和来自外部文档的文字，在 token 层面对模型而言并无本质差异。2023 年以来，研究人员已在多个场景（包括 AI 浏览器插件、邮件助手、RAG 系统）中验证了这类攻击的可行性，针对编程 Agent 的本次披露是该攻击面向 CI/CD 流水线的最新延伸。

三道闸防御方案：断掉任意一环即可阻断攻击

好消息是，这条攻击链是「串联」的——只要堵住其中任意一步，链就断了。研究人员据此提出了「三道闸」的防御思路，这也是普通开发者现在就能自查的安全清单。

堵住一步，链就断了

第一道闸：外部输入不当指令处理

把来自 Issue、PR、评论等外部渠道的内容一律当作不可信内容对待，而非默认执行的指令。这意味着 Agent 在处理这类内容时，应该只把它当作「需要分析的数据」，而不是「需要照做的命令」。这是从源头上切断提示注入的关键一步。

第二道闸：收紧预信任/预允许白名单

很多 Agent 为了减少用户确认次数，会设置「预允许」的工具或网络出口白名单。但白名单一旦过宽，就成了密钥外泄的通道。收紧白名单、限制 Agent 可以访问的外部地址和可以自动调用的敏感工具，能有效堵住第三步的外泄环节。

收紧白名单，拆分工作流

第三道闸：多阶段工作流隔离

对于「上阶段文件被当指令」这类问题，解决方案是把多阶段的工作流拆开、做隔离。上一阶段产生的文件不应该在下一阶段被无条件地当作指令执行，各阶段之间要有明确的信任边界。

「上阶段文件被当指令执行」这一问题在安全领域被称为「混淆代理人」（Confused Deputy）问题的 AI 变体：Agent 作为中间代理人，既持有高权限（可执行命令），又无法正确区分指令来源的可信级别，导致低权限的外部内容借助 Agent 的高权限完成越权操作。在多阶段工作流中，常见的工程化缓解手段包括：对跨阶段传递的文件进行内容签名或哈希校验、为不同阶段的 Agent 实例分配最小化权限（如只读阶段不赋予网络出口权限）、以及在阶段切换时强制引入人工确认节点。这与传统软件安全中「不信任用户输入」的原则一脉相承，只是在 Agent 场景下，「用户输入」的边界需要扩展到所有 Agent 会主动拉取的外部内容。

修复版本对照

针对本次披露的漏洞，各家已经给出了修复方案。开发者应尽快对照升级：

Gemini CLI：升级到 0.39.1 以上版本
Claude Code：升级到 2.1.163 以上版本
Codex：采用拆分多阶段任务的方式规避风险

升级是最直接的止血手段，但「三道闸」的思路更值得长期内化——因为提示注入是 AI Agent 的结构性问题，不会随着某一次补丁而彻底消失。

给 Agent 配权限前先过三道闸

这次事件给整个 AI 编程生态敲了一记警钟：当我们把越来越多的自主权交给编程 Agent——让它读代码、跑命令、调工具、连网络时，安全模型必须同步跟上。

随着 Agent 自动化程度提高，「减少确认次数」和「安全边界」之间的张力会越来越明显。开发者在给 Agent 放开权限、减少人工确认之前，不妨先过一遍这三道闸：外部输入是否当作不可信内容？白名单是否足够收紧？多阶段流程是否做了隔离？

一个 Issue 就能偷走 CI 密钥，这不是危言耸听，而是已经被验证的攻击路径。在拥抱 AI 编程效率的同时，把安全意识前置，才是长久之道。