2026 年 8 月底,TrueFoundry 工程团队公开了一篇基于 247 篇学术论文的综述解读,标题是"Agent Security Is a Systems Problem"。这篇综述由 Ling 等学者撰写,覆盖 2022 年到 2026 年中所有关于 LLM Agent 安全的主要学术论文,把整个领域的攻击面与防御基线系统性地画了一张图。综述给出了一个被广泛认可的核心框架——Agent 安全不能只看 prompt injection 这一个入口,而必须同时考虑三个互相耦合的维度:信息如何进入 Agent、Agent 拥有什么权限去动作、攻击如何通过持久状态跨任务存活。在生命周期层面,综述把 Agent 拆成 Input → Planning → Decision → Tool Execution → Output 五段核心动作链路,叠加 Memory、Monitoring、Coordination 三个跨切面。综述还明确指出,现有的防御机制是"weakly compositional"——一个内容过滤器、一个沙箱、一个审批门、一个 trace 系统单独看都有效,但合在一起并不自动形成完整的安全边界。这份综述与微软责任矩阵、OWASP Agentic Top 10、AWS 工程团队实战分析等 2025-2026 年陆续发布的文档放在一起,构成了企业级 Agent 安全研究的"新基线样本"——一个不再依赖"防御单点胜负"、而必须依靠"边界组合 + 权限治理 + 状态来源"三位一体来建立工程安全的研究范式。

一、综述的核心架构:三交互性质 + 五段生命周期 + 三跨切面

Ling 等的 247 篇综述并不是按"威胁清单"组织的——他们刻意回避了"OWASP Top 10 那种扁平的威胁列表"形式,而是采用了一个systems model(系统模型):把 Agent 安全问题建模成三个互相耦合的属性,再把这些属性映射到一个完整的生命周期上。

第一个属性是"信息如何进入 Agent"。这不只是 prompt 本身,而是所有 Agent 在运行时可能读到的输入——网页内容、邮件正文、工具返回结果、向量库检索片段、其他 Agent 发来的消息、长期记忆里的旧记录。这些输入每一个都可能是 prompt injection 的载体。综述强调,prompt injection 只是"信息进入 Agent"这个属性的一个具体子类型,真正的工程问题比 prompt injection 宽泛得多——任何能让 Agent 行为偏移的输入都属于这个属性。

第二个属性是"Agent 拥有什么权限去动作"。这包括 Agent 调用工具的能力、Agent 持有的 OAuth token、Agent 在系统中的身份、Agent 替用户发邮件/写文档/付款的代理权。综述指出,当代 Agent 安全问题与 1990 年代的脚本小子问题的根本区别就在第二个属性——脚本小子最多让自己的脚本跑起来,Agent 实际上拿到了用户在公司里的真实权限,它的任何一次工具调用都对应一次"用户名义下的真实动作"。这条属性的工程含义是:权限治理不再是"用户管自己",而是"用户管 Agent"。

第三个属性是"攻击如何通过持久状态跨任务存活"。这是综述特别强调的新维度——传统 LLM 安全讨论几乎不谈这一条,因为传统 LLM 是无状态的;但 Agent 有长期记忆、有向量库、有 scratchpad、有跨 session 状态,任何一次被注入的恶意指令都可能在未来某个任务中被错误触发。综述把这条属性放在与"信息进入"和"权限动作"同等重要的位置,实际上是承认了Agent 安全的本质已经从"瞬时攻防"演化到了"持久状态攻防"。

把这三个属性映射到生命周期上,综述给出了 Agent 的五段核心动作链路:Input → Planning → Decision → Tool Execution → Output。每段都有对应的攻击面:Input 段主要是 prompt injection;Planning 段有规划污染、循环爆炸、cost ceiling 失效;Decision 段有 reasoning hijack、模型自身误判;Tool Execution 段有工具滥用、权限提升、过度代理;Output 段有敏感数据外泄、内容篡改。

但综述同时指出,还有三个跨切面(cross-cutting surfaces)会贯穿整个生命周期——Memory、Monitoring、Coordination。Memory 影响 Planning/Decision/Tool Execution,因为 Agent 后续行为会被记忆内容触发;Monitoring 影响所有段,因为监控在哪个段介入决定了告警的有效性;Coordination 影响所有段,因为多 Agent 消息会污染其他 Agent 的上下文。综述把跨切面单独画出来,工程含义是:任何只看一段防御的方案都不完整,必须把跨切面也纳入治理。

二、"Weakly Compositional"——为什么现有防御拼不起来

综述里有一个非常重要的工程性术语:"weakly compositional"。这个术语直译是"弱可组合性",含义是:多个单点防御拼在一起时,防御能力不一定线性增加——有可能出现"防御 A 拦住一类攻击,防御 B 拦住另一类,但合起来依然留有漏洞"的情况。

综述给了几个具体例子。内容过滤器可能拦得住 prompt injection,但对过度授权的 token 完全无效——攻击者不需要让 Agent 说出不该说的话,只需要让 Agent 拿着正确权限的 token 去执行一个工具调用就行。沙箱可能圈住了代码执行,但拦不住一个被授权的 API 调用——Agent 即使在沙箱里,只要它能调出 GitHub API,而那个 API 又有写权限,沙箱形同虚设。审批门可能停掉了某次写操作,但拦不住一条被污染的记忆写入——审批门通常审的是"这次动作要不要执行",不审"这条记忆要不要写"。trace 系统可能让事件可观察,但本身不预防事故——trace 是事后取证工具,不是事前防火墙。

把这些例子放在一起看,综述实际上在讲一个相当硬的事实:Agent 安全的工程化不能依赖"哪个组件最重要",而要看"边界、权限、状态、证据这四件事是否在每一段都被治理"。任何一个段缺一项治理,整套防御就会出现缺口。这与微软责任矩阵里反复强调的"工具层 / 记忆层 / 编排层 / 身份层 / 审计层每一层都有专属责任"的设计逻辑完全对应。

三、5 项关键安全需求 + 5 个工程基线

综述把这些洞察压缩成了一张表,列出 5 项关键安全需求,每项对应一组"自然控制面"(natural control surface)和"重要边界"(important boundary)。

需求 1:Explicit Trust Boundaries(显式的信任边界)。控制面是 Runtime + model/tool/agent 接口层。综述强调,任何不被边界拦截的流量或状态都不受边界保护——这意味着 Agent Harness 不能假设"所有外部调用都走网关",必须主动把每个接口暴露为可审计的边界。

需求 2:Principled Privilege Control(有原则的权限控制)。控制面是 Identity、Access、Credentials、Approvals。综述明确警告:"Approval does not replace standing authorization"——审批门不能替代常态授权机制。一次审批只覆盖那次具体动作,不能扩展到未来任意动作。

需求 3:Provenance-aware State(可溯源的状态)。控制面是 Sessions、Events、Application metadata、Systems of record。综述特别强调:持久化 telemetry 不等于 memory 的可信证明——光记录事件不够,还要能证明"这条记忆来自哪个来源、经过了哪些验证"。

需求 4:Containment(隔离/遏制)。控制面是 Execution environment。综述指出:沙箱不会约束外部授权的工具调用——Agent 在沙箱里跑出来调用一个有权限的 API,沙箱根本拦不住。

需求 5:Runtime Mediation + Deployment-realistic Evidence(运行时中介 + 部署真实的证据)。控制面是 Model/tool 边界 + Runtime & Gateway observability。综述强调:没有任何单一 guardrail 能检测所有攻击家族;同时runtime 事件 + gateway trace 加在一起才是部署真实的证据。

把这 5 项需求映射到企业 Agent Harness 设计,可以提炼出 5 个工程基线:每个外部接口都要有显式边界;权限要按"最小 + 审批不替代"两个维度同时设计;状态写入必须带来源追踪;沙箱必须配合 API 鉴权才有意义;运行时证据 = runtime events + gateway traces 组合,而不是任何单一可观测性工具。

四、与 OWASP Agentic Top 10、Microsoft 责任矩阵的交叉验证

把综述的 247 篇论文框架与 OWASP 2025-12 发布的 Agentic Top 10 对照,会发现两者几乎是同构的——OWASP 的 10 条威胁恰好分布在综述的三个属性和五个段位上。

OWASP ASI01(Goal Hijack)对应综述"信息进入"属性 + Input 段;OWASP ASI02(Tool Misuse)对应"权限动作"属性 + Tool Execution 段;OWASP ASI03(Identity & Privilege Abuse)对应"权限动作"属性 + Identity 子系统;OWASP ASI06(Memory Poisoning)对应"持久状态"属性 + Memory 跨切面。OWASP 的 ASI05(Unexpected Code Execution)和 ASI07(Insecure Inter-Agent Communication)对应综述的"weakly compositional"短板——单一防御挡不住工具调用或跨 Agent 消息的复合攻击。

微软责任矩阵把综述和 OWASP 的"风险视角"转换成"责任归属视角"——它不直接告诉你风险怎么列,而是告诉你在 IaaS/PaaS/SaaS 三种部署模式下,这些风险的归属分别落在哪里。三者加在一起构成了 2026 年下半年 Agent 安全研究的"三视角基线":OWASP 列威胁、综述讲机制、矩阵说责任。任何想在企业内部建立 Agent 安全体系的工作,都不应当只读其中一份文档,而应当把三者并行摆在案头对照读。

五、对企业级 Agent 落地的工程启示

把 247 篇综述 + OWASP ASI 01-10 + 微软责任矩阵 + 几条真实 CVE(EchoLeak、AutoJack、JADEPUFFER、CVE-2025-55319、Agent Message Board、RubyGems 攻击、PromptLock)放在一起,可以提炼出对企业 Agent 落地非常有用的 5 条工程启示。

第一,Agent 安全是一个"系统问题",不是"模型问题"。把防御重点放在"如何训练模型更对齐"上,远远不足以应对综述里列出的复合攻击。真正的工程投入必须放在边界、权限、状态、证据四个维度上,放在跨切面的治理上,放在边界的"组合有效性"上。

第二,设计防御时必须按"组合"来设计,而不是按"单点"来设计。一个沙箱 + 一个审批门 + 一个 trace 系统,如果不主动验证它们在哪些复合场景下会出现缺口,就有可能部署了一套"看起来很完整"的防御但实际漏洞百出。综述提出的"weakly compositional"是这类问题的工程名字;对应的设计原则是:为每一个"防御 A + 防御 B 都不能独立应对"的复合攻击场景,补一个明确的桥接控制。

第三,持久化状态是 Agent 安全与传统 LLM 安全的最大差异。任何把"传统 LLM 安全方案"平移到 Agent 场景的团队,都必须重新设计记忆治理——按用户/租户隔离、内容来源追踪、保留期与删除权落地、记忆存储加密独立审计。这一层如果设计不当,Agent 会在数月之后被一条三年前注入的恶意记忆触发异常行为。

第四,跨切面治理必须有统一的边界模型。Memory、Monitoring、Coordination 三个跨切面不能各自为政——它们必须共享同一种身份/权限/审计语义。例如一段记忆如果在 Monitoring 系统里被标记为"未验证",那么它在 Coordination 系统里就不应该被另一个 Agent 信任;反之,一段记忆如果在 Monitoring 系统里被标记为"经过身份验证的高优先级",那么它应该在 Memory 系统里被赋予更高的保鲜优先级。

第五,真正的安全证据来自 runtime events + gateway traces 的组合。任何只靠单一可观测性工具(无论是 LangSmith 那种 runtime trace 还是 Datadog 那种 gateway trace)的安全体系,都会留下明显的取证缺口。综述把这两种来源并列作为"部署真实的证据",工程含义是:Agent 安全的可观测性必须是 runtime 层和 gateway 层同时在场,缺一不可。

六、从单点防御到系统治理:Agent 安全的范式转移

2022-2026 年的 247 篇论文汇集起来,清晰展现了 Agent 安全研究范式的根本转移:从"模型对齐"转移到"系统治理",从"威胁列表"转移到"系统模型",从"单点防御"转移到"组合防御",从"瞬时攻防"转移到"持久状态攻防"。这次范式转移的背后,是 Agent 本身的工程现实——LLM 安全时代的核心问题是"模型输出是否安全",Agent 时代的核心问题是"系统在面对持续的、多源的、跨任务的攻击时,能否保持边界完整 + 权限收敛 + 状态可信 + 证据可查"。

这条范式转移对任何想在 2026 年下半年落地 Agent 的企业来说都是一个明确信号:不能继续用 LLM 时代的安全思路来设计 Agent 安全。需要重新绘制系统威胁模型,需要重新设计边界、权限、状态、证据四个维度的治理,需要重新评估 OWASP ASI 01-10 与微软责任矩阵在自家部署中的具体落地点,需要重新建立一个"runtime events + gateway traces"双重可观测性的取证体系。这些工作如果不在 Agent 上线之前做完,等到第一次真实 CVE 出现时再来补,代价将是指数级增长的。

Ling 等的 247 篇综述不是 Agent 安全的终点,而是 Agent 安全研究的"第一次系统化盘点"。它告诉所有正在认真落 Agent 的企业:你们面对的不是"prompt injection 这一类问题",而是"一个由三个属性、五段生命周期、三个跨切面、五个安全需求共同构成的系统问题"。理解了这张图,就能开始真正工程化的 Agent 安全建设;没理解这张图,只会不断在单点防御上打补丁,然后在某次复合攻击面前整体失守。