Action-Graded Severity Scale for Tool-Using AI Agents
Action-Graded Severity Scale for Tool-Using AI Agents
一句话结论
这篇论文把 agent red-teaming 从“攻击是否成功”的二值指标，推进到“agent 实际执行了多坏的动作”的轨迹级严重度量表：L0-L6 按可逆性、跨 scope、扩权和 escalation chain 评分。
为什么对用户重要
对 Hermes / llm-wiki 来说，cron、wiki 入库、代码修改、发布和浏览器自动化都不是只有成功/失败两种结果。一个任务即使没有完全被 prompt injection 接管，也可能发生低级别但真实的越界：读取了不该读的文件、把内部内容写入外部页面、修改了用户未授权的配置。Harness-Engineering 需要的不只是“ASR=0”式安全结论，而是能区分 L1 harmless attempt、L3 local destructive、L4 cross-scope leak、L6 privilege/escalation chain 的行动后果评估。
机制 / 一阶原理
论文的核心机制是把安全评估锚定到执行轨迹而不是 agent 的自述。程序化 oracle 读取工具调用、参数、执行结果和攻击者目标，用每个 tool 的 effect metadata 判断最严重动作；LLM judge panel 则读取去标签化轨迹，独立给出 L0-L6 严重度。这个设计补上了 binary benchmark 的盲点：二值 ASR 只问“是否命中预设判定”，但 defender 真正关心的是最坏实际 side effect。
与既有 wiki 的关系
- 对 Agent-Benchmarks：补充了“severity distribution / worst-case tail”维度，不能只看 pass rate 或 attack-success rate。
- 对 Harness-Engineering：说明 verification membrane 应记录 action effects，并能在任务结束后产生 harm rubric，而不只是 PASS/FAIL。
- 对 External-Agent-Skills-Design-Patterns：外部 skill 安全审查应检查可执行脚本、网络、文件、凭证、消息发送等 effect metadata，才能做轨迹级严重度评分。
可执行启发
- Hermes 高风险工具调用日志应至少保留：tool name、目标资源、是否写入、是否外传、是否可逆、是否跨用户/跨系统 scope。
- wiki-radar cron 的“安全完成”可以从二值成功升级为：L0 只读发现、L1 被 gate 拦截、L2 无害本地试探、L3 修改本地 wiki、L4 外部投递/发布、L5+ 凭证/权限变化。
- 对外部 skill/repo 的 ingest 不应直接安装运行；先提取 effect metadata，再决定是否 sandbox detonation。
失败模式 / 边界
论文也暴露了边界：严重度 oracle 依赖 per-tool metadata 和可区分的攻击目标；LLM judge 对 escalation chains 有系统盲点；不同环境需要重新定义工具效果表。因此它更适合作为 harness 评估框架，而不是开箱即用的通用安全判官。
写入记录
- 2026-07-09 09:00 CST：新增论文来源页，提炼 action-graded severity 对 agent benchmark、harness 和外部 skill 安全评估的启发。