大模型时代，我们习惯用越狱、提示注入、数据泄露等类别描述安全风险。但到了 Agent 时代，这种分类方式开始显得不够用了。

一次攻击可能从网页中的一段外部信息进入 Agent，首先干扰推理，随后污染长期记忆；几天后，这段记忆又被重新读取，改变 Agent 的计划，并最终触发一个未经授权的工具调用。

你可以把它叫作提示注入，也可以叫记忆投毒或工具攻击，但任何一个标签都只能描述其中的一部分。

更关键的是，我们已经知道很多 Agent 安全风险，并不意味着这些风险都真正被实验验证过。

2026 年 9 月，来自成均馆大学和澳大利亚联邦科学与工业研究组织（CSIRO）的研究人员系统梳理了 2022—2026 年间的 66 篇 Agent 安全研究，提出了一套四维威胁分类框架；又进一步分析了 22 篇具有公开实验材料的红队研究和 11 个代表性安全 Benchmark，试图回答三个问题：Agent 到底有哪些风险？哪些风险已经被真正测过？现有安全评测究竟成熟到了什么程度？

https://arxiv.org/pdf/2609.23894

最终，他们得到了一张包含 4 个维度、32 类威胁和 13 个待解问题的 Agent 安全地图。

从“大模型安全”走向“系统安全”

传统大模型主要完成一件事情：

输入 → 模型 → 输出

即使模型受到干扰，大多数情况下，问题最终停留在输出层。

Agent 则不同。一个典型 Agent 会维护目标和状态，进行推理和规划，读取长期记忆，调用外部工具，并根据工具返回结果继续下一轮决策。

于是安全问题变成了一条不断循环的链：

目标 → 推理 → 记忆 → 规划 → 工具 → 环境 → 新状态 → 再次推理

一次异常输入可能改变推理结果，推理结果可能被写入长期记忆，受污染的记忆可能影响后续规划，错误规划又可能调用具有真实权限的工具，最终修改外部系统状态。新的系统状态还会重新成为 Agent 的观察结果，进入下一轮决策。

这意味着，Agent 安全已经很难被简单理解为“大模型是否会被绕过”。

真正的问题开始变成：

攻击从哪里进入系统，影响了什么组件，跨越了什么信任边界，最终造成了什么后果？

这也是论文提出四维威胁框架的出发点。

四维威胁地图

论文用一个非常简洁的表达描述 Agent 威胁：

T = ⟨S, B, P, A⟩

分别代表：

• S：Surface，攻击面——攻击影响了什么？
• B：Boundary，边界——攻击从哪里进入或传播？
• P：Property，安全属性——最终破坏了什么？
• A：Architecture，架构——这种风险在哪类 Agent 系统中被实验验证过？

它的关键不在于又创造了一套新的攻击名称，而是把过去分散的风险重新连接起来。

例如，一段来自外部工具的异常信息影响了 Agent 的推理，又被写入长期记忆，并最终诱导 Agent 执行了超出授权范围的操作。

在四维框架中，它可以同时被描述为：攻击影响了推理、记忆和工具，跨越了 Agent—Tool 信任边界，破坏了状态完整性和授权完整性，并且还需要说明这种攻击究竟是在单 Agent、流水线 Agent 还是多 Agent 系统中得到验证。

因此，四个维度不是四个攻击阶段，而是四组可以交叉组合的标签。论文也特别强调，这套表示并不直接描述攻击发生的时间顺序和因果关系。

第一维：Surface——被攻击的不再只有模型

论文将 Agent 的核心攻击面扩展为多个层次。

最靠近 Agent 内部的是目标与状态。攻击者甚至不需要破坏模型本身，只需要改变 Agent 正在追求的目标，一个完全“正常”的推理过程就可能得到错误结果。

其次是我们最熟悉的推理与规划，包括直接或间接提示注入、安全策略绕过、推理路径干扰以及让 Agent 陷入反复推理和重规划的资源消耗攻击。

再往外是记忆与知识。Agent 一旦拥有长期记忆，攻击便可能跨越一次对话持续存在。一次污染可以在后续任务中反复被检索、强化，甚至通过共享记忆传播到从未直接接触攻击者的其他 Agent。

然后是动作与工具。这里的风险已经从“模型说错话”升级为“系统真的执行了错误动作”，包括工具描述污染、工具返回结果操纵、跨工具组合、权限滥用等。

此外，论文还进一步纳入了基础设施、供应链以及治理与监督等系统层面的攻击面。Agent 安全由此逐渐从 Model Security 演变成真正的 System Security。

第二维：Boundary——很多攻击本质上是信任边界被打穿

如果说 Surface 回答“哪里坏了”，Boundary 回答的就是“问题从哪里进来的”。

论文重点关注：

Human–Agent、Agent–Agent、Agent–Tool / Service、Agent–Environment，以及进一步扩展出的基础设施、供应链和治理接口。

这实际上提供了一种比“攻击名称”更稳定的理解方式。

以间接提示注入为例，网页原本只是供 Agent 阅读的数据，但 Agent 却把网页中的某段内容当成了具有更高优先级的指令。

表面上看，这是 Prompt Injection。

从系统安全角度看，它实际上发生了一次更根本的问题：

低信任域的数据跨越边界，被赋予了高信任域指令的权限。

类似的问题同样存在于 Agent 间通信、MCP 工具返回、共享记忆和外部环境观察中。因此，在 Agent 时代，身份、来源、授权以及信息的 provenance——也就是“这条信息究竟从哪里来的”——会越来越重要。

第三维：Property——CIA 已经不够描述 Agent 安全

传统网络安全经常使用机密性、完整性和可用性，也就是 CIA 三元组。

论文在此基础上进一步拆出了 Agent 特有的安全属性，包括：

目标完整性、状态与知识完整性、动作与授权完整性、交互与信任完整性、监督与可追责性，再加上传统的机密性、可用性以及面向具身系统的物理安全，共八类属性。

其中尤其值得注意的是动作与授权完整性。

Agent 的一个特殊风险是：

每一步动作单独看都可能完全合法，但组合起来却可能形成一个从未被授权的执行轨迹。

例如 A 操作合法、B 操作合法、C 操作同样合法，但：

A → B → C

组合起来，却实现了用户从未允许 Agent 完成的目标。

因此 Agent 安全不能只做：

检查这次工具调用是否合法

还需要逐渐走向：

检查整条执行轨迹是否仍然符合最初的授权和目标。

第四维：Architecture——Agent 架构本身决定风险如何传播

论文没有简单地把系统分成单 Agent 和多 Agent，而是进一步区分了几种典型多 Agent 架构：

层级式架构由一个协调者管理多个下游 Agent，一旦上层协调者受到影响，错误权限可能沿委托链向下扩散；

流水线式架构按照 A → B → C 顺序执行，风险更容易沿处理链逐步传播；

水平协作式架构依赖多个 Agent 讨论、投票或交叉验证，因此身份、共识、串谋和拜占庭行为开始成为核心问题；

动态图架构甚至允许 Agent 的成员、角色和通信关系在运行时发生变化，此时“谁是谁、谁授权了谁、信息经过了哪些 Agent”都会成为安全问题。

需要注意的是，这个 Architecture 维度描述的是已有实验在哪些架构上验证过风险，而不是声称某种攻击只能发生在某类架构中。

32类Agent安全风险

在四维框架之上，论文最终归纳出了 32 类 Agent 安全威胁，并为了便于阅读，将它们整理为三组。需要注意，这三组只是组织方式，并不是四维框架之外的新分类轴。

第一组是 15 类功能性威胁，主要针对 Agent 自身的工作机制，包括目标操纵、奖励或规格操纵、策略性失配、指令劫持、安全策略绕过、推理与规划干扰、推理资源消耗、策略泄露、记忆与知识污染、持久状态操纵、上下文数据泄露、工具清单污染、工具执行利用、跨工具利用以及权限升级。

这部分与今天我们熟悉的 Agent 攻击研究最接近，但已经明显从 Prompt 扩展到了 Goal、Memory、Tool 和 Execution。

第二组是 11 类交互与信任边界威胁。

包括人与 Agent 之间的信任操纵、人工审批绕过、Agent 身份和通信攻击、跨 Agent 风险传播、共识和拜占庭操纵、Agent 串谋、工具或服务冒充、工具元数据和返回结果操纵、凭证与授权滥用、环境操纵以及网络—物理系统攻击。

这一组风险最能体现 Agent 与传统大模型的差别：安全问题不再只存在于模型内部，而越来越多地产生于不同主体之间的连接处。

第三组则是 6 类系统性和运营风险，包括资源与可用性攻击、隔离与凭证失陷、组件和依赖项失陷、安装与更新操纵、监督能力退化以及治理规避。

至此，一张完整的 Agent 安全图谱开始从“模型有没有被绕过”，扩张到：

目标 → 推理 → 记忆 → 工具 → Agent 协作 → 身份与授权 → 基础设施 → 软件供应链 → 人类监督与治理。

这也是论文真正有价值的地方：它并没有试图再创造第 33 种攻击，而是告诉我们，应该把不同攻击放在怎样的一张系统地图上理解。

地图已经很大，但真正被实验验证过的区域仍然有限

如果论文只做到32类威胁分类，它仍然只是一篇比较完整的综述。

真正让这篇论文更有价值的是，作者进一步把：

“我们认为存在的风险”

和：

“我们真正通过实验验证过的风险”

区分开来。

在构建威胁地图时，作者分析了 66 篇研究；随后又设置了更严格的实证研究标准：研究不仅需要真正针对 Agent 实现具体攻击，还要能够描述攻击者、目标系统、实验过程和结果，并至少公开代码、攻击 Prompt、数据集或评测脚本中的一种。

最终，只有 22 篇具有公开实验材料的红队研究进入了后续分析，同时作者还检查了 11 个代表性 Agent 安全 Benchmark。

得到的结果非常明显。

22 篇研究中：

16 篇研究的是单 Agent，只有 6 篇涉及多 Agent；真正报告具体防御实验的只有 7 篇。

11 个 Benchmark 中：

10 个主要针对单 Agent 系统。

已有研究主要集中在：

提示与推理、记忆污染和工具相关攻击。

而对于：

跨会话持续攻击、Human–Agent 安全、复杂多 Agent 协作、系统性风险以及长程执行风险

的实证覆盖明显更少。作者也反复强调，这只能说明他们选择的这批公开研究存在这种分布，并不能据此断言整个研究领域都没有相关工作。

换句话说：

Agent 安全的理论地图已经画得很大，但真正被红队“走过”的区域还集中在少数热点。

一个 ASR，正在装下完全不同的安全后果

论文对现有 Agent 安全评测提出了另一个很重要的问题：大家都在报告 ASR，但不同论文里的 Attack Success Rate 可能根本不是同一种“成功”。

• 有些实验把模型生成了攻击者希望看到的文本算作成功；

• 有些实验要求 Agent 真的选择某个错误工具；

• 有些实验以敏感信息真正泄露作为成功；

• 还有一些实验要求 Agent 完成任务并修改外部系统状态。

这些显然不是同一个安全等级。

因此论文建议，Agent 攻击结果至少应该区分三个层级：

• Model Compromise：模型受到影响。攻击改变了模型生成的内容。

• Agent Compromise：Agent 受到影响。攻击进一步改变了 Agent 的目标、状态、计划或者即将执行的动作。

• System Impact：系统产生真实影响。攻击已经造成可验证的、未经授权的、有害的或者持久性的外部状态变化。

这一区分非常重要。

模型被骗，不等于 Agent 被攻破；Agent 被攻破，也不等于外部系统已经受到影响。

如果仍然把它们全部压缩成一个 ASR，两个“攻击成功率都是80%”的系统，实际安全后果可能完全不在一个数量级上。

从这个角度看，未来 Agent 安全评测需要逐渐从单一的 Response-based Evaluation，走向同时观察：

状态、动作、权限和执行轨迹。

Agent 安全的最小评测单元，正在从一次响应变成一条轨迹

传统大模型 Benchmark 很大程度上围绕 Prompt 和 Response 构建。

但 Agent 系统存在一个新的问题：

即使模型相同、Prompt 相同，只要长期记忆、工具返回结果、环境状态或者其他 Agent 的行为发生变化，两次执行也可能得到完全不同的轨迹。

因此，论文认为 Agent 安全实验要想真正可复现，除了记录模型和 Prompt，还必须记录：

模型版本与参数、工具版本、权限、初始记忆、环境状态、多 Agent 拓扑以及完整执行轨迹。

这里实际上出现了 Agent 安全评测范式的一个重要变化。

以前最基本的评测样本是：

一条输入 → 一条输出

未来更可能变成：

初始状态 → 一系列观察、推理、记忆和动作 → 最终系统状态

也就是一条完整的 Execution Trajectory。

这也解释了为什么论文特别强调轨迹级安全：在复杂 Agent 系统里，危险行为未必存在于某一个明显异常的动作中。可能每一步单独看都正常，真正的问题只有把几十步执行历史放在一起时才会出现。

13个待解问题

论文最后没有再继续扩充攻击列表，而是根据现有评测暴露出的不足，提出了 13 个开放问题。

如果不逐条照搬论文，而按照研究方向重新归纳，大致可以分成五组。

第一组：我们究竟应该怎样衡量 Agent 安全？

前 3 个问题关注评测本身。

不同攻击模型、不同 Agent 架构和不同实验环境下，安全证据的成熟度应该怎样统一衡量？

Model Compromise、Agent Compromise 和 System Impact 又应该如何建立可比较的指标？

以及，一个在单 Agent 或某种多 Agent 拓扑中得到的安全结论，究竟能不能迁移到另外一种架构？

这些问题背后其实都在指向同一个事实：

Agent 安全需要从“一个攻击成功率”走向更完整的系统评测体系。

第二组：从单次攻击转向长程运行安全

OQ4—OQ7 关注的是 Agent 长时间运行之后出现的问题。

例如，Agent 本来就需要根据环境不断调整自己的目标和计划，那么怎样区分合理的目标调整与恶意诱导形成的 Goal Drift？

如果每一步动作都合法，但几十步组合起来最终违反了用户目标，能否在不可逆结果发生之前检测出来？

长期记忆受到污染后，怎样恢复恶意状态，同时保留 Agent 真正学到的有价值信息？

以及，一个 Agent 如果只在某种隐藏触发条件下表现异常，甚至能够意识到自己正处于安全测试之中，现有 Benchmark 又该怎样发现它？

这些问题表明，未来 Agent Guardrail 可能不能只检查：

Prompt、Response 或单次 Tool Call。

它还需要理解：

目标、状态、执行历史、授权关系和后续影响。

第三组：多 Agent 与人类本身也是攻击面

OQ8—OQ10 聚焦 Multi-Agent 与 Human–Agent。

多 Agent 安全不是把一个单 Agent Benchmark 同时跑十遍。

当多个 Agent 通过共享状态、委托、通信和共识机制共同完成任务后，一个被影响的 Agent 能不能进一步改变整个系统，取决于它所处的位置、通信拓扑、权限以及其他 Agent 如何聚合信息。

与此同时，Human-in-the-loop 也并不天然等于安全。

Agent 可以利用人的自动化偏见、生成误导性的解释，或者通过大量重复确认制造“审批疲劳”；攻击者同样可以诱导用户为 Agent 的错误动作主动授权。

因此：

增加一个人工确认按钮，并不意味着建立了真正有效的人类监督。

第四组：供应链和物理世界会成为新的安全边界

OQ11—OQ12 把问题进一步推向系统外部。

现代 Agent 会不断依赖第三方 Tool、Skill、Plugin、MCP Server、模型、代码库和外部服务。

一个组件安装时是可信的，不代表它未来始终可信。更新、依赖变化、服务端行为变化都可能改变原本建立的信任关系。因此论文提出，Agent 组件未来可能需要持续认证、持续监控和动态撤销信任。

当 Agent 进一步进入机器人、汽车、实验自动化和工业系统之后，问题会更加严重。

一句错误文本可以删除。

一次错误的物理动作却可能不可逆。

这意味着 Agent 安全指标最终还需要从“是否生成危险内容”，真正走向：

是否产生了可验证的现实世界后果。

第五组：Benchmark 自己也要能够“活下去”

最后一个问题关注 Agent Benchmark 的长期可复现性。

模型会升级，工具会升级，API 会改变，MCP Server 会更新，Agent 的拓扑也可能不断变化。

那么今天得到的 ASR，一年以后还是否具有比较意义？

论文给出的方向是建立持续维护的 Benchmark，保存版本化的任务、配置和结果，并尽可能记录环境快照与完整执行轨迹，使实验能够重新播放和比较。

安全的对象，正在从“模型”变成“执行中的系统”

如果把这篇论文压缩成一句话，它真正想表达的其实并不是：

Agent 有32类安全风险。

而是：

我们需要改变描述和评估 Agent 安全的基本单位。

过去谈大模型安全，我们习惯围绕模型本身展开：

输入是什么，输出是什么，模型有没有拒绝。

到了 Agent 时代，真正需要保护的对象逐渐变成一个持续运行的系统：

它有自己的目标和状态，会形成长期记忆，会调用具有权限的工具，会和其他 Agent 交换信息，还可能修改数字世界甚至物理世界。

因此，安全研究的关注点也在随之移动：

从 Prompt 走向 State，

从 Output 走向 Action，

四维威胁地图最大的意义，也许并不是替我们记住了32个攻击名称，而是提供了一套更适合 Agent 时代的问题框架：

攻击影响了什么？

从哪个信任边界进入？

当我们开始用这四个问题审视 Agent 安全时，一个更重要的事实也随之暴露出来：

今天我们已经能够描述很多风险，但距离真正系统地验证这些风险，仍然有很长的路要走。

声明：本文来自模安局，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。