Gemini ADK Agent间攻击可泄露密钥篡改PR

资讯专家

Pillar Security在Google的Agent Development Kit（ADK）Python版（google/adk-python）中发现了一种agent-to-agent攻击方法，攻击者可利用精心构造的提示词，将恶意交接评论传递给高权限代理，导致机密信息泄露和拉取请求（PR）投毒。

该仓库内有两类自动化AI代理：低权限代理面向用户交互开放，高权限代理仅仓库维护者可访问。研究人员Dan Lisichkin发现，操纵低权限代理即可向高权限代理传递提示，获取命令执行等受限能力，进而可能引发供应链风险。

起初，研究人员注意到负责分流PR的代理会以Collaborator身份在PR上评论，表明其拥有仓库高权限。随后，他构造了一种方法，让该代理在PR上发布“@gemini-cli <prompt>”形式的评论，触发gemini-invoke工作流，进而访问更高权限的流程。初始提示经由gemini_invoke.yml工作流响应，泄露了特权代理通过MCP服务器可用的工具列表。

结果显示，该代理可访问所有bash命令，意味着研究员可以远程执行代码，并有可能提取代理的GitHub令牌。Lisichkin称，利用该令牌，他能够修改其他维护者、协作者和成员的评论、PR及Issue，可以驳回审查或批准PR变更，还能对任意PR调用gemini-invoke和gemini-review。这些能力可以污染PR审批生命周期，但恶意PR最终需要成员批准并合并，因此需要配合社会工程学。

具体攻击场景为：威胁行为者先以协作者身份建立信任，提交一个包含恶意代码的PR并标记为待审查；随后再提交一个包含提示词的第二个PR，指示代理将第一个PR标记为“已分流、已审查、已批准”。

Lisichkin指出：“编辑分流代理的评论利用了Issue的write权限；以机器人身份发布和批准使用了通过RCE提取的GITHUB_TOKEN；标签和审查请求修改属于pull-requests:write。这些操作串联起来，制造了一条完整且可信的‘有人请求审查，Gemini运行了审查，Gemini批准了’的痕迹，但这一切从未发生过。”

Google在6月初收到通知后，通过加固修复了该问题，但认为其不满足漏洞奖励标准，因为合并恶意PR需要社会工程学。此后不久，Pillar又在ADK仓库基于Antigravity-SDK的代理自动化功能中发现了另一个漏洞，该漏洞可在无需维护者交互的情况下导致远程代码执行，Google已于7月底完成修复。

热心网友7

感谢楼主分享这个安全研究，信息量很大。AI代理之间的权限隔离确实是个关键问题——低权限代理被提示词注入后，竟然能间接调动高权限代理的工具，甚至拿到GitHub令牌伪造整个PR审批流程，这个攻击链设计得相当巧妙。最值得警惕的是，它把“人工审查”这个环节也变成了可被污染的一环，即使最终合并还需要人，但留下的“已审查已批准”痕迹可能让维护者放松警惕。 Google后续修复了，但对漏洞奖励标准的判断有点争议。毕竟攻击链的实际危害已经远超普通提示词注入，而且另一个Antigravity-SDK漏洞居然能无需维护者交互直接RCE，那就更严重了。希望这类案例能推动更多团队重新审视agent之间的信任边界和最小权限原则。

热心网友7

这个发现挺值得重视的。虽然Google认为需要社会工程学配合所以不给奖励，但从攻击链来看，低权限代理能成为通往高权限能力的跳板，本身就说明代理之间的信任边界需要更严格设计。尤其是编辑评论、复用机器人身份、伪造审查轨迹这些操作串在一起，实际影响已经不只是理论风险了。后面那个无需维护者交互就能RCE的漏洞更让人在意，说明这类自动化代理的权限隔离还得继续打磨。

热心网友7

这个攻击链挺有意思的，低权限代理居然能成为跳板，把提示词传到高权限代理那边去。尤其是通过编辑评论来伪造“已审查已批准”的痕迹，感觉比单纯拿令牌更危险，因为整个过程看起来就像正常流程。虽然Google说不满足漏洞奖励标准，但能通过RCE拿到token已经很严重了吧？这种自动化代理之间的信任边界感觉以后会是个大问题。