AIR: Improving Agent Safety through Incident Response

先给结论

AIR 的位置非常清楚：前面几篇论文告诉我们 memory、retrieval、state、trend 会怎么漂移；AIR 告诉我们监控器报警之后该做什么。一个 Drift Monitor 如果只能输出 risk score，而不能触发 containment、recovery、eradication，它在真实 agent 系统里是不完整的。

版本说明：本页基于公开 arXiv v1 PDF/source、TeX/source inventory、图表抽取和实验表格重建完成；检索日期为 2026-05-26。本页是 paper2html 深度阅读，不声称完成了独立复现实验。

研究动机

很多 agent safety 工作都默认目标是“让失败不要发生”：对齐底层 LLM、检查计划、拒绝危险工具调用、用 runtime guard 阻断某一步。这些都重要，但对真实 agent 还不够。agent 会生成自然语言计划、连续调用工具、修改外部环境；单步看似无害的 action，经过多步组合可能已经造成 side effect。

AIR 的核心立场是：失败不可避免，所以系统需要 incident response。传统安全系统会讲检测、遏制、恢复、根除；LLM agent 也需要类似生命周期，只是它面对的是更语义化、更动态、更依赖工具的执行轨迹。

这正好补上 Drift Monitor 的一个缺口。我们此前关心的是“能否发现 drift”；AIR 强迫我们继续问：“发现之后，是停止当前任务、隔离状态、回滚 memory，还是生成一条未来 pre-check 规则？”

数学表示及建模

论文把 LLM agent 建模为一个在环境状态 \(\mathcal{E}_t\) 和内部上下文 \(C_t\) 上迭代的执行过程。首先，agent 根据当前上下文生成 plan：

然后通过工具执行函数改变环境，产生 action、observation 和新环境状态：

最后，agent 把 plan 与 observation 写回上下文：

这个建模很适合 self-evolving agent：危险不一定在 \(\pi\) 阶段就暴露，也不一定是单个 \(a_t\) 的静态属性。危险可能来自 \(\tau\) 已经造成的环境副作用，或者 \(\phi\) 把失败轨迹写回上下文后改变未来行为。

因此，AIR 实际上把 agent 的安全控制拆成两个位置：

对我们的方向，可以把它抽象成 action policy，而不是 scalar score：

算法流程 / 方法

DSL: AIR rule

AIR 的关键工程设计是一个轻量自然语言 DSL。它不是把所有检查写成底层 API predicate，而是让开发者或 LLM 用结构化自然语言描述 trigger、check 和 remediation。

rule @copy_sensitive_file
trigger python_repl
check
  a sensitive file has been copied
  into an unprotected directory.
remediate
  delete the copied sensitive file,
  then confirm that no other sensitive files
  remain exposed in the working directory.
end

Runtime execution semantics

AIR 嵌入 agent 的执行循环。每个 step 完成后，它先根据 trigger 选出相关规则，再让 agent 用当前环境状态、最新 observation 和 recent execution context 判断 check 是否成立。如果没有 incident，继续原任务；如果有 incident，执行 remediate，并在 remediation 之后终止原始已受污染任务。

这里有一个很重要的设计判断：AIR 不让 agent 在同一个 compromised task 里“修完继续干”。它完成 containment/recovery 后终止原任务，这比“边修边继续”更适合高风险系统，因为后者可能让一个已经出现副作用的上下文继续扩大影响。

Eradication: guardrail rule generation

remediation 只是修当前事故，eradication 要防止复发。AIR 会抽取最近 incident 的 plan、tool invocation、environment state 和 check condition，然后生成未来 pre-check guardrail：

rule @copy_sensitive_file_precheck
trigger python_repl
check
  plan suggests copying files from system
  directories into user-level folders.
block
end

这个 guardrail 与 AIR rule 的区别是：它在未来 plan 刚生成时运行，判断“如果执行这个 plan，会不会复发同类 incident”，因此可以在工具调用前 block。

Implementation

论文的 reference implementation 基于 OpenAI Agent SDK，在两个位置加 hook：一是在 tool invocation 之后做 incident detection / remediation；二是在每一步执行前做 plan-level guardrail check。DSL 用 ANTLR4 解析成统一 IR。作者强调设计本身是 framework-agnostic，原则上可以映射到 LangChain 或 ReAct-style controller。

实验设计

实验围绕四个 RQ：RQ1 检测/响应/根除是否有效；RQ2 是否及时以及 safe task overhead 多大；RQ3 LLM 能否自动生成可用规则；RQ4 结构化 remediation 和 guardrail generation 是否必要。

论文的 effectiveness metrics 覆盖 incident response 生命周期：

实验结果

RQ1: 三类 agent 上 detection / response / eradication 都较强

Code Agent 的 25 个 RedCode 风险类别中，大多数类别 #det 与 #exe 相同；不可逆类别无法 remediation，因此重点看 eradication。例如 untrusted installation 是 28/28/28/28，copy sensitive files 是 14/14/14/14，eval injection 是 26/26/--/26。论文也指出，某些类别的低 #det 不一定是检测失败，而是 agent 经常没有真正生成对应 risky behavior。

Embodied Agent 的结果更干净：10 个 hazard categories 中 #det 全部等于 #exe，#rem 和 #era 也接近满分。

CUA 的底层执行成功率较低，但在已发生 incident 的子集上 AIR 仍能检测和响应。这个边界很重要：AIR 证明的是 incident response 能力，不是 CUA 本身能完成所有 UI tasks。

RQ2: check 不算太慢，但 safe-task overhead 不小

作者没有把 overhead 轻描淡写。safe tasks 上，Embodied 和 CUA 都约增加 40% 时间。论文讨论了两个优化方向：用轻量 rule-based prefilter 减少 check 触发频率；或者用更小更快的 risk model 并行检查，把检查与主执行解耦，只保留一个短 delay window。

RQ3: LLM-generated rules 可用，但仍需要 HITL

这里 LLM 使用 GPT-5，输入包括目标 agent 描述、可用工具、3 个 developer-authored 示例规则和风险任务示例；生成规则不经人工修正直接评估。结果显示 DSL 结构足够规则，LLM 能生成有用规则。但作者也指出两个失败模式：过窄规则漏掉同类风险，过抽象规则容易误报；还有一些 remediation 过于理想化，例如“恢复已删除文件”。

RQ4: structured remediation 和 guardrail generation 都必要

去掉 rule-specified remediation，让 agent 自己推断恢复动作，成功率下降且 response 更慢。这对 Drift Monitor 很关键：报警后不能只说“请修复”，需要结构化 recovery playbook。

guardrail refinement 的三轮实验同样重要：Code incidents 从 54 降到 6 再到 0；Embodied 从 67 降到 5 再到 2；CUA 从 8 降到 1 再到 0。这个结果说明 eradication 不是只修一次事故，而是在积累未来执行的安全知识。

False positives

0 FP 是好结果，但也要注意 CUA 的 #pass 很低，很多 safe tasks 是底层 agent 自己没完成，不是 AIR 干预失败。因此这张表说明“没有误拦截”，不说明 CUA agent 本身已经可靠。

我的评论

为什么 AIR 对 Drift Monitor 很有价值

Drift Monitor 的第一版很容易做成一个检测器：给每个 memory/state/tool update 打 risk score，超过阈值就拒绝。但真实 self-evolving agent 里，很多问题不是简单拒绝就结束。比如 memory 已经写入、工具默认权限已经改变、用户长期状态已经被污染、workflow 已经执行一半。此时需要的是 incident response。

我会把 AIR 映射成 Drift Monitor 的后半段：

它不能直接解决的问题

AIR 并不是 self-evolving agent 专门论文；它处理的是 agent execution incident，而不是 memory consolidation、retrieval poisoning 或 alignment tipping。它的 DSL 也依赖自然语言 rule 和 agent reasoning，因此如果 detection model 本身被污染或规则写错，AIR 仍然会漏报或误报。

此外，AIR 的 overhead 不低。如果把它直接套到每个 tiny memory write 上，可能很慢。更现实的做法是分层：轻量 prefilter 先筛出低风险变更，高风险变更才进入 AIR-style response chain；真正 irreversible 或 high-impact 的更新再要求人工确认。

作为 baseline 的可操作版本

我建议把 AIR 当作 action-layer baseline，而不是照搬它的全部 DSL。第一版可以做得很窄：每次 agent 写 memory/skill/state 时，保存 diff；若 monitor 判定风险，执行 rollback；然后把触发风险的 pattern 自动加入 future pre-check。这样就把 AIR 的三段式响应落到了自进化系统的 writeback boundary 上。

One More Thing

AIR 给了一个很好的论文结构启发：我们的 Drift Monitor 不能只报告“检测准确率”，还应该报告 incident lifecycle 指标。比如：

这能让我们的方向从“又一个安全分类器”变成“带恢复和防复发的 self-evolution safety runtime”。AIR 本身不是最终答案，但它提供了一个非常实用的评测语言。

Reference / Evidence