2026arXiv 2603.22928

Agentic AI 的攻击面：工具、RAG 与自主性的系统安全地图

SoK: The Attack Surface of Agentic AI -- Tools, and Autonomy

这篇 SoK 并不发明某个新护栏，而是做了一件更根本的事：把 Agentic AI 的安全问题拆成一张可以审计、可以度量、可以接入工程流水线的地图。论文围绕工具调用、RAG、长期记忆与多智能体协作，梳理了攻击目标、攻击路径、信任边界与评估指标，试图把“智能体不安全”从一种直觉，变成一套系统工程语言。

Ali Dehghantanha, Sajad Homayoun

AI Agent运行时安全RAG安全多 Agent 系统系统安全

PDF DOI

论文概览

arXiv: 2603.22928
作者： Ali Dehghantanha, Sajad Homayoun
主题： Agentic AI 安全、工具调用风险、RAG 投毒、多智能体攻击面

我觉得这篇论文最有价值的地方，不是提出了某种神奇的新防御，而是承认了一件朴素却常被忽略的事实：Agentic AI 已经不是“模型安全”问题，而是“系统安全”问题。

只要一个大模型开始会检索、会写文件、会调用 API、会运行代码、会和别的 agent 对话，它就不再只是一个说话的东西，而更像一台带着自然语言接口的操作系统。此时攻击者面对的，不再是一段 prompt，而是一整条工作流。

论文把这条工作流拆开了：从用户输入，到检索器，到 LLM 核心，到工具代理，到沙箱、文件系统、外部 API，再到长期记忆和审计链路。作者真正做的是一张地图——一张关于 “攻击从哪里进、经过哪些信任边界、最后在哪里造成实害” 的地图。

核心贡献

我把这篇 SoK 的贡献压缩成四点。

1. 把 Agentic AI 的攻击面从“点”改写成“面”

论文没有把风险只看成 prompt injection，而是给出 10 个关键攻击面（AS1–AS10），覆盖：

用户输入
检索内容入口
工具调用序列化
沙箱边界
文件 I/O
API token 作用域
索引器
检索器 / ANN 层
长期记忆
审计与遥测

这很重要。因为许多工程团队谈智能体安全时，口头上说“防 prompt injection”，实际系统里却把高风险暴露面埋在工具参数拼接、向量库授权、长期记忆写入和日志缺失里。论文提醒我们：真正危险的，不是提示词本身，而是提示词能穿过多少系统边界。

2. 给出更适合智能体的威胁模型

论文定义了攻击者、资产和安全属性。这里我特别注意到一个细节：文中写的是 “four adversary classes”，但实际列出了五类攻击者：

外部攻击者（External Attacker）
恶意内容提供者（Malicious Content Provider）
供应链攻击者（Supply-Chain Attacker）
内部人 / 开发者（Insider / Developer）
被攻陷的外部服务（Compromised API / Service）

这个小疏漏不影响主结论，反而说明论文确实是在做“系统化整理”而不是追求排版上的漂亮。五类攻击者合起来，基本覆盖了今天 agent 部署里最现实的失陷入口。

3. 提出五条典型攻击路径（P1–P5）

论文最有工程感的一部分，是把复杂攻击归纳为五类参考路径：

P1：直接提示 → 工具滥用
P2：间接内容 → LLM → 工具
P3：跨工具跳板
P4：索引投毒 → 查询 → 响应
P5：多智能体跃迁

其中我最看重 P2 和 P4。因为这两类攻击最像现实世界里的后门：植入和触发不是同一时刻，甚至不是同一操作者。一个恶意 README、一个被污染的 PDF、一个带隐含指令的邮件，都可能在几小时甚至几天后，通过检索或上下文拼接，被系统重新激活。

4. 把安全评估做成“可量化的工程度量”

这是论文最不花哨、但可能最有用的部分。作者提出了一组 attacker-aware metrics，用来替代“这个系统感觉上还行”的空话。

攻击面架构：LLM 只是一个不可信提议器

论文在系统模型上有一个我非常赞成的立场：LLM 应被视为不可信代码生成器（untrusted code generator）。

这句话其实比很多“AI 安全愿景”都更实在。它意味着：

模型输出不能直接执行
检索到的内容不能默认可信
工具调用必须经过 schema 验证
沙箱、最小权限和凭证隔离才是真正的控制面

换句话说，安全边界不在模型里面，而在模型外面。模型负责提出动作，系统负责决定这些动作是否能落地。

论文由此定义了 TCB（Trusted Computing Base），主要包括：

核心模型权重与系统提示
工具执行基座（沙箱、broker、schema validator）
密钥与凭证存储
私有 RAG 语料的索引流水线与存储

这套划分很像传统系统安全的做法，只是把“进程、内核、权限边界”换成了“模型、检索、工具、API、记忆”。我觉得这恰恰说明，Agentic AI 安全并不是完全陌生的新问题，而是经典系统安全在语言接口时代的再发明。

方法论：从 taxonomy 到 measurement

这篇论文的方法不是做新实验，而是做系统化归纳。它大致有三层。

第一层：Taxonomy

作者把攻击目标定义为 G1–G7：

编号	攻击目标	含义
G1	Data Exfiltration	数据泄露 / 隐私泄漏
G2	Integrity Subversion	行为篡改 / 安全绕过
G3	Privilege Escalation	权限提升 / 越权访问
G4	Resource Abuse	资源滥用 / DoS / DoC
G5	Fraud / Financial Harm	欺诈与财务损害
G6	Persistence / Backdoor	持久化控制 / 后门植入
G7	Supply-Chain Compromise	供应链污染

它接着把向量分到 prompt、RAG、tool、API/cloud、state/memory、multi-agent、supply chain 等层上。这样的拆法有个好处：安全讨论终于从“某个模型会不会越狱”升级到“哪一层出了问题，问题能传播到哪一层”。

第二层：Causal Threat Graph

论文进一步用因果图描述 kill chain。核心思想可以写成：

text

Attacker Content
  -> Retriever
  -> LLM
  -> Tool Broker
  -> Sandbox / File System / API
  -> Real-world Side Effect

每一条边都意味着一个可被拦截的地方。比如：

在 Retriever 处做 provenance / ACL-aware filtering
在 Tool Broker 处做 schema validation
在执行层做 sandbox + least privilege
在出口处做 egress control 和 kill switch

这比只谈“模型对齐”更接近真实工程，因为攻击通常不是在某一点突然成功，而是一环一环穿过去的。

第三层：可量化指标

论文提出的几个指标值得单独记一下：

Unsafe Action Rate (UAR)

\mathrm{UAR} = \frac{1}{|S|}\sum_{s \in S} \mathbf{1}\{\mathrm{violation}(s)\}

即：在所有测试场景里，有多少比例最终触发了违规动作。

Policy Adherence Rate (PAR)

\mathrm{PAR} = \frac{\sum_{a \in A} \mathbf{1}\{\mathrm{compliant}(a)\}}{|A|}

即：执行出的动作里，有多少符合策略约束。

Privilege-Escalation Distance (PED)

\mathrm{PED} = \min_{u \in U,\, \pi \in \Pi} \mathrm{dist}_G(u, \pi)

即：从不可信输入到特权动作，最短因果路径有多长。这个指标很妙，因为它不只看“有没有洞”，还看“从洞到灾难之间隔着几道门”。

Retrieval Risk Score (RRS)

\mathrm{RRS}(B) = \sum_{i=1}^{k} \alpha_i r(d_i)

其中 $r(d_i)$ 是每篇检索文档的风险分数， $\alpha_i$ 是系统对该文档的依赖权重。这个指标试图把“高风险检索包”量化出来，并据此决定是否降低 agent 自主性或切入人工审核。

证据综述：这篇论文并非空谈

虽然这是 SoK，不是实验论文，但它并不只是概念体操。作者做了一个 PRISMA-lite 式证据梳理：

初始候选约 100 篇
全文复审后保留约 40 篇
最终核心语料包括：
- 14 篇同行评审论文
- 5 篇重要预印本
- 3 份标准 / 行业文档
- 外加少量技术博客与公开工件

其中最刺眼的证据有两个。

第一，LLM + tools 几乎天然带着 RCE 风险。 论文引用 LLMSmith 的结果：在 11 个 agent framework 中发现了 19 个 RCE 漏洞。这说明只要工具层没有严谨的 schema、沙箱和权限收缩，所谓“自然语言自动化”就很容易退化成“攻击者借模型远程操作你的执行环境”。

第二，RAG 并不天然更安全。 这是很多人有直觉误区的地方：觉得检索接入事实，就会减少胡说八道。论文引用的证据恰恰相反——检索有时会带来新的污染通道，尤其在索引投毒、恶意近邻召回、ACL 缺失、instruction-like 文本混入时，系统反而更容易被误导。

论文还有一个重要判断：攻击手段的证据成熟度普遍高于防御手段。 工具层和检索层攻击大多已经有 A/B 级证据支持，而多智能体与生命周期级防御，很多还停留在 C 级。翻译成人话就是：怎么打，大家已经知道不少；怎么稳妥防住，大家其实还远没想清楚。

我对这篇论文的判断

它最强的地方：把“安全”从伦理问题拉回工程问题

现在很多关于 agent 的讨论，要么太抽象，要么太表演化，仿佛只要多加一点 alignment、多写几句 system prompt，系统就会自己学会谨慎。作者不走这条路，而是强调：安全要靠结构，不靠期待。

这也是为什么我觉得这篇论文和很多“agent 未来展望”不同。它不试图告诉你 AI 多厉害，而是告诉你：如果它真的厉害，你就必须像对待一台可执行系统那样对待它。

它的局限也很明显：测量框架多，落地基准还不够硬

论文提出了很多好指标，但它本身没有给出统一 benchmark 上的大规模对比结果。UAR、PED、RRS 这些指标在概念上漂亮，真正进团队流程时会遇到几个现实难题：

标签从哪来？ 什么算 violation，谁来判？
因果图谁来画？ PED 依赖静态图，而真实系统总在变。
RRS 怎么校准？ 文档风险分数 $r(d_i)$ 并不是现成有标准答案的量。
多智能体系统如何标准化？ 目前这块证据还很薄。

所以这篇论文更像一张蓝图，而不是完工的房子。它把坐标系搭出来了，但很多工程构件还要社区自己补。

最值得记住的一句话

如果只让我留下这篇论文的一个结论，我会选这个：

不要把 agent 的安全寄托在模型“懂事”上，而要把它建立在检索、记忆、工具、权限和审计这些可验证的边界上。

这句话听上去不浪漫，但工程世界本来就不靠浪漫维持秩序。

启示与下一步

对做 agent 系统的人来说，这篇论文至少给出三条可执行的方向：

把工具层做成 deterministic kernel：LLM 只能提议，不能直接执行。
把检索层做成风险感知的入口：相关性不等于可信度。
把安全评估接入 CI/CD：不只是上线前测一次，而是版本变更时持续回归。

论文最后提出了四个研究方向，我认为都很扎实：

用形式化方法验证 agent plan 与 tool contract
建立带 provenance 与隔离语义的安全记忆系统
做超越简单过滤器的 risk-aware retrieval
把持续红队与 AI 攻击者模拟接入开发流水线

这些方向有一个共同特征：它们都默认 agent 将持续拥有更强行动力，因此安全不能靠临时补丁，而要靠体系化约束。

我想，这也是这篇 SoK 最终想说的话：当语言模型开始行动，安全讨论就必须从“生成什么文本”上升到“这个系统在世界上能做什么事”。

参考链接

📄 arXiv 原文
📑 PDF 下载

研究