AI Agent安全为何失效？四大失败路径深度解析

AI Agent正在快速进入企业系统，但安全防护却远远跟不上。Token Security的Kayla Williams在一期技术分享中，系统性地拆解了AI Agent安全失效的根因。她的核心观点是：不要把安全失败简单归咎于缺少控制手段。在概率性系统面前，即使最强的控制也会在足够大的规模下失效。

核心公式：Agent风险 = 失败概率 × Agent可达范围

这个公式是整个分析的基石。一个能拦截99.9%恶意请求的提示注入过滤器听起来很强，但当天请求量达到10,000次时，仍有10次会穿透。此时Agent会做什么，完全取决于它的可达范围。

控制手段降低的是失败概率，而访问控制限制的是可达范围。两者缺一不可。这个逻辑在传统安全领域并不新鲜，但当Agent具备自主决策和多步执行能力时，可达范围的量级会急剧膨胀，风险敞口随之失控。

Context is crucial when you judge intent, which probabilistic controls need to do.

动作链：控制的布防点在哪里？

Williams将Agent的执行过程拆解为一条清晰的动作链：

用户给出指令
系统围绕指令组装上下文
模型形成计划并选择工具
执行动作并使用凭证
生成操作记录

每个环节都可以部署控制：提示过滤器、来源标签、工具允许列表、权限范围、网关和日志。但问题在于，某些失败并不发生在某一步之内，而是发生在步骤之间——通常是因为上下文丢失了。

上下文为什么决定成败

判断意图需要上下文，而概率性控制的核心任务恰恰就是判断意图。异常本身也是上下文相关的：其他系统对Agent行为的上下文了解越多，误判率就越低。但它永远不会是零。

这就是为什么某些环节必须使用确定性控制：工具不在目录里？不能用。Token没有携带权限范围？不能用。这里没有判断的余地。

在实际的Agent场景中，确定性和概率性控制需要协同工作。一个降低Agent被攻陷或失控的次数，另一个设定风险上限。

提示注入（Prompt Injection） 是理解本文的关键背景。它指攻击者通过精心构造的输入（用户输入、网页内容、文档、工具返回值等）嵌入恶意指令，劫持大模型的执行方向。与传统SQL注入不同，提示注入没有可靠的"转义"机制——因为自然语言中指令和数据本质上是同一种载体，模型无法在架构层面区分"这是要执行的内容"与"这是要参考的内容"。常见变体包括直接注入（用户直接下指令）和间接注入（污染Agent读取的外部数据源）。防御手段主要依赖分类器、指令层级、来源标签等，但它们无一例外都是概率性的：模型可能被新颖的措辞绕过，分类器可能误判合法输入。这正是文章强调"结构性不对称"的技术根源——防御者面对的是一个开放的、可无限生成的攻击面。

四条失败路径

Williams将真正的安全失败——既包括穿透了主动防御的攻击，也包括完全绕开防御的攻击——归纳为四条路径。

路径一：设计正确但覆盖不足

系统完全按设计运行，但设计本身的覆盖范围不够。提示过滤是典型案例。问题不仅是它们的概率性本质，还存在一种结构性不对称：攻击者有目标可以反复探测，没有内置时间约束；而防御方必须考虑合法提示的延迟。即使一切完美运行，防御方也处于劣势。

工具允许列表同理——它可能是确定性的，但覆盖范围是预定义的。有人偷偷装了一个自己的MCP服务器？不在覆盖范围内。有人修改了允许工具的description来污染指令？也不在覆盖范围内。

路径二：度量了错误的东西

基线设置不当是典型问题。如果你对10个承担不同任务的Agent只设一个速率限制，或者逐个调用判定器，必然漏掉可疑的Agent行为流。

使用权限做基线也帮不上忙，因为一个失控的Agent永远在它的授权范围内行事。

as a rogue agent is always within its grant.

在所有情况下，缺乏上下文是度量不完整的根本原因。

路径三：不知道Agent的存在

这是最常见的失败路径。如果你不知道Agent的存在，就看不到它持有了不该持有的凭证——比如一个服务账号、一个未经审批的内置工具带来的权限、或者一个范围过宽的OAuth授权。

凭证管理的问题尤其突出：Agent被删除了，但它使用的OAuth授权往往仍然存活，因为供应流程绕过了身份提供者。

Third, a control can be bypassed because it doesn't know about the agent.

服务账号（Service Account） 与 OAuth scope 是这一路径的两个核心概念。服务账号是非人类身份的机器账户，通常被授予长期有效的密钥，用于服务间调用；问题在于它往往权限过大、轮换困难、且不绑定具体人员，一旦被Agent获取，攻击者就获得了一个没有MFA、没有行为基线、可长期潜伏的"幽灵身份"。OAuth scope则定义了访问令牌能做什么，理想情况应遵循最小权限原则，但实践中许多API的scope粒度是按整个系统（如"读取全部邮件"）而非按具体任务（如"读取某封邮件"）设计的，导致Agent不得不申请超宽权限。再加上Agent的供应流程常绕过身份提供者（IdP），导致Agent被删除后授权令牌依然存活，形成"孤儿凭证"，这是审计中最容易被忽视的盲区。

路径四：人为因素

理想情况下，每个不可逆操作都应该有人工审核。但这根本不可扩展。如果一个审批关口每天触发30次，用不了多久所有请求都会被橡皮图章式地放行。

凭证：唯一与上下文无关的变量

Agent接受指令后，追溯指令来源和每个动作背后的真实操作者往往是不可能的。在这种上下文缺失的困境中，凭证是唯一与上下文无关的要素——它要么允许访问，要么不允许。

and who the true actor is behind every action.

凭证本身不属于Agent，而属于Agent访问的那些系统。当Agent出问题时，凭证最终决定了损害能蔓延多远。

但凭证也是双刃剑。如果目标系统只提供管理员级别的API访问，你就被迫做全有或全无的决定。OAuth scope需要针对系统而非任务来定制，因此往往不得不设置得很宽。加上目前还没有公认的委托标准，构建"按请求者而非按工具"来限定范围的凭证非常复杂。

委托（Delegation）标准 的缺失是精细授权难以落地的制度性原因。在人类用户的场景下，OAuth 2.0 提供了授权码、PKCE、Token Exchange（RFC 8693）等机制来表达"用户A授权应用B代表自己访问资源C"，但针对Agent的委托链——即"用户授权Agent调用工具、工具再调用下游服务"——目前缺乏公认的端到端标准。结果就是每一跳都容易丢失原始操作者身份，最终下游系统只看到一个宽泛的服务身份。业界正在探索的方向包括：以用户身份传递（On-Behalf-Of）令牌、可验证凭证（VC）、以及针对Agent的专门身份框架。在这些标准成熟之前，团队只能用短期令牌、请求级审计、凭证代理等手段作为过渡方案，但都无法根治"按系统而非按任务"授权带来的过宽问题。

务实的行动建议

Williams给出的结论并不复杂：审视你的系统，追问概率性和确定性控制各自的覆盖边界，思考它们在规模扩大后如何表现，然后开始填补缺口。

没有简单的解决方案，但不行动绝对不是选项。对于正在部署AI Agent的团队来说，这四条失败路径提供了一个实用的审计框架——不是问"我有没有控制"，而是问"我的控制在哪条路径上会失效"。