Agentic AI 的攻击与防御全景：系统性综述

论文概览

这是首个从系统级视角系统分析 AI Agent 安全的综述论文。论文将 AI Agent 定义为"结合 LLM 与传统软件组件的混合软件系统"，从设计空间、攻击景观、防御机制三个维度构建了完整的安全分析框架，并通过 AutoGPT 和六个真实 Agent 的案例研究揭示了现有防御的关键缺口。

核心贡献

论文的三大贡献构成了 Agent 安全研究的基石：

贡献一：Agent 设计维度框架

提出七个关键设计维度，每个维度都代表一个从"最不灵活"到"最灵活"的连续谱系：

核心权衡：灵活性越高，功能越强，但攻击面也越大。这七个维度与 MITRE ATLAS 和 OWASP Top 10 for LLM 框架建立了映射关系。

贡献二：攻击景观与风险分类体系

论文将攻击向量按威胁模型分为三类，并将安全风险归纳为七类：

攻击向量（V1-V6）：

安全风险（R1-R7）：

风险放大机制：攻击面风险（R1）→ 模型风险（R2, R3, R4）→ 后果风险（R5, R6, R7）形成级联放大。以 EchoLeak 攻击为例：恶意文档利用异构不可信接口（R1），通过 Agent 检索管线触发不受约束的数据流（R3），最终将敏感用户数据泄露到攻击者控制的服务器（R5）——全程无需用户交互。

贡献三：防御景观系统化

论文将防御机制分为五大类别，并基于传统安全的纵深防御原则进行系统组织：

设计维度与风险映射

七个设计维度与风险的映射关系揭示了灵活性如何放大安全风险：

• Input Trust / Memory / Tool → 直接扩大攻击面（R1）。更多外部数据源引入间接提示注入风险，持久记忆创造记忆投毒目标，第三方工具引入供应链风险。
• Workflow → 主要驱动模型风险（R2, R3, R4）。从简单聊天机器人到 LLM 定义的动态执行，灵活的控制流为劫持 Agent 推理提供更多机会。
• Access Sensitivity / Action / User Interface → 决定后果风险的严重程度（R5, R6, R7）。访问更敏感数据的 Agent 一旦被攻破，影响更大。

案例研究：真实世界 Agent 防御分析

论文分析了六个开源 Agent 的防御覆盖情况：

AutoGPT CVE 深度分析

论文对 AutoGPT（180k+ GitHub stars）进行了详细的 CVE 分析，跟踪了从 v0.4.3 以来的五个真实漏洞：

关键发现：所有五个 CVE 都缺少**信息流控制（IFC）**这一防御层。现有的补丁都是"头痛医头"的补丁式修复，而非系统性的防御设计。这验证了论文的核心论点——需要纵深防御而非单一机制。

攻击方法分析

论文指出，由于攻击复杂性，大多数现有攻击严重依赖人工构建攻击路径和载荷。攻击载荷主要基于预定义的攻击模式：

• 角色扮演场景：模拟特定身份绕过安全约束
• 分隔符混淆：利用特殊字符混淆指令边界
• 指令重置：要求 LLM 忽略先前上下文

近期研究开始探索自动化攻击方法：

• 攻击载荷自动化：设计专门的 fuzzing 方法生成提示注入攻击
• 注入点自动化：利用 LLM 自身识别有效注入点（如 just-in-time injection）

防御机制详解

1. 输入护栏（Input Guardrails）

设计维度：检测机制 × 验证目标 × 缓解策略

• 检测机制：规则型（严格但不灵活）vs 模型型（可泛化但开销大）
• 验证目标：内容型（语义检查）vs 来源型（验证数据来源可信度）
• 缓解策略：过滤 / 消毒 / 结构化 / 中和

局限：输入空间庞大且多样，难以建立通用安全标准。模型型检测器易被自适应攻击绕过，规则型需要大量人工。

2. 输出护栏（Output Guardrails）

检查 LLM 输出或工具执行结果，防止恶意行为。从规则匹配到模型分类器，混合方法采用结构化策略框架处理非结构化数据。

局限：比输入护栏消耗更多计算资源和时间，因为依赖 LLM 输出且需要处理更多数据。

3. 信息流控制与污点追踪（IFC & Taint Tracking）

为每条数据分配安全标签，沿 Agent 执行传播，检测违反格约束的不安全信息流。

• 完整性保护：阻止不可信输入影响工具调用决策
• 机密性保护：防止敏感数据到达不可信输出
• 机制：符号变量型 / 多次执行型 / 模型型

局限：多次执行或变量推理带来大量运行时开销，对延迟敏感的 Agent 不实用。

4. 权限分离（Privilege Separation）

• 垂直分离：Planner-Processor 分离（类似内核-用户分离），将工具调用规划（高权限）与工具结果处理（低权限）隔离
• 水平分离：按应用或功能划分并行组件，各自只与专用工具交互

局限：主要针对简化环境中的通用间接提示注入，难以应对 Web、文件系统、数据库等复杂真实环境。

5. 形式化验证（Formal Verification）

• VeriSafeAgent：将用户意图形式化为 UI 状态转换上的 DSL，验证 GUI 操作与用户任务对齐
• Formal-LLM：将形式语言与自然语言集成，实现可控的 LLM Agent

局限：仍处于新兴阶段，需弥合符号保证与非符号行为建模之间的鸿沟。

开放挑战

论文提出了六个关键开放挑战：

1. 可组合防御：多个防御机制组合可能产生涌现性错位，需要确保组合后的防御不产生新的攻击面
2. 自适应防御：当前防御多为静态规则或固定模型，需要能适应动态任务和信任上下文的自适应策略
3. 标准化身份与访问控制：Agent 需要专属身份、委托机制和动态访问控制策略，当前部署缺乏统一框架
4. IFC 实用性：信息流控制的运行时开销过高，需要更高效的实现方式
5. 人机协同的决策疲劳：频繁的验证提示可能导致用户疲劳，需要智能化的提醒频率控制
6. 真实环境复杂性：现有防御主要在简化环境中验证，需要应对 Web、文件系统、数据库等真实环境的多样挑战

与现有综述的区别

启示与思考

这篇综述对 AI Agent 安全领域的贡献在于它建立了一个可操作的框架——不是泛泛而谈"Agent 不安全"，而是精确地定义了"哪些设计选择引入了哪些风险，需要哪些防御"。

对 AARM 框架的启示：论文的七维设计空间与 AARM 的三层架构（意图授权、执行隔离、副作用验证）存在天然映射。Input Trust 维度对应意图授权层，Workflow/Action 维度对应执行隔离层，而 Memory/Access Sensitivity 维度对应副作用验证层。论文的 R1-R7 风险分类可以作为 AARM 规则引擎的威胁模型基础。

纵深防御是必由之路：AutoGPT 案例研究表明，单一防御机制（如输出护栏）无法覆盖所有风险。CaMeL 和 FIDES 的信息流控制方法代表了更有前途的方向——通过在系统架构层面而非运行时检测层面解决问题。

Agent 安全与传统安全的桥梁：论文成功地将 CIA 三元组、最小权限、完全中介、纵深防御等传统安全原则映射到 Agent 场景。这不是简单的移植——Agent 的"非符号化行为"（LLM 的概率性输出）为传统安全原则的落地带来了全新挑战。形式化验证在 Agent 场景的应用（VeriSafeAgent、Formal-LLM）是这一桥梁的前沿探索。

---

完整翻译

摘要

将大语言模型与非 AI 系统组件结合的 AI Agent 正在实际应用中快速涌现，提供了前所未有的自动化能力和灵活性。然而，这种前所未有的灵活性也引入了与传统软件系统根本不同的复杂安全挑战。本文提出了首个关于 AI Agent 安全的系统性综合综述，包括设计空间分析、攻击景观和防御机制。我们进一步进行了案例研究，指出了现有 Agent 系统安全保护的缺口，并识别了这一新兴领域的开放挑战。我们的工作还引入了首个理解 AI Agent 安全风险和防御策略的系统性框架，为构建安全的 Agent 系统和推进这一关键领域的研究奠定了基础。

1 引言（节译）

Agentic AI 系统的快速发展已经从根本上改变了 AI 格局，标志着从孤立语言模型到集成混合系统的范式转变——这些混合系统将大语言模型（LLM）与多样化软件组件结合。这些混合系统通过无缝集成 AI 推理和传统软件，展示了前所未有的能力，实现了动态工具使用和自主任务执行。Agentic AI 系统现在驱动着从简单聊天机器人到软件开发和 Web 浏览自动化的广泛应用。

Agentic AI 系统的安全影响正变得越来越关键，因为最近的事件展示了其漏洞的严重性。提示注入攻击已被利用来访问私有 GitHub 仓库，远程代码执行漏洞使攻击者能够获得未授权的系统访问。数据泄露攻击通过恶意文档附件和邮件转发泄露了敏感信息，而服务器则暴露了用户聊天和凭证数据。攻击者还在利用 Web Agent 访问用户的个人银行账户。这些事件凸显了 Agent 系统的灵活性和自动化能力虽然使其强大，但也创造了复杂的、传统软件系统或独立 AI 模型所不具备的安全挑战。

现有研究虽然在理解 AI Agent 安全方面做出了重要贡献，但大多数努力集中在特定攻击向量或单个系统组件上，主要是提示注入攻击。然而，这些研究缺乏从整体角度考虑 Agent 系统防御的视角。社区需要一个系统性框架来理解多组件集成如何引入新的攻击面，并需要根本不同的安全方法。

本文通过提供 Agentic AI 系统安全景观的首个系统化知识来填补这一缺口。我们从整体系统视角审视 Agent 安全，研究 LLM 和传统软件的组合如何创造独特的安全挑战——这些挑战无法仅通过组件级防御来缓解。

我们的贡献包括三个方面：

• Agent 设计维度：我们提出了一个系统性框架，通过七个关键设计维度来刻画 Agentic AI 系统：输入信任、访问敏感度、工作流、动作、记忆、工具和用户界面。我们分析了每个维度的灵活性如何影响安全风险，并将这些维度映射到 MITRE ATLAS 和 OWASP Top 10 for LLM 等已有框架。
• 攻击景观与分类体系：我们开发了一个按威胁模型（外部、用户级和内部攻击者）组织的攻击向量系统性分类体系，并提供了涵盖 CIA 三元组的七类安全风险的综合分类，以及风险交互和放大模式的系统级分析。
• 防御景观系统化：我们系统调研了现有防御机制，并进行了多项案例研究，识别了防御的具体设计维度和开放挑战。

3 设计景观

3.1 设计组件

在本文中，我们将 AI Agent 定义为结合传统软件组件和 AI 模型的混合软件系统。一个 AI Agent 通常包含以下组件：

LLM。Agent 的核心推理引擎，通过推理时输入-输出接口运行。在一个 Agent 中，LLM 通常承担两个角色：规划器（Planner）将用户任务分解为逐步计划，执行器（Actor）通过调用工具、生成内容或查询记忆来执行各个步骤。

记忆。Agent 用于存储和检索信息的机制。包括会话追踪（Session Trace，当前会话内的交互记录）、长期存储（Long-term Storage，跨会话的持久化数据）和内部 RAG（基于检索增强生成的知识库）。

工具。Agent 可以调用的外部能力。工具可以通过标准化协议（如 MCP）实现。值得注意的是，工具可以由 Agent 设计者或第三方提供商开发。

外部环境。Agent 交互以完成任务的外部上下文。不同类型的 Agent 在不同环境中运行：Web Agent与浏览器交互，处理来自不同 Web 源的任意不可信内容；编码 Agent在 IDE 和本地文件系统中操作；计算机使用 Agent通过可访问性 API 控制跨应用程序的 GUI 元素。

Agentic 系统与传统系统的关键区别体现在三个方面：第一，Agentic 系统结合传统程序与 AI 模型推理，而传统系统主要依赖符号逻辑；第二，传统软件的工作流主要是预编程的，而 Agentic 系统可以基于不同任务和输入上下文动态决定工作流和动作；第三，Agentic 系统使用支持语义检索的向量化记忆，而传统系统使用基于精确匹配的检索。

3.2 设计维度与安全影响

基于 Agent 结构，我们识别出七个 Agent 设计维度，每个维度代表一个灵活性的连续谱系。

输入信任（Input Trust）。对 Agent 依赖的外部数据源可信度的分类。从不使用外部数据（最高信任）到依赖任意、潜在不可信的外部数据源（最低信任但最高灵活性）。

工作流（Workflow）。Agent 的动作序列以及谁定义这些序列，类似于传统软件中的代码。从无复杂工作流（简单聊天机器人）到开发者定义工作流，最终到 LLM 定义的动态工作流。

访问敏感度（Access Sensitivity）。Agent 对系统或环境中敏感数据的访问级别。从无敏感数据到已知敏感数据源，最终到任意敏感数据。

动作（Action）。Agent 可以执行的操作范围。从仅 LLM 响应，到检索增强响应，最终到包含代码执行的完整执行能力。

记忆（Memory）。Agent 随时间存储和检索信息的方式。从无记忆操作，到会话级记忆，最终到跨会话持久记忆。

工具（Tool）。Agent 可用的工具范围。从无工具，到已知工具，最终到选择任意工具。

用户界面（User Interface）。用户与 Agent 交互的方式。从纯文本交互，到通过图像预览的图形交互，最终到 Web、终端和 IDE 的多模态交互。

安全影响：灵活性越高，攻击面越广。例如，简单聊天机器人的攻击目标仅是输入数据和模型参数；而在多 Agent 系统中，攻击者可以针对 LLM、共享记忆存储、工具和外部环境，攻击向量存在于系统组件之间。

4 攻击景观

4.1 攻击向量

我们在三种威胁模型下讨论攻击向量，分类基于攻击者在攻击执行时对 Agent 的访问能力，而非攻击开发期间的能力。

外部攻击者。攻击者处于外部环境中，不能直接与 Agent 交互，但可以操纵 Agent 可能检索和处理的外部资源。这是最受限但高度现实的威胁模型。

• V1 间接提示注入：攻击者在 Agent 交互的外部环境中注入恶意指令。当 Agent 从该环境检索内容时，可能检索并执行恶意指令。
• V2 恶意数据注入：攻击者注入非提示类恶意数据。当此类数据在敏感操作中被消费时，可能触发安全故障。
• V3 工具投毒与操纵：攻击者在 Agent 交互的外部工具名称或描述中注入恶意指令，或在工具实现中注入恶意载荷。

用户级攻击者。攻击者可以访问 Agent 输入，可以直接向 Agent 提供恶意内容，或将其注入到良性用户输入中。

• V4 直接提示注入：攻击者可以控制良性输入的某些部分，并在用户输入中附加恶意指令。

内部攻击者。攻击者可以访问 Agent 内部的部分或全部组件，这是最强的假设。此攻击向量构成最严重的威胁，但不太实际。

• V5 模型投毒：攻击者在 LLM 中注入后门，可在推理时激活以实现恶意行为。
• V6 记忆投毒：攻击者可以直接操纵 Agent 的记忆来注入恶意指令或虚假知识，或者从记忆中泄露敏感用户数据。

4.2 安全风险

R1 异构不可信接口。Agentic 系统从外部环境、第三方工具、记忆系统和用户输入等多个异构源接收输入，每个接口有不同的信任级别和安全保证，创造了大量攻击面。

R2 错误指令遵循。LLM 可能因对抗性输入而偏离合法用户指令，执行攻击者指令而非用户意图。在 Agent 中，这种偏离直接导致未经授权的动作。

R3 不受约束/不安全的数据流。由于 LLM 的随机性，Agent 系统中数据可以从任何不可信接口的输入自由流向任何输出，不像传统系统中数据传播受编程语言、类型系统和访问控制约束。这导致私密数据泄露（R5）、数据损坏（R6）和资源耗尽（R7）。

R4 幻觉与模型错误。模型经常幻觉并生成错误信息，在 Agent-环境交互中这一问题更加严重，因为 Agent 会对幻觉内容采取行动，产生超越错误信息的现实后果。

R5 私密数据泄露。Agent 跨多个组件处理敏感数据（用户对话、持久记忆、工具凭证、环境资源），创造了未授权数据访问的机会。

R6 未授权操作与数据损坏。Agent 可能通过未授权的操作（如未经授权的购买、任意代码执行）和直接修改存储资源的数据损坏来违反完整性。

R7 资源耗尽与拒绝服务。Agent 可能因对抗性输入或自身错误而消耗过多资源，包括 LLM token 消耗和 Agent 主机/外部系统的资源使用。

4.3 风险的系统级分析

从设计维度到风险：Input Trust、Memory 和 Tool 维度直接贡献于攻击面扩大（R1）。Workflow 维度主要驱动模型风险（R2, R3, R4）。Access Sensitivity、Action 和 User Interface 维度决定后果风险的严重程度（R5, R6, R7）。

风险放大：攻击面风险（R1）放大模型风险（R2, R3, R4），模型风险随后放大后果风险（R5, R6, R7）。具体而言，EchoLeak 漏洞展示了完整的放大链条：恶意文档利用异构不可信接口（R1），通过 Agent 检索管线触发不受约束的数据流（R3），最终将敏感用户数据泄露到攻击者控制的服务器（R5），全程无需用户交互。

5 防御景观

5.1 安全目标

基于标准安全原则——机密性、完整性、可用性（CIA）三元组——并引入上下文安全（Contextual Security）作为 Agentic 系统的新安全目标。

机密性。确保所有信息仅对授权实体可访问。包括保护系统级密钥（API 密钥、凭证）、Agent 内部记忆、用户私密数据和 LLM 相关数据（模型参数和系统提示）。

完整性。确保 Agentic 系统及其外部环境中的数据和控制流保持可信且未被未授权实体篡改。包括防止对 Agent 记忆、LLM 输出、工具结果和环境数据的篡改。

可用性。保护系统免受拒绝服务攻击和资源滥用，即使 LLM 推理或工具消耗用户资源。

上下文安全。确保 Agent 的行为符合特定上下文的适当性规范，借鉴 Nissenbaum 的上下文完整性理论——信息 flows 只有在其符合特定上下文中的适当性规范时才是可接受的。

5.2 运行时保护

运行时保护机制在 Agent 执行期间提供动态安全强制，检测实时威胁和行为。

输入护栏。检测机制分为规则型（预定义模式或端点白名单）和模型型（训练小模型或提示 LLM 检测恶意提示）。验证目标分为内容型（语义检查）和来源型（验证数据来源）。缓解策略包括过滤、消毒、结构化和中和。

输出护栏。检查 LLM 输出或工具执行结果。从规则型模式匹配到模型型分类器，混合方法采用结构化策略框架处理非结构化数据。

信息流控制与污点追踪。为每条数据分配安全标签，沿 Agent 执行传播，检测违反格约束的不安全信息流。机制包括符号变量型、多次执行型和模型型。

监控。实时跟踪 Agent 行为，检测异常。从静态规则到自适应模型，但长期执行会累积大量日志，存储开销和隐私控制仍未充分探索。

人机协同验证。允许用户验证 Agent 行为和工具使用。设计维度包括验证范围、用户提醒和重复策略。

5.3 安全设计

权限分离。垂直分离（如 Planner-Processor 分离，类似内核-用户分离）和水平分离（按应用或功能划分并行组件）。当前研究主要针对简化环境中的通用间接提示注入，难以应对真实环境的复杂挑战。

形式化验证。将用户意图形式化为 DSL，验证 Agent 行为与用户任务对齐。VeriSafeAgent 将用户意图形式化为 UI 状态转换上的 DSL；Formal-LLM 将形式语言与自然语言集成。这一领域仍处于新兴阶段，需要弥合符号保证与非符号行为建模之间的鸿沟。

5.4 身份与访问管理

身份管理。确保每个操作者在正确身份下运行。支持委托、可审计性和监管问责。架构分为集中式（依赖中央注册或身份提供商）和分散式（使用分布式验证协议）。身份范围可在用户级、Agent 级或任务级定义。

访问控制。管理 Agent 对资源的访问权限。从静态权限规则到动态策略，覆盖 Agent 内部记忆、外部数据库、工具 API 和文件系统。现有工作主要针对检索增强 LLM 应用，Agentic 系统需要更广泛的覆盖。

凭证管理。保护 Agent 与外部服务交互所需的各类凭证。包括机密存储、生命周期管理和凭证配置。

5.5 组件加固

模型加固。SecAlign 和 StruQ 微调模型使其在面对冲突指令时始终遵循初始指令。指令层次感知训练确保系统提示优先于用户输入和外部数据。

工具加固。ETDI 实现加密签名和版本化工具控制元数据，确保工具生命周期完整性。MCP Context Protector 创建 MCP 代理强制执行手动审查流程。

5.6 防御设计原则

三个传统安全原则指导 Agent 防御设计：

纵深防御。有效 Agent 安全需要多个互补防御机制协同工作，而非依赖任何单一方法。

最小权限。Agent 应以最小必要权限和访问权限运行。通过权限分离技术和身份管理实现。

完全中介。所有对敏感资源的访问都应被验证和授权。通过监控系统、访问控制机制和身份管理实现。

6 真实世界 Agent 安全

我们分析了六个开源 Agent 的防御覆盖。

编码 Agent 通用防御。编码 Agent 通常在用户信任的目录中操作。威胁来自多个来源：LLM 可能幻觉并生成错误代码、模型本身可能被后门攻破、看似可信的输入（用户输入、代码仓库、文档）可能包含恶意指令。编码 Agent 通常结合访问控制（路径限制、沙箱执行）与人机协同验证。

Codex。结合访问控制与人机协同验证，为 AI 建议的文件补丁和 Shell 命令提供安全保障。文件补丁在目标文件超出可写路径时请求用户批准；Shell 命令默认在沙箱中执行（限制工作目录访问且无网络）。模型可以请求提升权限在沙箱外运行命令，但需要用户批准。

Gemini CLI。主要依赖人机协同验证进行命令执行。对文件访问和 Shell 命令应用输出护栏，将文件读取限制在工作区目录。Shell 命令维护允许和拒绝列表，对未列出的命令提示用户。

OpenHands。采用多层方法，结合输出护栏与人机协同验证和权限分离。要求 LLM 在每个工具决策时输出安全风险分数，以上下文敏感的方式检测高风险工具使用。

Web Agent 通用防御。Web Agent 特别容易受到间接提示注入攻击（V1），因为它们持续处理来自不同来源的不可信外部输入。Web Agent 通常采用四种防御机制：输入护栏（域名允许/拒绝列表）、输出护栏（防止导航到敏感 URL）、凭证管理（编辑或替换密钥）和监控（浏览遥测）。

7 详细案例研究：AutoGPT

AutoGPT 是最广泛使用的开源自主 Agent 之一，拥有超过 180k GitHub stars。它暴露了一套广泛的工具，使 LLM 能够与异构环境交互，包括互联网、本地文件和执行接口。

A. Docker Compose 注入（CVE-2023-37273）。未清洗的外部内容可以操纵 LLM 生成恶意 Docker Compose 配置，在 Agent 重启时执行恶意容器，导致容器逃逸和主机被攻破（R2, R6）。

B. 路径遍历（CVE-2023-37274）。未清洗的 basename 参数允许路径遍历攻击，写入沙箱外的文件。攻击者通过注入外部内容中的指令，诱骗 LLM 调用 execute_python_code 并使用遍历路径如 ../../main.py，覆盖关键 AutoGPT 源文件（R2, R5, R6）。

C. ANSI 转义序列欺骗（CVE-2023-37275）。当 AutoGPT 通过 browse_website 获取外部 Web 内容时，将检索的内容（包括嵌入的 ANSI 码）直接传递给控制台而不清洗。攻击者制作嵌入 JSON 编码 ANSI 转义序列的恶意网页，欺骗控制台输出可隐藏执行的命令或诱骗操作者批准恶意操作（R3, R6）。

D. 跨站请求伪造（CVE-2024-1879）。缺少 CSRF 保护和宽松的 CORS 设置允许从恶意网页发起已认证的 API 请求。攻击者制作网页，当已认证用户访问时，通过跨域请求静默触发 Agent 操作，实现未授权命令执行和数据泄露（R5, R6）。

E. OS 命令注入（CVE-2024-1881）。AutoGPT 使用仅检查第一个 token 的白名单验证 Shell 命令。这种方法阻止单个危险命令但无法检测操作符链式载荷或单行中的多个命令。攻击者注入指令操纵 LLM 生成带有链式操作符的命令（如 ls && rm -rf /），绕过首词检查（R2, R4, R5, R6）。

防御分析。每个 CVE 的补丁都部署了特定防御机制，但都存在遗留风险。所有五个 CVE 都缺少信息流控制（IFC）防御层——这表明需要从系统架构层面而非运行时检测层面解决安全问题。

8 开放挑战（节译）

Agentic AI 安全领域面临多个关键开放挑战：

可组合防御。多个防御机制的组合可能产生涌现性错位，需要确保组合后的防御不产生新的攻击面。

自适应防御。当前防御多为静态规则或固定模型，需要能适应动态任务和信任上下文的自适应策略。

标准化身份与访问控制。Agent 需要专属身份、委托机制和动态访问控制策略，当前部署缺乏统一框架，依赖临时的、非统一策略。

IFC 实用性。信息流控制的运行时开销过高（多次执行或变量推理），需要更高效的实现方式以适用于延迟敏感的 Agent。

人机协同的决策疲劳。频繁的验证提示可能导致用户疲劳，当前提醒机制通常假设用户具备安全素养，这对普通用户不成立。

真实环境复杂性。现有防御主要在简化环境中验证，需要应对 Web、文件系统、数据库等真实环境的多样挑战。

我们的 SoK 可以作为构建安全 Agent 的指南，并指出未来研究的有意义方向。

参考链接

• arXiv: https://arxiv.org/abs/2603.11088
• MITRE ATLAS: https://atlas.mitre.org/
• OWASP Top 10 for LLM: https://owasp.org/www-project-top-10-for-large-language-model-applications/
• CaMeL (Defeating Prompt Injections by Design): arXiv 2503.18813
• FIDES (Securing AI Agents with IFC): arXiv 2505.23643
• AgentArmor: arXiv 2507.15219