我对代理的信任问题：从提示符注入到 gemini-cli 的供应链漏洞
一句话看懂：安全公司 Pillar Security 在 Google 的 AI 代码代理 gemini-cli（超 10 万星标）中发现一组 CVSS 10.0 的严重漏洞，攻击者仅需在公开 GitHub 仓库发布一条 Issue，即可通过提示符注入链式劫持 CI/CD 流水线，最终实现对整个项目的供应链投毒。Google 已在 2 天内修复并发布 gemini-cli 0.39.1 版本。
事件核心：发生了什么
Pillar 研究员 Dan Lisichkin 在 Google 的 AI 驱动 Issue 分类工作流中，发现了一个可被任意外部攻击者利用的“必杀三要素”（Simon Willison 提出的术语：可访问私密数据、可接触不受信内容、可对外通信）组合。具体流程为：攻击者在公开仓库（如 google/draco）发布恶意 Issue → 工作流触发 gemini-cli 以 –yolo 模式（自动批准所有工具调用）运行 → 提示符注入诱导模型读取父进程环境变量（包括 GEMINI_API_KEY 和 OIDC 凭证）并写入 Issue 正文实现数据泄露。分析师进一步发现，该漏洞模板至少存在于 8 个 Google 仓库，其中最有价值目标是 google-gemini/gemini-cli。在该仓库中，虽然 GITHUB_TOKEN 未被显式传递，但 actions/checkout 步骤默认将凭据写入 .git/config 文件，攻击者可诱导代理读取该文件并外传至攻击者服务器。利用该 token（拥有 actions:write 权限），攻击者可触发仓库内的 smoke-test.yml 工作流，该工作流允许指定分支检出，通过伪造的 package.json 文件完成全链的供应链投毒（获取更高权限的 GITHUB_TOKEN）。
为什么重要
这一事件揭示了 AI 代理安全面临的一个系统性问题：当 AI 代理被赋予调用外部工具（如 gh issue edit、shell）的能力时，传统软件安全中的“最小权限原则”和“输入验证”在提示符注入面前几乎完全失效。Google 的防护尝试（不传递 GITHUB_TOKEN 到环境变量）看似合理，但忽略了文件系统持久化凭据这一常见做法，这正是攻击链得以延展的关键。目前公开信息显示，该漏洞并非 Google 独有——任何使用 AI 代理自动处理用户提交内容（尤其是 Issue 和 PR）的 CI/CD 流水线都面临相同风险。Pillar 将这一模式命名为“TrustIssues”，认为它代表了一种新类别攻击：从提示符注入到供应链投注的横向跳跃，不再依赖零日漏洞，而是利用代理本身的“信任”机制。
对用户/开发者/创作者的影响
对开发者：如果你在 CI/CD 中使用 AI 代理处理公共仓库的 Issue 或 PR，请立即检查工作流是否满足“必杀三要素”。特别是不要以 –yolo 模式运行代理，且务必限制代理可调用的工具范围。Google 的修复方式（2 天内发布补丁）是可参考的最佳实践。
对开源仓库维护者：建议为触发 AI 代理的工作流分配最小权限的 GITHUB_TOKEN，并考虑使用 OIDC 临时凭证替代长期密钥。同时，在 workflow 中添加对 Issue 内容的消毒（sanitization）步骤，或在输入代理前后添加人工确认环节。
对普通用户：如果你只是使用 gemini-cli 作为编码助手，影响有限——攻击链针对的是 GitHub CI/CD 流水线，而非终端用户环境。但需要注意的是，一旦 gemini-cli 项目被供应链投注，该包的下游用户（通过 npm 或 pip 安装的开发者）会直接受到影响。
值得关注的后续
1. 安全工具的响应：GitHub 是否会默认禁用 AI 代理在工作流中访问 .git/config 或其他持久化凭据？目前 GitHub Actions 没有原生提示符注入检测，未来可能引入类似 Secret Scanning 的运行时保护。
2. Google 的全面自查：虽然 Google 已修复 gemini-cli 和 draco 等仓库，但类似漏洞是否存在于其他 AI 代理项目（如 GitHub Copilot Workspace）仍有待验证。Pillar 表示将继续扫描类似模式。
3. 行业规范的形成：Simon Willison 的“必杀三要素”可能被安全社区接纳为评估 AI 代理安全性的基础框架。未来可能会出现针对 AI 代理的 OWASP 式分类指南，帮助开发者在部署前进行威胁建模。
