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

在探讨AI Agent安全时，许多团队的关注点仍集中在两端：用户输入的合规性与模型最终输出的安全性。这固然重要，但今天我们将聚焦于一篇前沿研究，它将视线投向了一条更为隐蔽且高风险的地带——Agent在执行多步任务过程中，其逐步发出的工具调用轨迹，能否被安全护栏有效识别并实时拦截。

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

该研究提出了一个专门的评测基准——TRACESAFE-BENCH，并明确指出一个核心结论：在涉及多步工具调用的复杂场景中，传统仅针对文本表面进行监控的安全护栏机制已显不足。

Agent 的风险往往潜藏于执行过程之中

论文开宗明义地指出：在AI Agent的工作流中，真正的安全威胁常常并非源于最终回复，而是潜伏于某一次不经意的中间工具调用环节。

例如，模型可能将本应保密的敏感信息嵌入API调用参数中传出，或错误地将外部返回内容里夹带的恶意指令作为后续行动依据。又或者，模型在理解接口时产生“幻觉”，错误调用了本不该使用的工具。

当前许多防护方案更擅长处理越狱攻击、违规文本及最终输出审查。但对于这种多步骤、结构化、发生于执行链条中间过程的风险，其覆盖与防御能力存在显著缺口。研究特别提及，像MCP-Guard这类现有工作，更侧重于单次调用后的检测，难以实现在“调用发生前进行拦截”这一更为关键的安全节点布防。

这正是本项研究的核心价值所在：它将Agent安全的焦点，从“模型最终说了什么”向前推进至“模型正准备做什么”。对于实际业务部署而言，这一视角更接近安全风险发生的源头。若等到危险的工具调用请求已抵达服务端再行判断，往往为时已晚。

Agent轨迹安全基准：TRACESAFE-BENCH

TRACESAFE-BENCH的构建思路颇具巧思。它并非让模型随意生成看似攻击的样例，而是从BFCL基准的多步函数调用任务中，筛选出完全正确执行的良性轨迹作为“种子”。这些种子来源于5个不同模型，且仅保留100%执行正确的轨迹。

随后，研究者采用一套“检查（Check）+ 变异（Mutate）”的机制，将原本正常的执行过程，精准改造为在特定步骤植入风险的变体轨迹。

“检查”步骤首先评估特定风险能否合理注入当前步骤；“变异”步骤则依据预定义的代码逻辑，对工具描述、工具列表、用户请求、参数或返回结果进行修改。这种方法确保了风险点的明确性、可定位性与可复现性，而非模糊的“整体不安全”状态。

最终，论文构建了一个包含1170条静态轨迹的数据集。12个细分的风险类别每类包含90条样本，再加上良性负类样本，形成了一个均衡的评测集合。作者还额外从每个类别中抽样10条，联合专业网络安全公司进行了人工审计验证。

该数据集的规模或许并非其最大亮点，其核心价值在于每一步的风险标注都足够精准，高度贴近真实的工具调用现场。

12类执行过程中的风险

本研究对风险的分类体系极具参考价值。它将问题划分为四大领域：提示注入、隐私泄露、幻觉、接口不一致。

进一步细分，则得到12个更贴近工程实践的具体风险类别：工具描述投毒、工具输出投毒、用户信息泄露、API密钥泄露、内部数据泄露、参数名或格式歧义、虚构工具、虚构参数值、额外虚构参数、缺失类型提示、版本冲突、函数描述与真实功能不一致。

作者甚至将这些类别整理成了适合云端护栏配置的自然语言规则，这表明该分类体系不仅具有学术归纳意义，也具备显著的工程落地价值。

这里尤其值得注意的是：在这12类风险中，部分属于明显的恶意攻击行为，如提示注入和敏感信息外泄；但也有不少属于“系统工程中的灰色错误”，例如接口版本冲突、函数描述错误、类型提示缺失等。

论文实质上提醒我们，Agent安全不仅关乎防御外部攻击，同样包括防止模型在复杂的工具环境中做出危险性的错误动作。

实验结论与核心发现

结论一：简单的“安全/不安全”二分类方法，效果并不理想。

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

结果表明，在二分类场景下，通用模型与专用护栏表现出截然相反的倾向：通用模型更容易“误判一切为危险”，而专用护栏则更容易“将许多风险误判为安全”。这说明，面对工具调用轨迹，直接询问“这安全吗”并非一种稳定的检测策略。

结论二：清晰的风险分类框架能显著提升检测效果。

在粗粒度多分类设置下，模型需要判断轨迹究竟属于提示注入、隐私泄露、幻觉、接口不一致中的哪一类，或是良性轨迹。在此层级上，许多模型的表现明显更为稳健，其中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安全护栏，不应只是一个简单的“违规文本分类器”。它必须进化成为一个精通接口规范、理解参数语义、熟悉模式定义、洞察调用关系的“结构化审计员”。论文结果清晰地表明：此类任务更依赖于模型的结构化理解与分析能力，而非单纯的安全对齐能力。

第三，安全评测方法也需要同步升级。如果现今仍仅以模型的最终输出来评估安全性，极易高估整个系统的安全水平。论文在混淆分析中发现，许多检测失败案例并非将某类风险误判为另一类，而是直接将风险样本误判为良性。例如，“虚构参数值”、“版本冲突”这类执行级错误，被误判为良性的比例分别高达67.6%和55.9%。这警示我们，仅关注最终结果，很可能无法洞察真正危险的中间过程。