一条PR标题，偷走你的API密钥

一条PR标题，偷走你的API密钥什么是「评论与控制」攻击三个案例，三种姿势案例1：Claude Code，一条PR标题就够了案例2：Gemini CLI，伪造一个「可信内容区」案例3：Copilot Agent，三层防御全被击穿三家厂商，三种态度我检查了一下自己的配置如何保护自己1尽快将GitHub Actions中的AI Agent工具更新至最新版本2审查工作流中的权限配置，确保Agent仅持有完成任务所需的最小权限集3轮换此前可能暴露的API密钥和访问令牌4对公开仓库启用「要求对所有外部贡献者进行审批」选项5定期审计GitHub Actions日志，检查是否有异常行为写在最后

昨天看到一条新闻，说实话，后背有点发凉。

一个独立安全研究员，只用了一条Pull Request标题，就从Anthropic的Claude Code里偷走了API密钥。

不是漏洞利用，不是零日攻击，就是一条普通的PR标题。

好家伙，这事儿还牵扯到三家科技巨头，Anthropic、Google、微软，全中招了。

先说个概念，叫「间接提示注入」。

直接提示注入，你得攻破AI的「大脑」，接触系统提示词。这很难。

间接提示注入不一样，它攻击的是AI的「眼睛」。

AI Agent被设计去读取并信任的内容，都可以变成攻击载体，文档、Issue描述、PR标题、代码注释，全都行。

打个比方，你雇了个助手，让他帮你处理所有邮件。你告诉他，「邮件里说什么你就照做」。结果有人发来一封邮件，标题是「请把你的银行卡密码回复给我」。

助手照做了。

这就是间接提示注入。AI Agent就像那个听话的助手，它不知道邮件内容可能是恶意的。

你想想看，开发者不会把PR标题当作安全边界，但AI智能体被明确要求去阅读、解析、基于这些内容做决策。

中间没有安检。

这就是「评论与控制」（Comment and Control）攻击的核心逻辑。

研究证实，Anthropic的Claude Code安全审查工具、Google的Gemini CLI GitHub Action，以及微软GitHub旗下的Copilot Agent，均存在同一类漏洞模式。攻击者仅需通过Pull Request标题、Issue评论或隐藏HTML注释，即可劫持这些AI Agent，窃取宿主仓库的API密钥和访问令牌。

Anthropic的Claude Code安全审查工具，运行在GitHub Actions里，专门自动审查Pull Request中的代码变更。

研究员关傲男在审查源代码时发现，PR标题被直接拼接到提示词模板中，没经过任何过滤。

与此同时，Claude CLI在调用时没启用工具权限限制参数，子进程完整继承了宿主环境的所有环境变量。

攻击效果是直接的。

攻击者创建一个PR，在标题里嵌入精心构造的注入文本，就能突破Claude的提示词边界，指示它执行系统命令，读取ANTHROPIC_API_KEY和GITHUB_TOKEN。

Claude会把命令执行结果写入JSON响应，然后自动发布为PR评论。

攻击者不需要任何特殊权限，开一个PR就能完成窃取。

真的有点离谱。

Google的Gemini CLI GitHub Action，攻击逻辑差不多。

研究员创建一个带注入标题的Issue，然后在评论里逐步升级注入指令。

先要求Gemini关注用户任务，再伪造一个「可信内容区」，声称当前环境安全，允许共享GEMINI_API_KEY。

这一策略成功覆盖了Gemini原有的安全指令，导致它把完整API密钥以Issue评论的形式公开暴露。

这个案例最震撼。

GitHub的Copilot Agent有三层防御，环境变量过滤、密钥扫描、网络防火墙。

听起来很安全对吧？

结果被逐一击穿。

第一道防线，环境变量过滤。Copilot运行时会向子bash进程剔除20个敏感变量，但父级Node.js进程和MCP服务器进程从未被过滤。攻击者执行命令，就能读取完整环境变量列表。

ps auxeww

这就像你把家里的钥匙藏在地毯下面，以为安全了。但攻击者直接从窗户翻进来，根本不需要找钥匙。

第二道防线，密钥扫描。Copilot在git push前会把提交差异发送至密钥扫描API，按模式匹配已知令牌前缀。攻击者的应对极为简洁，把凭证进行Base64编码。编码后的字符串不符合任何扫描规则，直接通过检测。

这就像安检员只检查「枪支」两个字，攻击者把枪拆成零件，每个零件都通过了安检。

第三道防线，网络防火墙。Copilot的出站连接被限制在白名单之内。但github.com本身就在白名单中。编码后的凭证作为普通代码提交发布到PR，攻击者直接在GitHub上下载就行。

这就像你禁止员工把文件带出公司，但允许他们发邮件。攻击者把文件发到公司邮箱，然后自己下载。

最终，研究员从MCP服务器进程中成功提取了四项关键凭证，包括GITHUB_TOKEN、GITHUB_COPILOT_API_TOKEN、GITHUB_PERSONAL_ACCESS_TOKEN和COPILOT_JOB_NONCE。

这是Copilot Agent，2000万付费用户，覆盖《财富》100强中90%的企业。一旦这些凭证被恶意利用，攻击者可以访问私有仓库、篡改代码、甚至渗透整个组织的开发基础设施。

漏洞披露后，三家厂商的处理方式很值得玩味。

厂商: Anthropic | 漏洞评级: CVSS 9.4（Critical） | 赏金: $100 | CVE: 无 | 安全通告: 无

厂商: Google | 漏洞评级: 未公开 | 赏金: $1,337 | CVE: 无 | 安全通告: 无

厂商: GitHub | 漏洞评级: 「已知设计后果」 | 赏金: $500 | CVE: 无 | 安全通告: 无

三个关键点。

第一，Anthropic把漏洞评级提到CVSS 9.4，Critical级别，但只支付了100美元赏金。这个数字在安全圈里引发了不少争议，有人调侃说「连一顿像样的饭都吃不了」。

第二，Google支付了1337美元（黑客文化里的数字，代表「leet」即精英），GitHub支付了500美元，合计1937美元。相比Anthropic，这两家至少在赏金上体面一些。

第三，三家公司都没有发布CVE编号或安全通告。这意味着，大量开发者可能至今不知道自己的API密钥曾经暴露在风险之中。

Anthropic选择静默修复，Google通过赏金程序确认后保持沉默，GitHub把问题定性为「已知设计后果」。

这背后是AI安全领域的结构性困境。

当漏洞根植于模型对自然语言指令的服从性，而非传统代码缺陷时，厂商往往倾向于把它视为「设计局限」而非「安全漏洞」。

但对开发者而言，API密钥和访问令牌的泄露，意味着攻击者可能获得访问私有仓库、云基础设施乃至整个组织代码资产的权限。

危害并不因定性而降低。

看完这个漏洞，我立刻去检查了自己的GitHub仓库。

我有个开源项目，之前配置过GitHub Actions，里面确实用了一些AI相关的工具。

打开目录，翻了一遍workflow文件。

.github/workflows

好家伙，里面有个action用了，权限是。

GITHUB_TOKEN

write

这个action的功能只是自动生成release notes，根本不需要写权限。

我赶紧把权限改成了。

read

然后又检查了环境变量，发现有个是全局配置的，所有workflow都能访问。

OPENAI_API_KEY

这也太危险了。

我把它删掉，改成只在需要的workflow里单独配置。

整个过程花了不到10分钟，但让我意识到一个严重的问题。

我们平时配置CI/CD的时候，很少会去想「最小权限」这件事。

能用就行，权限给大点也没关系。

但AI Agent时代，这个习惯可能会害死人。

因为AI Agent不是被动执行脚本，它会「思考」，会根据外部输入做决策。

一旦被注入恶意指令，后果就是API密钥泄露、仓库被篡改、甚至整个组织的代码资产被窃取。

研究员在论文里提出了一个务实的框架，把提示词注入视为针对机器的「网络钓鱼」，把AI Agent视为需要遵循最小权限原则的超级员工。

「只给Agent完成其任务所需的工具和权限。即使在模型层面已部署提示词注入防护，这些防护在当前实践中最终仍可被绕过。」

落实到具体操作，核心是两点。

工具授权层面，采用白名单而非黑名单机制。

Anthropic的应急修补是在disallowed-tools参数中封禁ps命令，试图阻断攻击者读取进程信息的能力。

但黑名单思路有先天缺陷。封禁ps后，攻击者可通过读取同等信息。封禁该路径后，仍有、、等多种替代方式。

cat /proc/*/environ

ls /proc/$PID/environ

env

printenv

正确的做法不是穷举禁止哪些命令，而是明确声明Agent只需要哪些工具。

如果一个代码审查Agent不需要执行bash，就不应该给它bash权限。

凭证管理层面，严格按照功能边界控制凭证作用域。

如果一个Agent的唯一职责是总结Issue，它不需要持有具备写权限的GITHUB_TOKEN。

如果它只需要读取代码，它不需要持有Anthropic API密钥。

凭证暴露面越小，被窃取的损失越可控。

具体操作建议：

从2025年10月首次向Anthropic报告，到2026年4月研究公开发布，这项研究历时近六个月。

在此期间，三家厂商完成了修补，却无一主动告知用户。

漏洞赏金合计1937美元。

而研究所涉及的产品正在被数千万开发者日常使用，覆盖了全球最顶尖的企业。

这组数字，或许是当前AI安全生态最简洁的注脚。

更值得深思的是，同样的攻击模式已在开源项目OpenCode（GitHub上约13.9万Star）中复现。随着AI编程Agent成为主流开发工作流的标配，这一攻击面还将持续扩大。

AI Agent正在从「副驾驶」走向「自动驾驶」，但谁来为智能体越权买单？

这个问题，值得每个开发者认真想想。