核心要点
新漏洞类别：agent-on-agent 指一个 Agent 利用另一个 Agent 的信任、接口或共享资源实施攻击；2026-08-03 Google ADK 案例是首个公开披露（The Register，poolId P012）。
威胁模型扩展：传统模型假设攻击者是人/恶意软件、受害者是系统/人；新范式两端都是 Agent——横向移动目标新增同环境 Agent 的记忆、工具与授权。
第五问：在目标/边界/能力/可观测四问之外，多 Agent 环境必须新增「同环境其它 Agent 是否在我的信任边界内？」，默认答案为否。
防御工具化：NVIDIA SkillSpector 开源 Agent 技能安全扫描器，联动 OSV.dev 漏洞库，在技能安装/执行前做供应链检查（poolId P010）。
暴露面数据：Wiz 传感器显示 71% 组织已部署 AI 编码助手（poolId P011）——开发者工作站成为 Agent 攻击的高价值入口。
简要回答
agent-on-agent 漏洞把攻击链的两端都换成了 Agent：恶意 Agent 不再直接攻击系统，而是欺骗、劫持或榨取同环境的另一个 Agent——借它的工具、读它的记忆、用它的授权。Google ADK 2026-08 的案例证明这不是理论威胁。威胁建模要新增一个维度：把「其它 Agent」当作潜在攻击面而非天然盟友，默认零信任；工程上用技能扫描（SkillSpector）守住供应链入口，用最小权限隔离共享记忆与工具。
标准回答
一、漏洞形态：攻击者与受害者都是 Agent
The Register 报道的 Google ADK 漏洞（poolId P012）是首个公开的 agent-on-agent 案例：恶意 Agent 通过 Agent 间交互接口攻击另一个 Agent。它与两类既有威胁的区别要讲清：
- 与「被劫持」（间接提示注入）的区别：注入的攻击目标是让人类/系统执行恶意操作，agent-on-agent 的目标是另一个 Agent 本身；
- 与「自主越界」（Reward Hacking 驱动）的区别：越界没有外部攻击者，agent-on-agent 有明确的恶意主体，只是主体也是 Agent。
二、为什么多 Agent 环境放大风险
三个结构性原因：其一，Agent 间默认互信——协议层（MCP/A2A）假设消息来自合法 Agent；其二，共享记忆与工具池创造了横向移动通道——攻破一个 Agent 等于拿到它的记忆写入权与工具调用权；其三，Agent 的行为可被自然语言影响——攻击面从二进制漏洞扩大到语义层。
三、威胁建模更新：四问变五问
在 agent-security-002 的「目标/边界/能力/可观测」四问之外，新增第五问：**同环境的其它 Agent 是否在我的信任边界内？**默认答案为否。落地含义：Agent 间消息按不可信输入处理；共享记忆按租户/角色分区；工具可见性最小化——Agent A 不应看到 Agent B 的高危工具。
四、防御纵深
- 供应链入口：技能/插件安装前静态扫描——NVIDIA SkillSpector 联动 OSV.dev（poolId P010）；
- 运行时隔离：Agent 间共享资源按最小权限，记忆写入带签名与审计；
- 暴露面收敛：Wiz 数据显示 71% 组织已部署 AI 编码助手（poolId P011），开发者工作站的凭据是 Agent 攻击的首选战利品，传感器与资产清点先行。
五、评估含义
多 Agent 系统的安全评估不能只评单个 Agent——需要组合测试：恶意 Agent 样本注入、Agent 间接口模糊测试、共享记忆投毒演练。
常见误区
误区一：「这是 ADK 的实现 bug，换个框架就没了。」 错。漏洞根源是多 Agent 系统的信任假设——任何允许 Agent 间自由通信与共享资源的框架都有同类攻击面，ADK 只是第一个被公开的。
误区二：「提示注入防御能覆盖 agent-on-agent。」 部分覆盖但不完整。提示注入防御针对「数据被当指令」，agent-on-agent 还包括协议层滥用（伪造 Agent 身份）、记忆投毒（持久化影响）与工具借道（用受害 Agent 的授权做事）——需要在协议与资源层设防。
误区三：「我的 Agent 不联网就安全。」 agent-on-agent 的攻击路径是 Agent 间接口，不需要外网——同环境内的任何不可信 Agent 都是入口。
追问
追问 1：共享记忆如何防止被投毒？
三层防御与提示注入同构：写入层——记忆条目带来源 Agent 签名与置信度标签，跨 Agent 写入需显式授权；读取层——Agent 消费他人写入的记忆时按不可信数据处理，隔离指令与内容；审计层——记忆变更全量留痕，异常写入模式（高频、跨主题、敏感字段）触发告警。核心是重建「谁写的」与「内容是什么」的边界。工程落地顺序建议：先做签名与留痕（成本低、不影响功能），再做读取层隔离（需要改造消费逻辑），最后上实时异常检测。
追问 2：如何在评估中构造恶意 Agent 样本？
红队构造方法分四步：定义攻击目标（窃取记忆、借道工具、拒绝服务三类最典型）；构造带明确恶意目标的 Agent 样本接入受控环境；观察它能否通过合法 Agent 间接口达成目标（而非靠系统漏洞）；复盘横向移动路径并固化为回归用例。关键是评估环境的权限拓扑必须与生产一致——共享记忆、工具可见性、Agent 间授权关系照搬，否则测不出真实的横向移动路径。样本库建议按攻击目标分类维护，每次框架升级后重跑。
🔗 相似问题
同一考点的不同问法，换着练更稳
延伸学习
按主题分类的相关资源，便于系统复习