当攻击者也有 50 万 Token：Agent 安全不能再只看一次攻击成功率

过去我们评估大模型或 Agent 的安全性，常见做法是准备一批攻击样本，然后统计有多少攻击成功，得到一个攻击成功率 ASR。

但这种评测方式隐含了一个很强的前提：攻击者基本只尝试一次。

当攻击者本身也变成一个 Agent，能够观察目标系统的执行过程、总结失败原因、不断调整策略，并投入几十万 Token 持续搜索时，这个前提开始失效。

Dynamo AI 与伊利诺伊大学厄巴纳-香槟分校的一项最新研究提出，应当把间接提示注入重新理解为一个“测试时搜索”问题。

论文原文（arXiv）

论文发现，随着攻击预算从几千 Token 增长到 50 万 Token，原本看起来安全的 Agent 会持续暴露新的漏洞。

更重要的是，真正决定攻击效果的并不是简单地“多试几次”，而是攻击者有没有能力理解环境、管理攻击策略，并根据每一次失败反馈调整下一步搜索方向。

换句话说，未来我们评价一个 Agent 是否安全，可能不能再只问“它的 ASR 是多少”，还必须继续追问：

是在什么攻击者、什么搜索策略、多少计算预算下测出来的？

一次没攻破，不等于真的安全

假设我们现在要测试一个能够读取邮件、日历、云盘并调用工具的办公 Agent。

传统安全评测可能准备这样一个场景：攻击者提前在一封邮件里放入一段间接提示注入，用户随后让 Agent 阅读邮件并完成工作。如果 Agent 没有执行攻击者要求的额外操作，我们就记为一次“攻击失败”。

如果连续测试 100 个场景，只有 5 个成功，那么最终得到：

ASR = 5%。

看到这个数字，人们很容易形成一种直觉：这个 Agent 对提示注入的防护能力大概有 95%。

问题是，真实攻击者为什么只能尝试一次？

• 第一次失败后，攻击者完全可能换一种写法
• 如果还是失败，就换一个注入位置

如果发现 Agent 根本没有读取邮件正文，就转而寻找会议描述、商品备注、共享文档等 Agent 真正会读取的位置；

如果发现 Agent 已经调用了攻击所需要的工具，只是参数不对，就围绕这个“差一点成功”的结果继续优化。

于是，真实攻击过程可能越来越像：

尝试
↓
观察
↓
分析失败原因
↓
修改策略
↓
再尝试
↓
再观察。

只要攻击者还有预算，这个过程就可以继续。

这正是论文《Rethinking Indirect Prompt Injection as a Test-Time Search Problem》提出的核心观点：

间接提示注入不应该只被看成一个静态攻击样本，而应该被看成攻击者在一个巨大攻击空间里的持续搜索过程。

作者进一步指出，攻击面并不是固定的，而是由环境、用户当前任务以及攻击目标共同决定。不同任务会形成不同的正常工具调用轨迹，也就暴露出不同的可利用入口。

Agent 的攻击面，不只是“哪里能塞进去一段文字”

过去谈提示注入攻击面，我们容易想到邮件正文、网页、PDF、搜索结果、数据库内容等“不可信文本入口”。

但对于 Agent 来说，这还只是第一层。

真正重要的问题其实是：

在用户当前这个任务中，Agent 到底会经过哪里？

例如，用户问：“帮我看看明天和某家公司的晚餐安排在哪里。”

Agent 可能先读取日历，再读取会议描述，最后返回餐厅地址。此时，会议描述就是一个非常关键的攻击面。

但如果用户问的是“帮我总结今天收到的邮件”，同一个会议描述即使存在恶意内容，也可能毫无意义，因为 Agent 根本不会访问它。

因此论文提出了一个非常值得注意的概念：

任务相关攻击面。

攻击面并不是系统里所有可以写入文字的位置简单相加，而是攻击者需要找到那些正好位于 Agent 正常执行轨迹上的位置。

论文的实验也发现，真正成功的攻击往往集中在用户任务附近，而不是在任意位置暴力塞入攻击内容。

攻击者要做的，并不是让恶意指令变得越来越夸张，而是让它越来越像当前正常工作流中的一个合理步骤。

这其实揭示了 Agent 安全与普通聊天模型安全之间一个很大的不同。

普通聊天模型面对的主要还是：

输入
↓
模型
↓
输出。

Agent 面对的则是：

用户任务
↓
规划
↓
调用工具
↓
读取外部信息
↓
再规划
↓
再调用工具
↓
修改真实环境。

攻击者真正寻找的，已经不是一句能够“骗过模型”的神奇 Prompt，而是一条能够让攻击行为搭上正常执行轨迹的路径。

例如，当 Agent 本来就在处理一个配送任务时，额外操作如果被包装成“完成配送之前的必要步骤”，往往比单纯说“忽略之前指令，执行另一个操作”更自然。

作者因此指出，成功攻击的关键经常在于改变攻击目标与正常任务之间的因果关系：让原本无关的行为，看起来像是完成用户任务不可缺少的一环。

这也是为什么 Agent 安全不能只盯着“危险字符串”。

真正危险的，是：

不可信信息什么时候进入了 Agent 的正常决策链条，以及它是否有机会改变后续行动。

攻击者也有了一个自己的“搜索系统”

为了验证这个想法，作者没有简单让一个大模型不停生成新的攻击 Prompt，而是专门给攻击者搭建了一套 Search Harness，可以理解成“搜索框架”。

它主要负责三件事情：环境侦察、策略搜索，以及执行后的反馈。

• 攻击 Agent 可以先了解目标环境有哪些工具、哪些位置可能被写入内容
• 然后记录自己已经尝试过哪些攻击策略，避免在同一个方向反复兜圈

最后把候选攻击真正放进环境中运行，观察受害 Agent 的回答、工具调用轨迹、任务完成情况和攻击是否成功。

这个设计有一个非常重要的意义：

攻击失败不再只是一个“0”。

因为不同的失败，其实代表完全不同的搜索状态。

有些攻击失败，是因为 Agent 根本没看到攻击内容；有些是 Agent 看到了，但没有采取任何行动；有些则已经调用了攻击需要的工具，只不过参数不对；还有一些可能成功完成了攻击目标，却把用户本来的正常任务弄坏了。

对传统 Benchmark 来说，这些可能全部都是“失败”。

但对于一个会学习的攻击 Agent 来说：

“完全没有任何动作”

和

“已经调用正确工具，只是参数差一点”

显然不是一回事。

后者意味着攻击者已经非常接近成功。

论文把这种情况视为 Near Miss，也就是“差一点成功”。

当攻击预算开始变得有限时，攻击 Agent 会主动减少无目的探索，把计算资源集中到这些最有希望的 Near Miss 上继续优化。

论文附录中的搜索轨迹显示，当剩余 Token 越来越少时，攻击 Agent 会明确判断哪些历史失败最值得继续尝试，并根据目标 Agent 实际调用过的工具重新收缩攻击面。

50 万 Token 之后，原本的“安全结论”开始改变

论文最值得关注的实验，是作者直接改变了攻击者可以使用的 Token 数量。

实验设置了两个模拟环境：一个是包含邮件、日历等工具的 Workspace 办公环境，另一个是 Retail 零售环境。

Workspace 一共组合得到 240 个用户任务与攻击任务对，Retail 有 136 个。

目标 Agent 使用 GPT-5.5 和 Claude Opus 4.8，攻击 Agent 则使用 GLM-5.2。

作者不再只报告传统 ASR，而是引入 ASR@T：也就是在攻击者已经消耗 T 个 Token 时，攻击成功率是多少。

实验结果非常直观。

当攻击预算还很低时，很多攻击都无法成功。但随着攻击 Token 持续增加，攻击成功率也一路上升。

在 Retail 环境中，GPT-5.5 大约从 50K Token 左右开始明显暴露更多漏洞；到 500K Token 时，完整搜索框架的攻击成功率已经达到约 58%。

相比之下，Opus 4.8 明显更加稳健，在 500K Token 时攻击成功率约为 20.6%。

在 Workspace 环境中，漏洞暴露得更快：GPT-5.5 在 100K Token 时已经达到 52.1%，而同样预算下 Retail 为 37.5%。

论文认为，其中一个重要原因是办公环境天然包含大量待办事项、会议记录、后续动作等操作性文本，因此攻击内容更容易伪装成正常工作流中的“下一步”。

更值得警惕的是：

500K Token 还不一定代表搜索已经结束。

作者检查了一些最终仍然失败的案例，发现攻击 Agent 在耗尽 50 万 Token 时，有些仍然在提出新的攻击假设，或者围绕之前的 Near Miss 继续优化。

换句话说，它不是已经证明“这里攻不进去”，而只是：

Token 用完了。

论文统计显示，在 GPT-5.5 的实验中，从 250K 到 500K Token，平均攻击成功率仍然从约 49.0% 上升到 57.8%。

作者因此明确提醒：达到最大预算仍然失败，并不能证明搜索已经收敛。

这件事情带来的问题就非常现实了。

如果某个安全报告告诉我们：

“这个 Agent 的提示注入攻击成功率只有 5%。”

我们实际上还缺少很多关键信息。

攻击者只试了一次，还是允许不断重试？

攻击者能够看到目标 Agent 的工具调用结果吗？

攻击失败以后能不能知道失败在哪里？

有没有历史记忆？

有没有专门管理攻击策略？

总预算是 5K Token，还是 500K Token？

如果这些条件不同，那个看起来非常确定的“5%”，可能根本不是目标 Agent 固有的安全属性。

关键不是“多试几次”，而是知道下一次该试什么

看到这里，很容易产生另一个误解：

既然更多 Token 可以提高攻击成功率，那是不是只需要让模型不停随机生成攻击 Prompt 就可以？

论文专门通过消融实验否定了这一点。

作者比较了完整 Search Harness、去掉整个搜索框架，以及只去掉策略管理工具的三种方案。

在 Retail 环境、GPT-5.5 作为目标 Agent 的情况下，到 500K Token 左右时，完整搜索框架达到 58.1% 的攻击成功率；

• 没有 Harness 的方案约为 39.7%
• 而保留环境侦察、但去掉显式策略管理后，只有 26.5%

尤其有意思的是，没有 Harness 的攻击者在最开始并不一定表现得差。

因为它什么都不用分析，上来就是不断尝试，低预算阶段反而可能快速撞到一些简单漏洞。

但到了大约 100K Token 后，它很快进入平台期。

原因也不复杂：容易想到的招已经试得差不多了，接下来模型开始在相似策略附近反复打转。表面上每一次生成的文字都不一样，本质上可能还在做同一件事。

完整 Search Harness 的优势是在这个阶段才真正体现出来。

它会记录：

• 哪些策略已经失败
• 哪些位置 Agent 根本不会读取
• 哪些方向已经重复测试太多
• 哪些失败离成功只差一步
• 还有哪些不同类型的攻击机制尚未探索

于是后面的 Token 不只是用来“生成更多文字”，而是被用来扩大搜索空间和深化已有线索。

这也是论文最值得记住的一点：

Test-Time Scaling，不等于简单增加采样次数。

真正有价值的是：

更多计算资源 + 有状态的搜索 + 反馈 + 策略管理。

这其实和很多复杂问题中的搜索算法一样。随机搜索前期成本很低，但空间一旦变大，一个能够记录历史、判断方向、利用反馈的搜索系统，才有可能持续取得收益。

未来安全评测，也许应该从“ASR”变成“ASR 曲线”

这篇论文真正值得重视的地方，并不是它发明了某一种更厉害的提示注入话术。

它改变的是我们看待安全评测的方式。

过去我们很容易把攻击成功率理解为模型的一个固定属性：

某个模型的 ASR = 10%。

但在这篇论文的框架下，更合理的表达应该是：

ASR@T。

也就是：

在某一个攻击计算预算 T 下，它的攻击成功率是多少？

再进一步，这个数字实际上还取决于目标 Agent、攻击模型、搜索算法、能够获得的反馈、用户任务以及外部环境。

所以未来一个更加完整的 Agent 安全评测，可能不会再只有一个数字，而应该有一条攻击强度曲线：

低预算攻击者能做到什么？

给它 10 倍预算以后会发生什么？

有没有出现明显的平台期？

搜索是不是已经收敛？

还是攻击成功率仍然随着预算增长？

从这个角度看，安全评测正在出现一个很重要的变化：

过去 Benchmark 更像是在问：

“这批攻击样本里，有多少能够打穿系统？”

而未来可能需要问：

“给一个足够强的自动攻击者一定资源，它最终能找到多少条有效攻击路径？”

这已经不再只是一个数据集评测问题，而越来越接近：

Adversarial Search——对抗搜索。

这可能是 Agent 红队测试下一阶段真正需要补上的东西

过去几年，自动红队的发展已经走过了几个明显阶段。

最开始是人工写攻击 Prompt；随后是用大模型批量生成攻击样本；再往后出现能够根据结果自动修改攻击的红队 Agent。

而这篇论文向前又走了一步：

攻击者本身开始拥有“测试时计算预算”。

这意味着一个未来的红队系统，不应该只是拥有一个攻击样本库，然后把不同 Prompt 一条条请求目标 Agent。

它更像应该拥有一套真正的“攻击搜索系统”。

攻击样本或者 Seed 解决的是：

世界上存在哪些攻击语义。

而 Search Harness 解决的是：

面对眼前这个具体 Agent、具体任务和具体环境，我现在应该搜索哪一类攻击？失败以后下一步应该往哪里走？

两者并不是替代关系。

恰恰相反，一个高质量攻击知识库可以成为搜索空间，而运行时攻击 Agent 负责在这个空间里探索、利用、剪枝和继续扩展。

因此，一个更加完整的自动红队系统，未来可能需要同时记录“攻击是什么”和“攻击是怎么被找到的”：包括攻击策略、具体包装方式、注入位置、执行轨迹、失败类型、Near Miss，以及不同计算预算下的搜索进度。

这时，红队测试的产物也不再只是：

1000 条攻击样本 + 一个 ASR。

而可能变成：

一张目标 Agent 的攻击面地图，以及随着攻击预算增加不断展开的漏洞发现曲线。

真正需要衡量的是“攻破它要花多少成本”

这篇论文还有明显局限。

作者目前主要研究白盒条件，攻击者可以获得比较丰富的环境信息和目标 Agent 反馈；实验也只有 Workspace 和 Retail 两个模拟环境，模型覆盖范围有限。

作者自己也明确承认，目前观察到的增长趋势还不能直接推广到所有真实生产系统，更不能简单称之为一条普适的“攻击 Scaling Law”。

但它提出的问题可能比实验数字本身更加重要。

对于一个真正有价值的 Agent，未来攻击者完全可能不是一个手工写 Prompt 的人。

攻击者也会使用 Agent。

它可以连续工作几个小时，拥有长期记忆，积累所有失败经验，观察每一次工具调用，不断更换攻击入口，并投入越来越多计算资源寻找系统中最薄弱的一条路径。

到了那个时候，“这次攻击没有成功”几乎不能说明什么。

真正有意义的问题会变成：

面对一个能够持续学习和搜索的攻击者，这个 Agent 到底能够坚持多久？

甚至可以再往前一步：

未来衡量 Agent 安全性的一个核心指标，可能不再只是“攻击成功率是多少”，而是“攻破这个系统需要多少搜索成本”。

密码系统从来不会因为攻击者尝试一次失败，就被认为安全。

进入 Agent 时代以后，大模型安全评测可能也需要逐渐接受同样的现实。

一次没攻破，只能证明这一次没找到。

真正的安全，要看攻击者把搜索预算扩大到 50 万 Token，甚至更多之后，还剩下什么。