TRACESAFE-BENCH：Agent执行过程的安全性评测框架

很多团队在做 Agent 安全时，关注点还停留在两端：用户输入有没有问题，模型最终回复合不合规。但今天介绍的这篇论文盯住的是中间那一段更危险的链路：Agent 在执行任务时，一步一步发出的工具调用轨迹，能不能被护栏及时识别并拦住。

论文地址：https://arxiv.org/pdf/2604.07223

论文把这个问题做成了一个专门的基准 TRACESAFE-BENCH，并明确提出：在多步工具调用场景里，传统只看文本表面的安全护栏，已经不够了。

Agent 的风险，很多时候发生在中间过程

论文开篇就点得很直接：在 Agent 工作流里，真正危险的地方，常常不是最终那句回复，而是中途某一次工具调用。

比如，模型把不该传出的敏感信息塞进参数里，把外部返回内容里的恶意指令当成后续行动依据，或者在接口理解上出现幻觉，调用了不该调用的工具。

现有不少防护方案更擅长处理越狱、违规文本和最终输出，但对这种多步、结构化、执行中的风险覆盖还不够；论文还专门提到，已有工作如 MCP-Guard 更偏单步、调用后检测，难以覆盖”调用前拦截”这个关键位置。

这也是这篇论文最有价值的地方：它把 Agent 安全的重点，从”模型说了什么”往前推了一步，推到了”模型正准备做什么”。对于真实业务来说，这个切点更接近事故发生的位置。等危险工具调用已经打到服务端，再做判断，很多时候就晚了。

Agent 轨迹安全基准

TRACESAFE-BENCH 不是让模型随便生成一堆”看起来像攻击”的例子，而是从 BFCL 的多步函数调用任务里挑出执行完全正确的良性轨迹，作为干净种子；这些种子来自 5 个不同模型，并且只保留 100% 执行正确的轨迹。

然后，作者用一套 Check + Mutate 机制，把原本正常的执行过程，精确改造成某一步出现风险的变体。

• Check 先判断某个风险能不能合理注入到这一步
• Mutate 再用预定义代码逻辑去改工具描述、工具列表、用户请求、参数或返回结果

这样做的好处是，风险点是明确、可定位、可复现的，不是模糊的一坨”整体不安全”。

最终，论文构造出一个 1170 条的静态轨迹数据集。12 个细分风险类别每类 90 条，再加上 benign 负类，一共形成一个较平衡的评测集；作者还额外对每个类别抽样 10 条，联合专业网络安全公司做了人工审计。

这个规模未必算特别大，但它的重点不在”量”，而在每一步风险标注足够准，足够贴近真实工具调用现场。

12 类中途执行风险

这篇论文的风险设计很有参考价值。它把问题分成四个大域：提示注入、隐私泄露、幻觉、接口不一致。

再往下细分，就是 12 个更贴工程现场的类别：

作者甚至还把这些类别整理成适合云上护栏配置的自然语言规则，说明这套分类并不只是学术归纳，也具备一定落地价值。

这里最值得注意的一点是：这 12 类风险里，有些是明显攻击（提示注入、敏感信息外泄）；但也有不少属于”系统工程里的灰色错误”，比如接口版本冲突、函数描述写错、类型提示缺失。

论文其实在提醒我们，Agent 安全并不只等于防攻击，它还包括防止模型在复杂工具环境里做出危险的错误动作。

实验结论

一、简单的”安全 / 不安全”二分类效果并不好

论文评测了 13 个通用模型和 7 个专用护栏，设置了四种任务：不给风险定义的二分类、给风险定义的二分类、粗粒度多分类、细粒度多分类。

结果发现，在二分类场景里，通用模型和专用护栏会出现很强的相反偏置：通用模型更容易”看什么都危险”，专用护栏则更容易”把很多风险当成没事”。这说明面对工具调用轨迹，直接问一句”这安全吗”，现在还不是一个稳定做法。

二、只要把风险分类讲清楚，检测效果会明显变好

在粗粒度多分类设置下，模型需要判断它到底属于提示注入、隐私泄露、幻觉、接口不一致，还是 benign。到了这个层级，很多模型的表现明显更稳，其中 Qwen3-14B 的整体准确率达到 83.58%。

这说明 Agent 护栏不能只靠一个模糊阈值，还需要一套清晰的风险框架来帮助模型定位异常。

三、模型更擅长抓”结构上很显眼的坏事”，不擅长抓”接口层面的小错”

论文发现，显式风险类别（提示注入输出、几类敏感信息泄露、虚构工具、额外参数）整体更容易识别；但接口不一致这一类的表现明显差很多。以 Qwen3-14B 为例，在第 12 类”函数描述不匹配”上只有 4.71%。

这很符合很多工程团队的实际感受：真正容易漏掉的，往往不是赤裸裸的恶意指令，而是那些看起来像正常系统噪声、实际上已经偏离语义的执行错误。

四、Agent 护栏的瓶颈，更像”结构理解能力”，而不是安全对齐能力

论文把 TRACESAFE 的成绩与 5 类能力做相关性分析后发现：

• 与 RAGTruth Data2txt 这类结构化幻觉检测任务相关性最高（ρ≈0.79/0.80）
• 与 LiveCodeBench 这类代码与结构解析能力也有较强相关（ρ≈0.63）
• 但与 StrongREJECT 这种越狱鲁棒性指标几乎没什么相关（ρ≈0.05）

作者据此提出一个很关键的判断：在工具调用轨迹里，模型得先把嵌套 JSON、工具 schema、参数关系读明白，后面才谈得上判断风险。

五、轨迹更长，反而可能更容易看出问题

随着轨迹长度和步骤数增加，检测准确率并没有明显下滑，反而在更长轨迹上还有上升趋势。作者给出的解释是：短轨迹里，模型更多在看静态工具定义；轨迹拉长以后，动态行为信号——模型动作和环境反馈——占比更高，异常会更容易暴露。

这一点很值得做 Agent 运行时监控的团队重视：长上下文本身未必是最大问题，缺少行为视角才是。

三点启发

第一，护栏部署位置要前移。 真正关键的拦截点，是每次工具调用发出去之前。输入端和输出端当然还要保留，但如果没有中途执行监控，很多风险其实已经穿过去了。

第二，护栏能力要升级。 未来的 Agent 护栏，不能只是”违规文本分类器”，它还得像一个懂接口、懂参数、懂 schema、懂调用关系的”结构化审计员”。论文的结果已经很清楚：这类任务更依赖结构理解，而不是单纯的安全对齐。

第三，评测方法也该升级。 如果今天还只拿最终输出做安全评测，很容易高估系统安全性。论文在混淆分析里发现，很多检测失败并不是把某类风险误判成另一类风险，而是干脆把风险当成 benign——像虚构参数值、版本冲突这种执行级错误，被误判为 benign 的比例分别达到 67.6% 和 55.9%。只看结果，很可能看不见真正危险的中间过程。