用遥测数据识别智能体越权与目标劫持

Agent 读到一封邮件、一个网页或一段工具返回值，就可能把别人的指令当成自己的任务。Google 这次拿五套非自研公开基准，测试 Agent Anomaly Detection 能否发现任务被劫持：对 Agent 已经执行的有害指令，总体检出率是 87%。

但它是事后告警，不负责拦截动作；87% 也不是所有攻击的检出率。对准备把 Agent 接入业务系统的开发者，这篇最值得读的地方，是检测率如何计算，以及正常工具使用、历史数据和长期记忆会怎样改变结果。

87% 的检出率，分母到底是什么

OWASP 将 Agent 目标劫持列在《Top 10 for Agentic Applications (2026)》首位。典型攻击并不直接出现在用户提问里，而是藏在邮件、文件等工具返回内容中，诱导 Agent 偏离用户任务。

Google 在 9 月宣布，Agent Anomaly Detection 在 Gemini Enterprise Agent Platform 进入 Private Preview。它异步读取执行轨迹（traces）和日志，发现超出预期边界的会话，不给 Agent 执行路径增加延迟。

这次测试使用 ADK（Agent Development Kit）构建 Agent，模型统一为 gemini-2.5-flash，在基准的模拟应用中运行，共评估 1,774 个会话。五套基准分别是 AgentDojo（NeurIPS 2024）、InjecAgent（ACL 2024 Findings）、Agent Security Bench（ASB，ICLR 2025）、AgentDyn（2026）和 AgentHarm（ICLR 2025）。前四套把攻击藏在工具返回的数据里，AgentHarm 则由用户直接提出有害请求。

评测先区分攻击有没有真正发生：

• 没读到：工具没有返回那段恶意指令，Agent 没有接触攻击。
• 抵抗了：Agent 读到了，但没有执行成功；尝试过却失败，也归在这里。
• 执行了：Agent 读到并完成了有害指令，由基准检查最终应用状态来确认。

87% 指的是第三类会话中，被检测器标记出来的比例。

把没读到和抵抗成功的会话也放进分母，各基准的标记比例只有 45% 至 62%。141 个没有读到攻击的会话中，检测器只标记了 1 个，此时也没有发生攻击后果。

模型本身没有执行约一半已读到的有害指令：直接有害请求约有四分之三被拒绝，工具输出中的恶意指令约有 30% 被忽略或执行失败。模型的抵抗与检测器的告警，回答的是两件事，不能混算。

第三方基准增强了可信度，但没有覆盖所有风险

每次运行后，基准自带的 Python 检查程序读取应用最终状态，例如钱是否已经转出，再给会话打标签。裁判是确定性代码，因此不会被注入内容说服，检测器也无法靠影响裁判模型获得好成绩。

这比只用自建案例更有说服力。不过，第三方基准不等于第三方独立评测，实验仍由 Google 执行。

在已执行的有害指令中，AgentDojo、InjecAgent、AgentDyn 和 AgentHarm 的检出率分别为 85%、87%、99% 和 81%。11 个应用里，有 8 个达到至少 95%；最低的是 AgentDojo 的 Slack 应用，只有 63%。作者解释，一些攻击只要求访问一次网页，动作太小，看起来很像正常浏览。

拒绝请求也可能产生告警。AgentHarm 的 412 个请求中，Agent 执行了 108 个；对被拒绝的会话，检测器仍标记了 55%，因为恶意请求直接留在用户消息里。相比之下，藏在工具输出中、被 Agent 抵抗的指令，只有 11% 至 25% 被标记。

因此，告警不能直接等同于失守。判断事件时，还要核对动作是否实际执行。

检测结果的五种威胁类别中，有四种对应 OWASP 分类，但公开基准主要集中在目标劫持和工具滥用。作者没有找到带标签执行轨迹、可用于评估级联故障或身份与权限滥用的公开基准，这些能力尚缺本次研究的证据。

上线后最容易踩到的，是历史不足和正常行为太危险

异常检测需要知道 Agent 平常怎么工作。原文称，每个 Agent 先运行至少 300 个正常会话，用来学习行为基线；后面又单独展示了 AgentDyn 的历史量对照：约 220 个正常会话时，已执行攻击的检出率为 33%，到 360 个时升至 99%。

这组结果说明历史量会影响检测能力，但原文没有完整交代它与前述预热流程的关系，也不能据此把 360 个会话当成通用达标线。

误报同样依赖日常工作。三个以办公任务为正常样本的注入基准，误报率为 2% 至 4%；AgentHarm 则达到 16%。后者的正常任务与有害任务互为对应版本，也会发社交媒体内容、执行终端命令和下载文件。正常使用的工具越有影响力，就越难只凭行为区分是否滥用。

对日常运行终端、下载依赖的 AI 编程 Agent，这个差异尤其有参考价值。不过，原文没有直接测试真实开发仓库，不能照搬其误报率。

更明显的缺口是记忆投毒：攻击者把指令写进 Agent 的长期记忆，让它以后继续受影响。ASB 中有 18 个会话因此执行了有害动作，检测器只抓到 4 个。

作者列出五项改进方向：以较低严重程度报告被抵抗的攻击尝试、识别访问不可信目的地的小动作、区分高影响工具的正常使用与滥用、缩短新 Agent 的覆盖等待期，以及增强记忆投毒检测。这些是待改进方向，不能当成已有能力。

我的判断

这组结果支持把 Agent Anomaly Detection 当成分层防御中的事后检测层。它能发现一部分已经绕过模型的攻击，也明确暴露了记忆投毒和轻微动作的短板。

异步检测减少了执行路径上的等待，却无法阻止已经发生的转账或数据外发。

原文建议搭配 Model Armor 检查提示词和工具结果，并用处于 Preview 的 Semantic Governance Policy 在执行前核对工具调用是否符合用户请求和规则，不符合就拒绝。这是合理的职责分工，但研究没有给出这些组件联用后的对照数据，不能把它推导成完整方案的防护成绩。

实验也只用了一个模型和模拟应用，正常任务可能比生产流量简单。约 6% 的提交会话没有返回检测结果；把这些计为漏报，总体比例还会下降 1 至 2 个百分点。评估时应把这部分算进去。

至于是否优于输入过滤、权限限制或其他检测方案，原文没有提供同条件对照，无法下结论。

能拿来做什么

• 给 Agent 做安全评测时，分别统计攻击是否被读到、是否执行成功、执行后是否告警，再单列误报与无结果会话，避免一个检出率掩盖不同问题。
• 使用 ADK 时，按原文建议启用 tracing 和 logging，包含 prompt 与 response 内容，并积累贴近实际工具使用的正常会话，检查新 Agent 的检测表现。
• 对支付、外发邮件和数据共享等动作，在执行前设置规则与人工审批，并把工具和权限限制到任务所需范围；事后告警用于补充调查。
• 如果申请 Private Preview，重点验证日常终端操作、小动作和长期记忆投毒。检测结果也会进入 Security Command Center，可把 Critical、High 级别发现接入事件处理流程。