
最近看到 Pillar Security 披露的 Google ADK(Agent Development Kit,智能体开发工具包)安全漏洞,忍不住想聊聊这事儿。AI 工作流自动化听着很爽,但权限管理一旦没到位,分分钟被人拿来做坏事。这篇把漏洞的来龙去脉和技术细节捋清楚,看完你就知道现在 Agent 系统里那些"自动化"到底埋了多少雷。
核心风险在于一个 triage agent(分流智能体),它的设计目标是评估外部贡献者的 pull request(拉取请求)。这个 agent 跑在一个特定账号下,拥有仓库的 collaborator(协作者)权限。研究人员发现,攻击者只要在 pull request 里嵌入特定的指令,就能让这个 agent 误判——它会发出命令,触发那些本来只开放给内部可信用户的 CI/CD(持续集成/持续部署)工作流。
工作流激活后,攻击者拿到了 CI 环境里的命令执行权限。虽然关联的 token(令牌)不能直接推送代码,但它可以修改 issue(工单)和 pull request。攻击者能篡改维护者的评论,或者伪造假的审批记录。这样一来,一个恶意的 pull request 就能伪装成"已通过验证、可以合并"的状态。
Pillar Security 在受控研究环境下成功复现了这条攻击链。虽然最终合并还是要人类维护者点按钮,但经过 agent 自动处理后,恶意代码看起来就跟安全的一样。Google 接到报告后加强了仓库的安全配置,封堵了这类未经授权的命令触发。
第二种攻击方式瞄上了使用新型 agent 的工作流。攻击者可以在公开的 issue 里注入 prompt(提示词),诱导一个分析 agent 启动本来只限授权人员使用的修复工作流。虽然系统试图限制 agent 只能执行标准的版本控制命令,但研究人员证明了这些命令仍然可以触发未经授权的代码执行。
在演示第二个漏洞时,研究人员还提取了一个个人访问令牌并外传到了外部服务器,甚至发现 Google Cloud 服务账号密钥在 workflow 过程中是可访问的。Google 确认在七月初移除了有问题的 workflow,并在当月晚些时候完成了第二个漏洞的修复。这些事件再次提醒我们:自动化系统往往缺乏上下文判断能力,分不清正常请求和恶意注入。
这组发现让安全从业者不得不重新审视多智能体环境。核心问题不只是漏洞本身,而是权限如何通过自然语言在系统间传递。当一个 agent 处理某条消息时,这条消息就成为了授权链上的一环。这种机制要求我们对复杂自动化系统中的权限管理采取全新的思路。
安全分析师指出,一个 agent 的实际权限往往比它表面的工具集更强。因为它的真实影响力包括任何它能触达的高层系统。如果一个低级别 agent 能跟高级别 agent 对话,它们之间的安全边界往往比预期薄得多。组织必须重新考虑如何给那些处理外部不可信数据的 agent 授予权限。
评估这些风险需要仔细分析 agent 如何消费内容。安全负责人需要识别哪些 agent 接收外部输入——比如邮件、工单系统里的支持工单或 pull request。然后追踪这些 agent 的输出能否触发更高权限的工作流。搞清楚链路中每个身份和工具的最大能力边界,是防止未授权访问的关键。
这类系统的复杂性意味着,传统安全工具往往只能看到局部。常规的身份管理或应用安全软件可能识别出各个组件,但看不到完整的委托路径。一个事件就能触发跨多个 agent 的系列操作,形成一条隐藏的权限路径。只有映射这些连接关系,才能看清在真实攻击场景中到底会发生什么。
追踪外部数据的流向是现代安全团队的必修课。必须从数据进入系统的那一刻开始追踪,直到下游动作发生。这包括审视共享状态,比如平台上的评论,它们可能成为另一个流程的触发器。对防御者来说,最根本的问题是:一个低权限 agent 能否修改高权限 agent 所信任的内容。
人类审核通常被认为是防止自动化出错的最后防线,但它并非万无一失。就 Google 仓库这个案例而言,虽然最终还是要人点合并按钮,但被操纵的 AI agent 给人类提供了虚假的证据。当系统展示"代码已经过其他 bot 审批验证"时,人很难不信任这个结果。
如果攻击者能骗人类替他们点按钮,他们根本不需要合并权限。这就是为什么专家建议审批必须绑定到某个不可变的代码版本。一旦检查后代码发生任何变更,之前的审批立即失效。这样才能确保人类看到的产物和实际部署到生产环境的完全一致。
除了收紧审批流程,组织还应该把对评论和审核意见的修改当作重大安全事件来处理。这些操作应该记录在独立的日志系统中,而且自动化 workflow 使用的身份必须无权修改这些日志。这才能形成一份永久、防篡改的决策记录,清楚显示谁或什么影响了最终判断。
用自然语言作为自动化的工具带来了效率,也带来了新型风险。Google ADK 的这些漏洞表明,信任本身就是 AI 开发中的一个大漏洞。开发者必须建立机制,在任何消息被允许影响高层流程之前,验证其来源和意图。没有这些防护措施,AI 自动化的速度只会让攻击来得更快、更有效。
随着越来越多的企业采用基于智能体的架构,这次发现的经验教训会变得越来越重要。安全不再只是保护密码和 API 密钥(应用程序接口密钥)的问题,而是要保护系统中各组件之间对话的完整性。监控信息流向、在不同 agent 之间维持严格的边界,是抵御这类新兴威胁的主要手段。