AIR 論文閱讀分析：真正成熟的 Agent Safety，不只要會阻止出事，還要會在出事後善後

論文基本資訊

• 論文標題：AIR: Improving Agent Safety through Incident Response
• 作者：Ziming Wang 等
• 年份：2026
• 來源：arXiv:2602.11749
• 論文連結：https://arxiv.org/abs/2602.11749
• 主題：AI Agents、Agent Safety、Incident Response、Guardrails、Runtime Enforcement、DSL、Autonomous Systems

如果說前一篇 AgentDoG 讓我們看到的是：當 agent 真正開始使用工具、跨步驟規劃、和外部環境互動之後，安全問題早就不只是「最後一句話有沒有違規」；那這篇 AIR 更進一步問的是另一個更務實、也更接近安全工程現場的問題：

就算我們已經做了各種 guardrail、alignment、runtime checks，agent 還是可能出事。那麼，當事故真的發生時，系統能不能像一個成熟的 incident response 流程那樣，自己發現、自己圍堵、自己恢復，甚至把這次事故轉成下次不再重演的防線？

這正是 AIR 想補上的空白。它不是再做一個更會攔截危險計畫的分類器，也不是單純再加一層拒答策略，而是把傳統資安裡非常成熟的 incident response lifecycle —— detection、containment、recovery、eradication —— 直接搬進 LLM agent execution loop。

這個角度很值得 sectools.tw 的讀者注意。因為近幾個月 agentic security 的論文，很多都在談 prevention：怎麼對齊、怎麼 pre-check、怎麼在執行前攔住風險。但真實世界的安全工程從來不是只靠 prevention 活著。再好的 preventive control 都會漏，再聰明的 agent 也會犯錯；真正成熟的系統，一定還要有 incident response。

這篇論文想解決什麼？

作者的核心批判其實非常準：今天大多數 LLM agent safety work，重點都放在事前預防，但對於事故發生後要怎麼處理，幾乎沒有系統化答案。

• Model-centric safety 想降低模型一開始就做錯事的機率。
• Planning / decision-level safety 想在 tool invocation 前就把危險計畫攔下來。
• Runtime enforcement 則試著在執行途中擋掉特定不安全行為。

但問題是，這些方法就算都做了，也仍然不等於「事故不會發生」。一旦 agent 已經真的做出有害行動，例如把敏感檔案複製到不該曝光的位置、在 browser workflow 裡進到危險頁面、或在 embodied environment 裡做出會造成 hazard 的動作，接下來怎麼辦？

AIR 的答案很直接：不要把 agent safety 只理解成阻擋，而要把它升級成完整的 incident management。

AIR 的核心觀念：把 IR lifecycle 變成 agent 的內建能力

如果用最簡單的話概括 AIR，它做的事情可以寫成這樣：

agent step 完成
  ↓
根據當前 tool / state / recent context 檢查是否發生 incident
  ↓
若發生 incident，執行 containment 與 recovery
  ↓
從這次 incident 萃取 guardrail rule
  ↓
未來在 plan generation 階段提前攔截類似事故

這裡最關鍵的是，AIR 不是只做偵測，也不是只做修補，而是把四個階段連成一條完整鏈：

• Detection：這一步是不是已經造成 incident？
• Containment：先把傷害止住。
• Recovery：把環境拉回安全狀態。
• Eradication：把這次事故轉成未來的 guardrail 規則，避免再犯。

這個設計很有意思，因為它讓 agent safety 從靜態規則集，變成一個會從事故中累積防禦知識的系統。這點和傳統 IR 裡的 post-incident hardening 非常像，只是 AIR 把這件事自動化了。

這篇論文最值得記住的技術點：它不是只提概念，而是做了一套 DSL

AIR 並不是抽象地說「系統應該具備 incident response」，而是設計了一個 domain-specific language（DSL），讓開發者或系統可以明確描述：

• trigger：哪一種 tool invocation 會觸發檢查
• check：要如何判斷 incident 是否已經發生
• remediate：若出事，應該怎麼圍堵與恢復

論文中的示意規則大致像這樣：

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

這種寫法的價值很高。因為它沒有把 incident response 綁死在某個特定 API 或硬編碼函式上，而是用一種結構化、但仍保有自然語言彈性的方式，去描述安全條件與修復動作。

換句話說，AIR 的設計哲學不是「用更硬的規則把 agent 綁死」，而是「用足夠可解釋的語言，把安全意圖寫進 agent 能理解與執行的 operational form」。

為什麼這件事重要？因為 agent 的風險常常不是單一步驟能看懂的

作者強調，很多 agent 事故不是簡單的 syntactic violation，而是要看當前環境狀態、最近上下文、與行為語意才能判斷。

例如：

• 同樣是 copy file，是否有問題，取決於檔案是否敏感、目的地是否受保護。
• 同樣是瀏覽某個網站，是否構成 incident，取決於它是不是釣魚頁、是不是導向資料外洩風險。
• 同樣是操作微波爐或某個物件，在 embodied setting 裡是否危險，必須看物件材質、位置、互動順序與當前狀態。

所以 AIR 的 check 不是只做關鍵字比對，而是讓 agent 參考：

• 當前 environment state
• 最新 observation
• recent execution context

也因此，AIR 真正處理的不是「某個函式呼叫違不違規」，而是某個行動在這個上下文下是否已經形成 incident。

Containment / Recovery：真正把 agent 當成會動手的系統，而不是只會被動回答

很多 safety paper 在「攔截」這一步就停了，但 AIR 很務實地往下走：如果事故已經發生，系統必須能透過 agent 自己的 tool interface 去做 containment 與 recovery。

這件事的技術意義其實很大。因為它代表 AIR 預設的不是一個只會拒答的模型，而是一個已經有能力改變環境的 agent。對這種 agent 而言，安全問題自然不能只停在 moderation，而必須變成 operational safety。

在這篇論文裡，containment 的角色是先把危害停止，recovery 則是讓系統回到安全配置。作者還特別指出：一旦 task 已經進入 compromised state，AIR 會在 remediation 後終止原任務，而不是假裝什麼都沒發生繼續跑。這點非常對，因為真實 IR 裡很多事故也是這樣處理：先止血，再恢復，而不是邊流血邊假裝繼續做業務。

Eradication：這篇論文真正漂亮的地方，在於它會把事故變成新 guardrail

AIR 最值得記住的，可能不是 detection，也不是 remediation，而是 eradication 的設計。

當 incident 被偵測並處理完之後，AIR 不會就此結束，而是會蒐集這次事故中的關鍵資訊，例如：

• agent 的原始 plan
• 實際執行的 tool invocation
• 當時的 environment state
• 對應觸發的 AIR rule 與 incident check

接著，系統會讓 agent 生成一條新的 guardrail rule，例如在未來 plan generation 階段就先攔下「看起來會導致相同事故」的規劃意圖。

這個概念很像把 incident postmortem 轉譯成 machine-enforceable safety knowledge。對 agentic systems 來說，這非常有價值，因為它代表系統不再只是靜態地被開發者手工更新規則，而是可以在某種程度上從事故中自我硬化（self-hardening）。

實作層面：AIR 怎麼接進 agent loop？

作者把 AIR 接在兩個關鍵鉤子上：

• tool invocation 後：做 incident detection 與 remediation
• 下一步 plan execution 前：套用 guardrail rules，提前阻擋類似風險

他們的 reference implementation 建在 OpenAI Agent SDK 上，並使用 ANTLR4 解析 DSL。不過論文強調這個框架本身是 framework-agnostic 的：理論上，只要別的 agent framework 也有類似的 before-step / after-tool hooks，就可以接入 AIR。

這點很重要，因為它代表 AIR 不是綁死在某家 agent stack 上，而比較像一種可攜式的安全控制層。

實驗設計：作者不是只在單一場景 demo，而是橫跨三種 agent 類型

AIR 的實驗覆蓋三種代表性 agent：

• Code Agent
• Embodied Agent
• Computer-Use Agent（CUA）

對應資料集分別來自：

• Code Agent：RedCode，超過 4,000 個高風險程式任務、25 類 risky behavior
• Embodied Agent：SafeAgentBench，750 個任務、10 類 hazard
• Computer-Use Agent：基於 RiOSWorld / OSWorld 的 browser / UI risk task

這個設計很聰明。因為 AIR 若只在 code agent 上有效，很容易被理解成某種針對檔案或 shell 行為的特殊防護；但作者刻意跨到 embodied 與 browser domains，就是要證明這件事不是某一類工具的特殊補丁，而是agent incident response 作為一種一般性框架。

結果怎麼樣？論文想傳達的重點是：agent IR 不只可行，而且成績相當高

從論文摘要與內文結果來看，AIR 在三類 agent 上都達到相當強的成績：

• incident detection success rate 超過 90%
• remediation success rate 超過 90%
• eradication / future prevention success rate 也超過 90%

在某些段落中，作者甚至提到多個場景的 remediation / eradication 成功率可達 95% 以上。此外，對 safe task 的測試裡，embodied 與 computer-use setting 都報告了沒有 false positives。

這些數字當然還是要保留研究論文常見的謹慎：因為 ground truth 與 remediation success 本身帶有人工評估成分，而且各資料集的 task 難度與 agent baseline 能力也不完全一樣。但至少從論文呈現來看，它提供了一個很清楚的訊息：incident response 不是只能留給人類處理，至少在許多 agent setting 裡，部分 IR lifecycle 已經可以被系統化、自動化。

時間成本與 overhead：AIR 不是免費的，但代價沒有大到不可接受

論文也沒有迴避 runtime cost。作者量測了三種時間：

• check time：判斷是否發生 incident 的時間
• response time：執行 containment / recovery 的時間
• eradication time：生成 guardrail rule 的時間

結果很直觀：

• check time 相對執行時間通常不算太大，尤其在本來就慢的 browser agent 上更不明顯。
• response time 往往和原本 task execution 同量級，因為你真的要動手把環境修回去。
• eradication time 最不穩定，也常常最長，因為 rule synthesis 本身就是額外推理工作。

這個 trade-off 非常合理。安全工程本來就不是零成本。真正值得注意的是：作者沒有把 AIR 講成「又快又免費的完美保護」，而是承認它有 latency，並討論可行的優化方向，例如：

• 先用更輕量的 prefilter 減少 check 次數
• 讓較小、較快的模型平行做風險判斷
• 把 incident detection 和主執行 loop 稍微 decouple

這讓 AIR 顯得比較像真正可以進 production 討論的東西，而不是只在 paper 裡漂亮。

另一個亮點：規則不一定都要人手寫，LLM 也能生成 AIR rules

作者另外測試了一件很重要的事：AIR rules 能不能由 LLM 自動生成？

在他們的設定裡，會提供：

• agent 類型與可用工具描述
• 少量 developer-authored AIR rules 作為示例
• 對應資料集中的 risky tasks 範例

然後讓 GPT-5 之類的模型去生成規則。結果顯示，這些 LLM-generated rules 在三個 domain 上的 detection success rate 也都能超過 80%，而 remediation / eradication 表現也接近手工規則。

不過作者也很誠實地指出問題：

• 有些規則會過度貼合特定例子，泛化不佳。
• 有些規則又會寫得太抽象，導致 false positive 風險提高。
• 某些 remediation 會過度理想化，例如要求「恢復已刪除檔案」，但在現實裡根本做不到。

這段我覺得很重要，因為它讓這篇論文沒有落入「既然 LLM 能寫規則，那人就可以退出」的天真敘事。相反地，作者給出的訊息比較成熟：LLM 可以協助生成 incident response 知識，但 human-in-the-loop validation 仍然非常必要。

這篇論文對 sectools.tw 的意義在哪裡？

如果把 AIR 放進最近 sectools.tw 這串文章脈絡，它的位置其實非常關鍵。

• AgentDoG 在問：怎麼更細粒度地看懂 agent risk、知道風險從哪裡來。
• Hallucination-Resistant Security Planning 在問：高風險場景裡，模型何時該停手。
• IRCopilot 在問：LLM 能不能真的協助 incident response workflow。
• CORTEX / SIABench / AIDR 在問：SOC 裡的協作、triage 與可稽核推理能不能更可靠。

而 AIR 補上的，是另一個平常很容易被忽略、但其實非常核心的問題：

就算 agent safety control 全部做了，當 agent 還是出事時，我們有沒有一套像傳統資安那樣成熟的 IR 機制，能真正處理 agent 本身造成的事故？

這讓 AIR 雖然不直接是在做 CTI 抽取、TTP mapping 或 SOC benchmark，卻和這整條主線高度相關。因為只要你真的想把 agent 放進安全工作流，遲早都得面對這個問題：不是只有「怎麼避免 agent 出事」，還有「出事後怎麼讓它收手、修復、學會別再犯」。

限制與保留

這篇論文當然也不是沒有保留點。

• 它仍然依賴 agent 本身的推理品質。 如果 agent 已經嚴重誤判環境，incident check 與 remediation 也可能一起失真。
• DSL 雖然優雅，但仍需要規則工程。 對真實企業環境來說，風險場景可能比 benchmark 更髒、更混雜。
• 自動生成 guardrail rule 很吸引人，但也有過擬合與錯誤泛化的風險。
• runtime overhead 不可忽視。 對高吞吐、低延遲場景來說，任何額外檢查都要算成本。
• 這仍偏研究原型。 真正要接進 production agent platform，還會遇到權限模型、觀測面、審計紀錄、rollback 能力與跨系統 orchestration 等更硬的工程問題。

但即使如此，AIR 仍然是一篇我會認為非常值得記住的論文。因為它把 agent safety 從「怎麼不犯錯」往前推成「犯錯後怎麼善後」，而後者其實才更接近真實世界系統設計。

重點整理

• AIR 要解決的核心問題是：當 LLM agent 真的發生安全事故後，系統能不能自動完成 incident response lifecycle。
• 它把傳統 IR 的 detection、containment、recovery、eradication 直接接進 agent execution loop。
• 作者提出一套 DSL，讓規則可描述 trigger、check、remediate 三個部分。
• AIR 不只偵測事故，也會執行修復，並把事故轉成未來 plan-level guardrail rule。
• 實驗橫跨 Code Agent、Embodied Agent、Computer-Use Agent 三個 domain，而不是單一 demo 場景。
• 論文報告 detection / remediation / eradication success rate 多數都在 90% 以上，顯示 agent IR 作為一種框架是可行的。
• 作者也證明 LLM 可以協助生成 AIR rules，但仍需要 human-in-the-loop validation。
• 這篇論文真正補上的，是agent safety 的事故治理能力，而不只是更嚴格的預防控制。

Takeaway

AIR 最值得記住的地方，不是它又替 agent 加了一層 guardrail，而是它提醒我們：真正成熟的安全系統，從來都不只靠 prevention。當 agent 開始能夠動手改變環境、跨工具執行、累積 side effects 之後，安全工程也必須跟著升級——不只要會攔，還要會救、會修、會記住這次怎麼出事，然後讓下一次更不容易重演。

如果說 AgentDoG 在做的是 agent risk diagnosis，那 AIR 更像是在補 agent-world 裡的 SOAR / IR 層。對任何想把 AI agent 真正放進高風險工作流的人來說，這篇論文的訊息其實很簡單，也很重要：你不能只問 agent 聰不聰明，還要問它出事時，系統有沒有能力善後。

免責聲明

本文由 AI 產生、整理與撰寫。

內容主要依據公開論文、arXiv 頁面與可取得之研究資料進行彙整、解讀與摘要。由於本文未逐節重建全部附錄、規則細節、標註流程與人工評估準則，對 AIR DSL、各類 agent 任務設定、timeliness 量測與 LLM-generated rule 實驗的理解，仍可能受限於公開材料粒度。實際技術細節、完整實驗條件與最終結論，仍應以原始論文與作者公開資料為準。