样本与方法

报告基于 Arrakis 客户生产环境里数千个 AI agent 的匿名遥测，覆盖 12 周。它看的不是模型输出质量，而是 agent 的身份、权限、触发器、连接和数据流——也就是一个 agent 在系统里「能做什么」。

关键数字

  • 76% 的启用 agent 至少 60 天没运行过，44% 超过 180 天；
  • 24% 的休眠 agent 可以被外部未签名 webhook 启动；
  • 22.9% 的 agent 至少有一个未加固的触发器；
  • 70% 能访问云存储、AI 服务或营销平台等敏感系统；这些连接里 99.4% 没有经过验证的 DLP 覆盖；
  • 19% 使用永不过期的 API key 或 token，且直接写在配置里；
  • 82% 至少有一项暴露，46% 有两项以上；
  • 20% 可以把任务转给权限不同的另一个 agent，拿回自己无权产生的结果；
  • 22% 可以把内容发给第三方模型，再根据回答执行动作。

为什么休眠 Agent 没被清理

Arrakis CEO Tal Baron 的说法很直接：员工离职当天权限会被收回，但 agent 停用后没人移除任何东西，因为大多数公司里没有人为它负责。Agent 往往由某个项目临时创建，项目结束后创建者调岗或离职，agent 就成了没有主人的自动化账号。

休眠不等于无害。它的凭证还在，触发器还在，连接还在；一个未签名的 webhook 就能把它叫醒，而它醒来后拥有的权限和休眠前一样。

风险不是「模型变坏」

这份报告里最值得注意的风险，大多和模型能力无关：永不过期的密钥、未签名的触发器、过宽的权限、缺失的 DLP、跨 agent 的权限传递。攻击者不需要说服模型叛变，只要找到那个还能用的 webhook，或者拿到配置里那把不会过期的 key。

跨 agent 传递尤其隐蔽：一个低权限 agent 可以把任务交给高权限 agent，再拿回结果。单看每个 agent 的权限都合理，连起来就形成了绕过。

一份可执行的清理清单

  1. 列出所有 agent：创建者、owner、最后运行时间、凭证、触发器、连接的系统；
  2. 给每个 agent 指定一个活人 owner，项目结束就进入回收流程；
  3. 停用 60 天未运行的 agent，先禁用触发器，再吊销凭证；
  4. 把长期密钥换成短期凭证，配置里不存明文；
  5. 给所有 webhook 加签名和重放保护；
  6. 对访问云存储、模型服务和营销平台的连接补 DLP 与最小权限；
  7. 记录跨 agent 调用，限制权限提升路径；
  8. 每季度复演一次「agent 离职」流程。

如果你只能做一件事，先做资产清单。没有清单，后面的吊销、签名和 DLP 都无从下手。