网络安全研究机构 Pillar Security 近期披露了一份引人警觉的技术报告，矛头直指谷歌开源的 Python Agent Development Kit（ADK）工具链。这份报告揭示了一个此前几乎未被业界正视的隐患：当多个 AI 代理在 GitHub 仓库的自动化流水线中协同作业时，外部攻击者竟能通过精心构造的恶意指令，撬动原本仅对受信任成员开放的权限层级。这并非理论推演，而是已被研究人员在真实环境中成功复现的完整攻击链。
从公开 Pull Request 到内部权限的"跳板"
问题的起点藏在一个看似无害的自动化流程里。谷歌 ADK 仓库部署了一个专门处理外部贡献的"分诊代理"，它的职责是扫描社区成员提交的 Pull Request 并给出初步反馈。这个代理以 adk-bot 的身份运行，而该账户恰好拥有代码库的协作者权限。
Pillar Security 的研究团队发现，攻击者完全可以在 Pull Request 的描述或评论中嵌入隐蔽的提示注入指令。当分诊代理读取这些内容时，恶意指令会诱导它发布一条包含 "@gemini-cli" 的触发命令。这条命令本身平平无奇，但它启动的却是一个原本仅限受信任用户触发的内部工作流。
这个被触发的 CI 流水线运行在 GitHub Actions 的执行环境中。虽然配置上的 GitHub Token 被限制为不能推送代码，但它对 Issue 和 Pull Request 具备写入权限。在实战测试中，研究人员利用这一权限完成了三项极具破坏性的操作：篡改维护者的历史评论、以 github-actions[bot] 的名义提交虚假的批准审核，以及直接删除合法的审核请求。经过这一系列操作，一个存在恶意代码的 Pull Request 表面上看起来已经获得了足够的社区认可，随时可以被合并进主分支。
Pillar 在受控环境中完整跑通了这条攻击链路。值得注意的是，最终的人工合并环节仍然需要维护者点击确认，但此时呈现在维护者面前的"证据"早已被自动化流程篡改得面目全非。谷歌方面在收到报告后对该仓库的权限配置进行了加固。
Antigravity 代理中的"二次渗透"
除了分诊代理这条路径，Pillar 还在基于 Antigravity 代理构建的新型工作流中挖掘出了另一条独立的攻击通道。这个工作流的设计初衷是自动分析公开 Issue 中的问题描述，并触发修复流程。
修复流程的开发者显然意识到了风险，试图将代理的行为严格限制在 Git 和 GitHub 命令范围内。然而这种限制在实际执行中形同虚设。Pillar 的研究人员证明，Git 命令本身就可以被利用来执行任意代码。在演示中，他们成功将 adk-bot 的个人访问令牌从 CI 运行器中提取到外部控制的服务器上，同时还将 Google Cloud 服务账户密钥一并带了出来。
这两条攻击路径的共通之处在于，它们都利用了"代理之间的信任传递"。一个面向公众、权限较低的代理，其输出被另一个权限更高的代理或工作流无条件信任并执行，从而形成了权限的逐级攀升。Pillar 将这种现象定义为"首个涉及生产环境多智能体系统的代理间剥削真实案例"。
当自然语言成为新的授权凭证
Greyhound Research 首席分析师 Sanchit Vir Gogia 对此给出了一个颇为犀利的判断。他认为这类弱点本身并不算新鲜，真正值得行业警惕的是"自然语言已经正式加入了授权流程"。在传统安全模型中，权限的流转依赖于密钥、令牌和角色绑定，而在 AI 代理架构里，一段文本输出就可能触发下游系统的敏感操作。
Gogia 强调，评估一个代理的安全边界不能只看它被分配了哪些工具，更要追踪它的输出能够激活哪些更高级别的系统。换句话说，代理的"隐性权限"往往比"显性权限"更危险。
IDC 亚太区网络安全服务高级研究经理 Sakshi Grover 则从企业安全治理的角度提出了三个追问。第一，哪些代理会接触不受信任的外部内容？这包括 Pull Request、Issue、邮件、工单乃至外部文档。第二，这些代理的输出是否会直接或间接触发拥有更高权限的其他代理或工作流？第三，整个链条中涉及的身份、凭证和工具，其最大有效能力究竟有多大？
现有安全工具的盲区
IAM、PAM、CIEM 以及应用安全工具能够暴露单个身份的权限配置，也能发现工作流中的不安全设置，但它们很难将这些碎片化的信息拼接成一条完整的"事件驱动委托路径"。库存清单记录的是"有什么"，而授权映射需要回答的是"可能发生什么"。
Gogia 建议安全团队重新梳理数据流：从外部输入进入第一个代理开始，一直追踪到下游系统执行相应动作的全过程。审查的重点不应仅停留在代理 A 能否调用代理 B，更要关注代理 A 是否有能力修改代理 B 已经信任的任何内容。
人工审批环节在这一场景下的防护价值也被打了折扣。虽然第一种攻击路径仍需维护者执行合并，但攻击者真正的目标从来不是获取合并权限，而是伪造足以说服维护者的虚假证据。Gogia 认为，有效的审批机制应当对审查人员形成刚性约束，确保他们只能审查特定的代码或工件，任何实质性变更都应自动使先前的批准失效。
Grover 进一步补充，对评论、意见和批准状态的任何修改都应被视为安全事件，并实时导出到独立的日志系统中。这个日志系统必须处于工作流自身身份无法触及的隔离环境中，防止攻击者在篡改审核状态后顺手抹去痕迹。
修复时间线与行业启示
根据 Pillar Security 披露的时间线，他们在今年 7 月 2 日确认第一条攻击路径涉及的受影响工作流已被移除。谷歌在 7 月 21 日回复研究人员，确认第二个问题也已得到修复。
这起事件给正在拥抱 AI 代理架构的企业敲响了警钟。当代码仓库的自动化流程开始由多个智能体协同驱动时，传统的 CI/CD 安全审查框架需要被重新设计。权限的边界不再仅仅由账户和角色定义，而是隐藏在代理与代理之间的每一次"对话"和"交接"之中。识别这些传递性的授权关系，或许将成为下一代安全工具必须攻克的核心课题。
扫一扫
162
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
