这是实际生产环境多Agent系统中首次出现的、真实世界的Agent间(agent-to-agent)利用案例。这类新型攻击可让一个AI Agent转而攻击另一个AI Agent,从而破坏软件供应链。
该漏洞存在于google/adk-python仓库中,该仓库是Google的Python版Agent开发工具包Agent Development Kit for Python(谷歌Python版Agent开发工具包)背后的核心代码库。这个SDK被开发者广泛用于构建自己的AI Agent。
adk-python仓库运行着两个层级的自动化AI Agent。低权限Agent负责处理面向公众的交互,每当用户提交Pull Request或Issue时便会触发;高权限Agent则专供受信任的维护者使用,他们对代码库拥有真正的管理权限。
Pillar的研究人员发现,这个暴露在互联网上的低权限Agent可以通过提示注入(prompt injection)被操纵,从而跨越权限边界,替攻击者调用高权限Agent。
Part01
AI Agent攻击自身CI/CD流水线
整个攻击链始于一个名为adk_pr_triaging_agent的Agent,它绑定的是一个类人协作者账户,而非权限受限的机器人身份。
研究人员精心构造了一条伪装成正常贡献说明的Pull Request评论,诱使分流Agent发布一条以“@gemini-cli”开头的评论,由此触发了需要高权限的gemini-invoke和gemini-review工作流。由于该Agent是使用真实协作者账户发表评论的,GitHub便认为这一触发动作来自受信任的人类。
在此基础上,研究人员发现,提取到的GitHub Token虽然权限范围很窄,仅限于Issue和Pull Request的写入权限,但已足够编辑其他用户的评论、冒充维护者,甚至触发伪造的自动化代码审查,并显示出令人信服的“approved(已批准)”标记。
将这些基础能力串联起来,攻击者就能在恶意Pull Request上伪造出一条完整且可信的审批记录,而整个过程没有任何人类真正审查过。
Part02
新增Antigravity自动化引入新漏洞
在最初披露几天后,Google又向同一仓库添加了基于Antigravity SDK的新自动化功能,结果引入了一个全新的漏洞。一个本意是将Agent限制在安全“git”和“gh”操作范围内的命令白名单,却能被git自身的脚本功能绕过,例如钩子(hooks)和shell别名(aliases),这实际上为在CI Runner上实现远程代码执行打开了大门。
由于该Runner持有长期有效的个人访问令牌(personal access token)以及Google Cloud服务账户凭据,攻击者只需打开一个GitHub Issue——无需任何特权访问——就可能从流水线中窃取敏感机密。
Google确认了这些发现并加固了adk-python仓库,不过并未将这一依赖社会工程学的供应链攻击场景纳入漏洞奖励范围,因为从技术上讲,合并恶意代码仍需要维护者执行操作。Pillar Security因此次披露获得了荣誉提名(honorable mention)。
Part03
给安全团队的启示
对安全团队而言,更深层的启示在于:基于Agent的AI工作流引入了一类全新的攻击面,而传统威胁模型从未被设计来应对这类问题。
任何会摄入不受信任文本(如Issue、Pull Request或支持工单)且同时持有凭据的AI Agent,都应被视为可能被攻击者控制的实体。
专家建议,为Agent提供权限范围狭窄、可审计的身份,而不是将其绑定到个人访问令牌;强制执行严格的工具白名单;并保留人工护栏(如分支保护和强制代码审查),以防止单个Agent被攻破后引发连锁反应,最终演变成全面的供应链入侵。
参考来源:
A Malicious GitHub Issue Could Turn Google’s AI Agent Against Its Own CI/CD Pipeline
https://cybersecuritynews.com/ai-agent-against-its-own-ci-cd-pipeline/