HarnessRisk：面向 Agent Harness 全生命周期的安全基准

  • 关联论文：2608.17597
  • 作者：Tom
  • 更新：2026-08-19

一句话结论

HarnessRisk 是首个覆盖 Agent Harness 从配置、扩展、运行、状态持久化、动作控制到事件恢复全生命周期六阶段的安全基准；在 128 个沙箱测试用例上，攻击成功率从 12.6% 到 80.9%，Utility 维持在 75.0%–97.6% 之间，揭示了现有安全评估只看单点攻击、忽视多阶段协同失效的根本缺陷。

解决什么真问题

大语言模型（LLM）通过 Agent Harness（工具管理、扩展、持久状态、权限、外部动作）部署到生产环境。然而现有安全基准只评估单点攻击机制（如 prompt injection、tool poisoning），或只覆盖部分运行阶段，无法揭示：

  • 攻击如何在 Harness 的不同职责阶段之间传播和放大
  • 多阶段协同如何让原本"授权范围内"的操作演变为安全失效
  • 为什么某些配置在风险识别率>90% 的情况下攻击成功率仍然很高

换句话说：现有基准缺乏对 Agent 系统全生命周期安全图景的系统性建模。

核心方法

六阶段安全生命周期

HarnessRisk 提出了 Agent Harness 安全的六阶段模型：

  1. Harness Configuration（配置阶段）：攻击者通过修改安全敏感参数（如权限范围、工具白名单）发起攻击
  2. Capability Extension（能力扩展阶段）：通过恶意扩展或插件注入额外能力
  3. Runtime Operation（运行时操作阶段）：在正常运行时触发恶意行为
  4. State Persistence（状态持久化阶段）：通过状态篡改实现持久化攻击
  5. Action Control（动作控制阶段）：操控已授权动作的执行逻辑
  6. Incident Recovery（事件恢复阶段）：利用恢复机制的缺陷扩大影响

基准设计

  • 128 个沙箱测试用例，每个将良性用户目标与嵌入在不可信工作流制品中的对抗指令配对
  • 每个测试轨迹从四个维度评估：Utility（任务完成质量）、Attack Success Rate（攻击成功率）、Persistence（攻击持续性）、Detection（检测率）

测试规模

维度 规模
Harness 数量 3 个
LLM 数量 6 个
模型 + Harness 配置数 14 组
测试用例 128 个沙箱用例

关键实验与数据

关键发现 具体数字
攻击成功率范围 12.6% ~ 80.9%
Utility 范围 75.0% ~ 97.6%
最脆弱阶段 Harness Configuration（所有 Harness）
高检测率陷阱 部分配置检测率 >90% 但攻击成功率仍然很高
⚠️ 攻击成功率中位数 原文未明确

最关键发现——"检测悖论"：某些配置能识别出 >90% 的风险运行，但攻击成功率仍然居高不下。这揭示了显式风险识别不等于安全行动：模型知道风险，但因 harness 层面的授权机制缺陷，仍然执行了危险操作。

⚠️ 数字核验：12.6%–80.9% 范围、75.0%–97.6% Utility 均来自 abstract；具体哪些 harness/LLM 组合对应哪个数字，原文未在摘要中列出。

亮点与局限

亮点： - 首次全生命周期安全评估框架，不是单点攻击测试 - 六阶段模型具有通用性：适用于 ReAct、Toolformer、LangChain Agent 等不同 harness 实现 - "检测悖论"是重要发现：单纯提升风险识别率不足以防御，harness 层面的授权执行机制才是关键 - 128 个沙箱用例全部公开，配合 project page（https://baiyajing.github.io/harness-risk/）

局限： - 仅 3 个 harness，覆盖范围有限；不同架构（centralized vs. decentralized）的脆弱性差异未充分研究 - 攻击成功率 12.6%–80.9% 的范围很大，但具体各阶段的分布数字未在摘要中给出 - 沙箱测试与真实生产环境的差距未讨论（真实环境有更多不可信输入源） - 六阶段中的 Incident Recovery 阶段具体攻击模式，摘要中几乎未涉及

对工程落地的启发

  1. Harness Configuration 是第一道防线：该阶段是最脆弱的入口，意味着安全审计应优先检查配置验证逻辑，而非只关注运行时行为。

  2. 风险识别 ≠ 安全执行：当发现模型在"检测到风险"后仍然执行攻击时，问题不在 LLM 的 safety alignment，而在 harness 的动作授权执行层。需要将风险信号转化为可执行的门控策略。

  3. 持久化攻击（State Persistence）需要特殊关注：一旦攻击者在状态层面站稳脚跟，清除难度远大于单次运行时攻击。需要在状态读写路径上增加完整性校验。

  4. 多 harness 评估是必选项：单一 harness 的安全基准不足以代表整个 Agent 系统；选择 harness 时应参考 HarnessRisk 的多配置评估结果。

  5. Action Control 的边界模糊：已授权动作的执行逻辑被攻击者利用，是一个被低估的向量。工具调用的副作用（文件写入、网络请求）应在 harness 层做最小权限控制。

与同方向工作的关系

  • 此前 Agent 安全评估（如 ReAct 安全性分析、Toolformer 风险研究）均聚焦于单阶段或单向量；HarnessRisk 首次提出横向跨阶段的安全失效传播建模。
  • 与 GPAT（Agent Threat Model）等框架相比，HarnessRisk 提供了具体的可量化基准而非仅威胁枚举。
  • 与传统软件安全中的"攻击链"（kill chain）思想呼应，但针对 LLM Agent 的多阶段协调特性做了定制。
  • ⚠️ 引用关系：论文与哪些现有 Agent 评估工作有直接引用，原文摘要未列出。

适合谁读

  • Agent 系统工程师：选择和评估 harness 安全性，HarnessRisk 是目前最系统的参考基准
  • 安全研究员：理解 Agent 全生命周期攻击面，尤其是 Configuration 和 State Persistence 阶段的防御
  • LLM 安全评估团队：建立内部 Agent 安全红队测试框架，参考其四维评估指标（Utility/ASR/Persistence/Detection）
  • 平台安全产品经理：理解为什么"模型检测到风险"不等于"系统安全"，推动架构层面的安全修复

§0 自检栏： - 机制 N 段：2（六阶段生命周期 / 四维评估指标）+ 1（检测悖论）= 3 段 - 工程 M 段：2（128 沙箱用例设计 / 14 组配置评估） - ⚠️ 数字核验：12.6%–80.9% ASR / 75.0%–97.6% Utility — 来自 abstract - ⚠️ 不确定处：各阶段具体 ASR 分布、自适应攻击检测效果、沙箱→生产环境泛化差距 — 原文未明确

工程落地与核查（Jay）

事实核查摘要

核查项 稿中描述 核查结果 风险等级
3 个 harness / 6 个 LLM / 14 组配置 摘要数字 ⚠️ 摘要未点名具体 harness 名称（是否为 ReAct/Toolformer/LangChain？）；无法独立验证 ⚠️ 中
128 个沙箱用例全部公开 project page: baiyajing.github.io/harness-risk GitHub Pages 域名可信；⚠️ 2026-08-19，距摘要上传仅 1 天，站点内容完整性待查 ⚠️ 低
ASR 范围 12.6%~80.9% 摘要数字 摘要原文；⚠️ 无中位数，无各阶段分布，范围宽泛但无法细化 ⚠️ 中
Utility 范围 75.0%~97.6% 摘要数字 摘要原文；⚠️ 同上，Utility 下限 75% 在安全攻击场景下是否可接受未讨论 ⚠️ 低
最脆弱阶段 = Harness Configuration 实验发现 ⚠️ 摘要原文；具体哪个配置参数最脆弱未点名 ⚠️ 中
「检测悖论」: ASR >90% 但攻击成功率仍高 核心发现 摘要原文；⚠️ 「部分配置」指哪些 harness/LLM 组合未说明 ⚠️ 中
攻击成功率 80.9% 上限 摘要数字 ⚠️ 高 ASR 是否为同一配置下的不同 case 或不同配置未说明 ⚠️ 中

可落地工程检查清单

六阶段威胁建模工作流（参考 HarnessRisk 框架）

以下 checklist 供团队对现有 Agent 系统做自审：

阶段 1: Harness Configuration
  [ ] 工具白名单是否在配置层验证而非运行时验证？
  [ ] 权限范围修改是否需要显式审批（不能由 LLM 自主扩大）？
  [ ] 配置变更是否写审计日志（谁/何时/改了什么）？
  [ ] 默认 deny 原则：未明确授权的工具调用一律拒绝

阶段 2: Capability Extension
  [ ] 扩展/插件安装是否有签名验证（不能加载未签名插件）？
  [ ] 扩展权限是否独立于主 harness（插件不能自动获得主系统权限）？
  [ ] 扩展的 API 调用是否经过 harness 的中央路由（不走旁路）？

阶段 3: Runtime Operation
  [ ] LLM 输出在执行前是否经过 harness 的动作审批层？
  [ ] 高风险动作（文件写入/网络请求/数据库写入）是否有二次确认？
  [ ] 每个 tool call 是否记录完整调用链（prompt / LLM 输出 / 执行结果）？

阶段 4: State Persistence
  [ ] Agent 状态（memory / context / learned preferences）是否防篡改？
  [ ] 状态恢复（resume from checkpoint）是否有完整性校验（HMAC 或签名）？
  [ ] 恶意状态注入后，是否有机制检测「行为漂移」（与 baseline 行为异常偏离）？

阶段 5: Action Control
  [ ] 工具调用的副作用是否在 harness 层做最小权限控制（不能超出原始授权范围）？
  [ ] 并发调用是否有竞态条件漏洞？
  [ ] 长时间运行的 action 是否可超时中断？

阶段 6: Incident Recovery
  [ ] 攻击后是否有干净的状态回滚机制（恢复到已知良好状态）？
  [ ] 恢复过程本身是否可被攻击利用（恢复 = 新的攻击面）？
  [ ] 是否有事后审计（post-incident review）记录恢复步骤？

「检测悖论」工程含义与对策

"检测悖论"（检测率 >90% 但 ASR 仍然高）是 HarnessRisk 最有工程价值的新发现。它的含义是：模型/系统知道风险但仍然执行了危险动作。这不是 safety alignment 问题，而是 harness 的授权执行层缺失。

具体工程对策：

# 风险信号 → 可执行门控（非可选，是必须）
class HarnessActionGate:
    def __init__(self, risk_detector, allowed_tools: set):
        self.risk_detector = risk_detector  # 输出 risk_score ∈ [0, 1]
        self.allowed_tools = allowed_tools

    def should_execute(self, tool_name: str, risk_score: float) -> tuple[bool, str]:
        if tool_name not in self.allowed_tools:
            return False, f"Tool {tool_name} not in allowlist"

        # 关键：risk_score 高 ≠ 模型"知道就能防"
        # 必须有独立的执行门控，不能依赖 LLM 自主拒绝
        if risk_score > 0.7:
            return False, f"High risk score {risk_score:.2f} — blocked by gate"
        if risk_score > 0.3:
            # 中风险：降权执行 + 告警
            return True, f"Medium risk {risk_score:.2f} — executed with monitoring"
        return True, "Low risk — normal execution"

⚠️ 工程坑点

  1. 六阶段覆盖度决定安全上限：大多数内部 Agent 系统只覆盖阶段 3（Runtime）的一小部分安全控制，阶段 1（Configuration）和阶段 4（State Persistence）往往是盲区。HarnessRisk 的贡献是把六阶段全部显式建模——补齐的边际成本远低于新发现一个零日。
  2. 检测悖论意味着 LLM-level safety filter 不够：不能依赖「LLM 知道这是危险的所以不会执行」——必须加 harness 层的机器可执行门控（强制执行 deny/gate 而非 LLM 自主决策）。
  3. 沙箱 vs 生产环境差距：128 个沙箱用例在可控环境中运行，生产环境有更多不可信输入（用户提供的文件、第三方 API 响应、不可控的工具输出）。沙箱 ASR 范围（12.6%~80.9%）是乐观估计，生产环境实际 ASR 可能更高。
  4. Utility 下限 75% 意味着什么：在遭受攻击时，Agent 仍能维持 75% 的任务完成质量。这对任务关键型 Agent（代码生成、科学研究）可能不可接受——75% 意味着每 4 个任务中有 1 个被攻击破坏或性能严重下降。
  5. Harness 选型：若 project page 确认 3 个 harness 包含 LangChain Agent，则大量现有 LangChain 部署已经受到 HarnessRisk 覆盖。建议：立即用 HarnessRisk 的四维指标（ASR/Persistence/Detection/Utility）跑一遍自家 Agent 系统基线。

结论：当前阶段值不值得跟？

  • ✅ 现在可做：六阶段自审 checklist今天可用，不需要等论文代码；重点检查阶段 1（Configuration）和阶段 4（State Persistence），这两个阶段摘要显示最脆弱且最容易被内部系统忽略
  • ✅ 值得关注：project page（baiyajing.github.io/harness-risk）已上线，等站点内容填充后可以下载 128 个沙箱用例，跑在自己 Agent 上做内部红队测试
  • 🔁 等正文：各阶段具体 ASR 分布、「检测悖论」的具体触发条件（哪些 harness/LLM 组合在 90% 检测率下仍然高 ASR）——这些数字是决定安全修复优先级排序的关键输入
  • ❌ 当前不宜：以 HarnessRisk 数字作为最终安全结论——样本量仅 128 个沙箱用例 + 3 个 harness，且沙箱与生产环境存在系统差距