论文

StepGuard: 可扩展监督与安全-效用平衡下的步骤级护栏学习

StepGuard: 可扩展监督与安全-效用平衡下的步骤级护栏学习

基于LLM的智能体可通过工具调用与外部环境交互,但这也会带来安全风险,例如文件修改、信息泄露和未经授权的操作。现有护栏通常评估已完成的轨迹,对步骤级动作的执行前监控研究不足。 我们提出 StepGuard ,一种步骤级护栏模型,既能审计已完成的智能体轨迹,也能在工具动作执行前进行检查。为训练 StepGuard ,我们引入 StepGen ,一个自动数据引擎,可在相同上下文但风险步骤动作不同的情况下生成安全与不安全轨迹。为进一步减少过度防御与防御不足,我们提出 Balance-GRPO ,基于观测准确率动态平衡安全和不安全动作的学习。 实验表明,StepGuard 在开放权重护栏模型中取得最高平均准确率,性能可与 GPT-5.4 媲美。用于保护 AgentDojo 和 AgentDyn 上的智能体时,StepGuard 将平均攻击成功率相对无护栏设置降低 77.3% ,而平均效用仅下降 2.8个百分点。

论文精读

TL;DR StepGuard 在代理执行每个工具动作前进行步骤级安全检查,通过自动生成同上下文对比轨迹与平衡强化学习,守护 AgentDojo/AgentDyn 时攻击成功率降 77.3% 而效用仅损 2.8 个百分点,性能媲美 GPT-5.4。

问题

问题背景:LLM-based agents 通过工具调用与外部环境交互,带来文件修改、信息泄露、未授权操作等安全风险。业界对 agent 安全护栏的关注正从离线评估转向运行时防护。

现有方法局限:现有 guardrails 主要在轨迹完成后做离线审计(如 R-Judge 等 trajectory-level evaluators),无法在动作执行前阻断危险调用;开源 guard 模型往往依赖人工标注或简单合成数据,缺乏成对上下文一致的安全 / 不安全动作对比样本,导致过防御(误杀正常工具调用)或欠防御(漏检恶意行为)。轨迹级判断也无法定位具体风险步骤,难以用于预执行拦截。

为什么难 / 重要:step-level 监控需要在每个工具调用前快速判定安全性,对模型精度与延迟都敏感;同时必须平衡安全性与 utility,否则过度拦截会显著降低 agent 的任务完成率。构建高质量 step-level 监督数据也困难:需要同一上下文下语义等价但安全/不安全分支,人工标注成本高,自动生成需保证分布对齐,避免数据泄漏或基准污染。

行业类比:类似自动驾驶的实时碰撞预警系统,必须在每个控制指令执行前判断风险,而非仅事后分析行车记录。

核心洞察

  • StepGuard 将 agent 安全防护从轨迹后评估前移到步骤级执行前审计,填补 pre-execution monitoring 的关键空白。现有多数 open-weight guard 模型只对完整 trajectory 做安全判断,无法阻止已发生的恶意工具调用。StepGuard 在每个 tool action 执行前检查其安全性,可在风险落地前拦截,这一范式转变使防护粒度从事后追溯变为事前阻断,大幅降低攻击成功概率。
  • StepGen 提出 prefix-aligned contrastive branching,在相同上下文下仅改变风险步骤的 action 来生成 safe/unsafe 轨迹对,显著提升监督信号质量。与传统 synthetic data 生成不同,它保证轨迹前缀完全一致,让模型专注于学习动作本身的风险差异,避免因上下文变化引入混淆因素。这种对比构造使 StepGuard 能更精准地区分安全与不安全行为,减少误报与漏报。
  • Balance-GRPO 在强化学习阶段动态平衡安全与效用目标,根据模型在安全/不安全动作上的实时准确率调整学习权重,减轻 over-defense 与 under-defense。相比于固定权重或静态安全-效用折中策略,该方法能适应训练动态,当模型对安全动作过度敏感时降低安全侧惩罚,反之加强对危险动作的识别,从而在守护 agent 时实现攻击成功率大幅下降的同时,仅损失极少量 utility。

方法

输入与输出

StepGuard 接收 代理轨迹前缀(历史观测、已执行动作及工具返回)和当前拟执行的 tool action(函数名与参数),输出该动作的安全判定(safe / unsafe)及可选理由。部署时可在执行前拦截危险调用,事后也可审计已完成轨迹。

关键模块

  • StepGen 数据引擎:采用 风险锚定轨迹构建 先规划并执行一条包含风险步骤的危险轨迹,通过 前缀对齐的对比分支 在风险步骤前保持完全相同的上下文,仅改变 risk step 处的 action,生成安全与不安全两个分支轨迹。随后进行步骤级标注和 质量控制(如五字段理由模式),产出成对的监督数据。
  • 冷启动 SFT:利用 StepGen 生成的 pairs 进行监督微调,让模型具备基础的步骤安全判断能力。
  • Balance-GRPO:在 SFT 基础上,通过强化学习动态平衡安全与效用。核心是根据模型当前对 safe/unsafe 动作的观察准确率自适应调整两类样本的优化权重,抑制 over-defense 和 under-defense。该方法在 GRPO 框架上引入平衡感知的优化目标,而非简单加权。

与同类差异

与主流仅评估完整轨迹的 guardrail(如 R-Judge、TS-Bench)不同,StepGuard 首次在步骤级预执行审计上引入前缀对齐的对比数据生成与平衡强化学习,使攻击拦截更前置、效用损失更低。

实验

实验设计

StepGuard 在两类评估中验证:静态护栏评估(多个基准,如 ATBench、ASSE-Bench、R-Judge、TS-Bench)与受保护智能体评估(AgentDojo、AgentDyn)。训练数据由 StepGen 自动生成,包含相同上下文但不同动作的安全/不安全轨迹;优化采用 Balance-GRPO 动态平衡安全与效用学习。

关键发现

  • 静态评估中,StepGuard 在开源护栏模型中取得最高平均准确率,性能与 GPT-5.4 相当。
  • 在 AgentDojo 和 AgentDyn 上,相对无防护设置,StepGuard 使平均攻击成功率降低 77.3%,而平均效用仅下降 2.8 个百分点。

与基线对比

相比其他开源护栏模型,StepGuard 在准确率与安全-效用平衡上优势明显;相比无防护,攻击成功率大幅下降而效用损失极小,证明 step-level 预执行审计能有效拦截恶意动作而不误伤正常行为。

行业影响

落地场景

StepGuard 作为 step-level guard model,适用于任何需要 LLM agent 调用外部工具的自动化系统。典型场景包括:

  • 企业服务与 RPA:财务机器人自动处理发票、修改 ERP 记录时,StepGuard 在 write_file、update_db 等动作执行前拦截越权或误操作,防止错误报销或数据篡改。
  • 电商智能客服:客服 agent 处理退款、订单修改等敏感操作,StepGuard 可以检测用户诱导的恶意意图(如 prompt injection),只允许符合策略的动作通过。

商业价值

  • 安全与合规降本:将攻击成功率降低 77.3%(相对无 guard),大幅减少安全事件导致的直接损失、法律风险与品牌声誉损害。
  • 人力审核成本下降:传统 trajectory-level 审核往往事后发现,StepGuard 的 pre-execution 检查可将人工复核前移且自动化,减少人工介入频次。
  • 模型选择灵活:作为 open-weight 模型,性能与 GPT-5.4 相当,可私有部署避免数据泄露给第三方 API,同时节省 API 调用成本。

与现有工作流集成

StepGuard 可作为轻量级中间件嵌入当前 agent 框架:

  • 在 LangChain / AutoGen 等框架的 tool executor 之前增加一个 guard 检查节点,调用 StepGuard 的 inference API 或本地模型。
  • 输出结构化判定(safe/unsafe + 风险标签),便于日志审计与合规留痕。
  • 支持 step-level prompt(对单个 action 判断)和 trajectory-level prompt(对整个轨迹审计),可灵活适配不同监控粒度。

原论文指出 StepGuard 的效用损失仅 2.8 个百分点,这意味着部署后几乎不影响任务完成质量,工程上易于接受。

局限

  • StepGen 自动数据引擎依赖预定义的风险模板和工具集,生成的轨迹与真实攻击存在分布差异。对于复杂、隐式或组合式恶意意图,模型可能缺乏足够覆盖,导致在未见场景中泛化不足。静态评估虽高,但动态环境如 AgentHarm 表现下降,表明数据多样性仍有限。
  • Balance-GRPO 通过观测精度动态平衡安全与效用,但缺乏理论收敛保证,在安全-效用冲突剧烈的场景下可能偏向保守或激进。RL 训练本身的不稳定性和超参数敏感性论文未深入分析,可能影响复现与部署稳定性。
  • 部署成本方面,StepGuard 作为前置 check 模型增加推理延迟与资源占用,对高并发或实时性要求高的系统可能成为瓶颈。与不同 agent 框架集成需适配工具 schema 和状态表示,通用性受限,且目前开源生态尚不成熟(GitHub stars 较低)。
论文Zhijie Zheng2026-08-25原文

相关内容