Agent 安全的真正战场：一文看懂大模型智能体的攻击面重构

今天很多人谈 Agent 安全，脑子里想到的还是老三样：提示注入、越狱、输出审核。但这篇论文真正想说的是，当大模型从”会回答”变成”会调用工具、会接外部知识、会自己规划任务”之后，安全问题就已经不再是单纯的内容安全问题，而是一个完整的系统攻击面问题。

https://arxiv.org/pdf/2603.22928

论文把研究对象明确限定为三类系统：带工具/API 的系统、带 RAG 的系统，以及具备自主规划或多智能体循环的系统；纯聊天问答并不在它的核心范围内。作者的中心判断也很明确：Agentic AI 的攻击面，与传统 LLM 应用相比，已经发生了质变。

换句话说，这篇文章不是在重复”Prompt Injection 很危险”这种大家已经知道的共识，而是在进一步追问：为什么 Agent 一旦接入工具、记忆、检索和执行环境，整个安全边界就会被打穿？

作者给出的答案是，Agent 系统把模型、数据、工具、状态、外部服务这些原本相对分离的部件串成了一条连续执行链。于是攻击者不再只是”诱导模型说错话”，而是可以借助这条链路，逐步走向越权调用、数据泄露、代码执行、资源滥用、记忆污染，甚至供应链投毒。

Agent 的总攻击面图

论文最有价值的地方，是先画出了一张 Agent 系统的参考架构图。图里把一个典型 Agent 系统拆成了用户入口、Planner/Orchestrator、LLM Core、Policy/Guards、Memory Store、Retriever、Tool Broker、Secrets/Vault，以及下面的浏览器工具、代码执行沙箱、文件 I/O、外部 API、RAG Indexer、Vector DB、文档源等模块；更关键的是，作者在这张图上进一步标出了 AS1-AS10 十个攻击面，分别对应用户输入、检索内容进入、工具调用序列化、沙箱边界、文件 I/O、API Token 范围、索引器、检索/ANN、长期记忆、审计遥测等关键位置。论文强调，这些位置才是 Agent 安全真正需要逐个审视的信任边界。

这张图的意义很大。它把很多团队嘴里的”Agent 很复杂、风险很多”，变成了一张可以真正拿去做架构审计的图。你会发现，问题根本不只在模型本身，而在模型和外部世界之间那些被打通了的接口。一段恶意文本本身并不可怕，可怕的是它被当成了工具参数、文件操作、API 请求、向量库污染内容，或者被写入长期记忆之后，在未来某个时刻再次触发。这种”从文本到动作”的跨层传导，正是 Agent 安全与传统聊天机器人安全的本质区别。

与 Figure 1 配套的 Table 1 也很重要。表格把攻击面按 Prompt/Content、RAG（Indexing/Retrieval）、Tool、API/Cloud、State/Memory、Multi-agent、Supply chain 几个维度展开，并同时标注了各自常见前置条件、对应攻击路径、持久化方式和影响结果。它其实在告诉读者：Agent 风险不是几个孤立点，而是一组可拼接、可级联、可持久化的系统性向量。

Agent 安全要按攻击目标来理解

论文把攻击目标拆成了 G1 到 G7 七类，包括数据泄露、完整性破坏/安全绕过、权限提升、资源滥用/拒绝服务、欺诈与财务损失、持久化/后门植入、供应链破坏。这个分类的价值在于，它把 Agent 风险从”内容层”往”系统层”和”业务层”推进了一步。比如在传统聊天场景里，大家重点关心的是模型有没有说不该说的话；但在 Agent 系统里，攻击者真正追求的往往不是一句违规回复，而是拿到更高权限、调用更危险的工具、污染未来任务流程，或者把恶意能力固化下来。

尤其值得注意的是 G3、G6、G7 这三类目标。

G3 是权限提升，意思是攻击者原本只有”输入一句话”的能力，却借助 Agent 的工具和权限，最终撬动了代码执行、管理员 API、内部文档等更高价值资源；

G6 是持久化，意味着恶意影响不会随着本轮对话结束而消失，而是进入记忆、索引、文件、工件甚至系统配置中；

G7 则是供应链破坏，指向框架、插件、依赖、模型权重、嵌入服务等更上游的位置。论文明确指出，Agent 安全的问题不只是”这次回答有没有错”，而是系统有没有被攻陷、能力有没有被劫持、后门会不会在未来继续生效。

这也是为什么这篇论文很适合企业安全团队看。因为企业做 Agent 落地时，真正要面对的绝不是”是否会输出一句不合规的话”这么简单，而是更接近 IAM、最小权限、工具白名单、检索边界、工作流授权、供应链治理这些更”传统安全”的问题。论文实际上是在提醒行业：Agent 安全的重心，正在从文本审核转向权限治理与执行控制。

真正危险的是从不可信输入到高权限动作的整条链

论文提出了一个很关键的”因果威胁图”思路。论文把攻击过程画成了一条从攻击者控制内容、经过检索和模型、再走到工具代理、文件系统、外部 API、数据资产的因果链路，中间还标出了可以被拦截的防御点，比如 risk-aware rerank、schema validate、egress control、kill-switch 等。这个图想表达的意思非常直接：安全不是只盯着输入端，而是要看攻击能否沿着因果链逐步穿透到最终效果层。

论文抽象出五条代表性路径，其中最核心的是4条：

第一条是 P1 直接提示词到工具滥用，也就是用户直接诱导 Agent 调用危险工具；

第二条是 P2 间接内容通过 LLM 到工具，恶意指令被埋进网页、邮件、文件、PDF 中，先进入检索或浏览流程，再诱导模型调用工具；

第三条是 P3 跨工具跳转，一个工具为另一个工具铺路，比如先社工骗到凭证，再调用云 API；

第四条是 P4 索引投毒到检索到响应，恶意内容先污染知识库，等未来查询命中后再触发；

第五条是 P5 多智能体跳转传播，一个受影响的 Agent 再把恶意消息扩散给其他 Agent。论文强调，现实中的很多事故并不是由一个单点漏洞触发，而是由多条链路串起来共同完成的。

这一点特别重要。因为它意味着我们不能再用”输入安全""输出安全”这种二维思路去理解 Agent。Agent 的核心风险在于：不可信输入能否借助模型、检索、工具和状态管理，最终转化成高权限动作。一旦理解了这一点，就会知道为什么单纯加一个 system prompt、加一个输入审核、加一层输出拦截，远远不够。

LLM 加工具默认就应按高危系统对待

这篇论文在证据综述部分给了一个非常强的判断：“LLM+tools implies RCE risk unless proven otherwise”，也就是”只要接了工具，默认就应该按可能导向代码执行或危险动作来评估，除非你能证明不是。”

作者引用的证据包括：LLMSmith 报告了 11 个 Agent 框架中的 19 个 RCE 漏洞；间接提示注入不仅可行，而且很难彻底消除；RAG 也并不天然更安全；多智能体协作还会进一步放大攻击传播半径。论文据此得出的判断是，表层护栏只能挡住浅层问题，真正有效的仍然是结构性控制。

今天不少团队仍然把 Agent 安全理解为：前面做一点内容检测、system prompt 里多写一点规矩、后面再接一个安全大模型兜底。问题在于，这些手段的对象仍然是”文本”，而 Agent 的核心风险早已变成了”动作”。当模型可以执行 shell、读写文件、操作知识库、连接云 API、调用支付或办公系统时，风险重心就已经转向动作授权、能力分级、参数约束、运行隔离和异常回滚。

Agent 安全该怎么测

很多 Agent 安全论文的问题是，讲了半天攻击和防御，但没有给出可操作的评估指标。这篇文章往前走了一步，提出了一组更适合 Agent 场景的指标，包括 Unsafe Action Rate（UAR）、Policy Adherence Rate（PAR）、Privilege-Escalation Distance（PED）、Time-to-Contain（TTC）、Patch Half-Life（PHL）、Retrieval Risk Score（RRS）、Out-of-Role Action Rate（OORAR）和 Cost-Exploit Susceptibility（CES）。

其中，UAR 用来看不安全动作触发率，PED 用来衡量从不可信输入到高权限动作之间隔了几层边界，RRS 用来评估检索结果本身的风险，OORAR 则用来检测 Agent 是否做了超出自身角色合同的动作。

这组指标背后其实隐含着一个非常清晰的产品方向：Agent 安全评测不能再只测”它会不会说错话”，而要测”它会不会做错事”。这意味着评测对象要从单轮对话，转向执行轨迹、工具调用链、策略判定记录、检索结果包和成本日志。

别幻想单点防御，必须分层治理

论文在附录里把防御按作用位置分成了几层：摄取前/索引前防御、推理时防御、Agent 逻辑防御、基础设施防御，以及监控与响应。

作者明确说，没有哪一个控制点可以单独解决问题，部署 Agent 系统必须采用 defense-in-depth。具体来说：

在数据层，要对 HTML、PDF、Office 等内容做最小化和规范化处理，去掉脚本、宏和自动执行逻辑；

在检索层，要做来源可信度和 ACL 感知检索；

在工具层，要采用严格 schema、allow-list 和 effect checks；

在执行层，要做沙箱隔离、无网/限网、CPU/内存/时间限制、路径隔离；

在运行期，则要有不可篡改日志、异常规则、SIEM、人工接管和 kill-switch。

更有意思的是，论文最后给了一个部署手册式的附录。这里面讲得非常工程化：上线前先做 threat modeling；能力按最小权限逐步放开；prompt 和 policy 要明确区分 user/system/retrieved roles，不能把秘密写进 prompt；供应链上要锁版本、看 CVE、做 SBOM；上线前要做覆盖 prompt injection、schema abuse、RAG poisoning、connectors 的红队测试；上线后则要按 UAR、PAR、PED、TTC 等指标持续追踪，并把能力变更当成生产变更来做风险评审。这个附录其实已经不是”论文建议”，而是一个简化版的 Agent 安全部署 checklist。

启发

今天很多公司在做 Agent 落地时，容易有一个误区：认为只要模型本身足够强、提示词写得足够严、前后加一点护栏，就可以把系统安全问题压下去。

这篇论文实际上是在提醒行业，Agent 的难点从来不只在模型，而在”模型接入真实世界”之后，系统边界如何被重新定义。一旦工具、知识库、工作流、外部 API、记忆机制都被接进来，攻击面自然也会同步扩张。安全工作的重点，必然从”模型回答对不对”转向”系统有没有被误导执行、越权调用、长期污染和跨节点传播”。

所以，这篇论文最值得记住的一句话，不是”Prompt Injection 很危险”，而是：Agent 安全的主战场，正在从模型内容层，迁移到权限、检索、工具、状态和执行链路。谁还把 Agent 安全理解成”提示词加几条规矩 + 输入输出过一遍分类器”，谁就还停留在 Chatbot 时代。

结语

这篇 SoK 的厉害之处，不在于提出了某个石破天惊的新攻击，而在于它把过去两三年 Agent 安全领域零散出现的 prompt injection、RAG poisoning、tool abuse、memory poisoning、多智能体传播和供应链破坏，第一次比较完整地装进了一套统一框架里。

它画出了攻击面、给出了攻击目标、梳理了攻击路径、总结了证据、提出了指标，还顺手给了一版部署手册。对于想做 Agent 安全产品、Agent 平台治理、企业级智能体落地的人来说，这样的论文未必最”炸裂”，但往往最有用。

如果要用一句话总结这篇文章：它不是在告诉你 Agent 有多危险，而是在告诉你，Agent 为什么必须按一个高危的复合系统来治理。