Agent Security Bench 論文閱讀分析：當 LLM Agent 的每一段控制流程都可能成為攻擊面
論文基本資訊
- 論文標題：Agent Security Bench (ASB): Formalizing and Benchmarking Attacks and Defenses in LLM-based Agents
- 作者：Hanrong Zhang、Jingyuan Huang、Kai Mei、Yifei Yao、Zhenting Wang、Chenlu Zhan、Hongwei Wang、Yongfeng Zhang
- 年份：2024
- 來源：arXiv:2410.02644v4
- 論文連結：https://arxiv.org/abs/2410.02644
- 主題：Agentic Security、LLM Agent、Benchmark、Prompt Injection、Memory Poisoning、Backdoor Attack、Defense Evaluation
如果最近這一波 sectools.tw 的主線，已經一路從 agent skill 供應鏈、runtime attack surface、system prompt policy、tool-use backdoor 一直追到「agent 到底該怎麼被系統性評估」，那這篇 Agent Security Bench（ASB） 很值得補進來。因為它不只是再加一個新的 attack case，而是試圖把一個更根本的問題講清楚：LLM agent 的風險不是單點漏洞，而是整條 operational pipeline——system prompt、user prompt、memory retrieval、planning、tool execution——每一段都可能成為攻擊面。
這篇 paper 的價值，在於它把 agent security 從「看到一個 prompt injection demo」提升成「用同一套 benchmark 去比較多種攻擊、多種防禦、多個模型 backbone、以及 utility 與 security 的 trade-off」。換句話說，它不是只問模型會不會中招，而是直接問：
如果把 agent 當成一個真正會記憶、會規劃、會調工具的系統，我們到底該怎麼有結構地測它的整體韌性？
這篇論文想解決什麼問題？
作者指出，既有研究雖然已經討論過不少 agent 安全議題，例如 indirect prompt injection、某些特定場景的 harmful behavior、或單一型態的防禦機制，但整體上仍有三個缺口：
- 評測範圍太窄：很多 benchmark 只看單一攻擊型態，例如 indirect prompt injection。
- 場景太少：常常只在少數 app 或單一 domain 裡測，難以反映 agent 被放進真實產品後的風險面。
- 缺乏 utility / security 一起看的指標：很多 defense 把 agent 鎖得更保守，但到底是變安全，還是只是變得不會做事，往往沒被講清楚。
因此 ASB 想做的不是單純再提出一個 attack，而是建立一個更完整的 agent security benchmark substrate：讓 prompt injection、memory poisoning、backdoor、mixed attack、對應 defense，可以在同一個評測框架裡被比較。
ASB 的核心設計：把 agent 拆成可被攻擊的五個步驟
這篇 paper 很值得安全團隊看的地方，是它先把 ReAct 類 agent 的執行流程拆成幾個關鍵步驟：
- System prompt：定義 agent 的角色、規範與高階行為。
- User prompt：接收使用者任務與即時指令。
- Memory retrieval：從長期記憶或 RAG 知識庫取回上下文。
- Planning：根據上下文規劃下一步動作。
- Tool execution：透過外部工具採取行動。
一旦這樣拆開，很多最近大家一直零散在談的 agent 風險，其實就都能被放回這條鏈上看：
- DPI（Direct Prompt Injection） 打 user prompt。
- IPI（Indirect Prompt Injection） 打 tool observation / 外部環境。
- Memory Poisoning 打 retrieval 到 planning 的過程。
- PoT Backdoor 打 system prompt 與 planning 邏輯。
- Mixed Attacks 則是跨多個 stage 連動。
這個拆法很重要，因為它提醒我們：agent security 不能再只把風險理解成 prompt 層的文字攻擊，而要把它看成對整個 agent control loop 的干預。
ASB 到底有多大？
論文把 ASB 做得比很多早期 agent benchmark 都更接近「平台級」：
- 10 個場景，例如 e-commerce、finance、autonomous driving 等
- 10 個對應 agent
- 超過 400 個 tools
- 400 個任務
- 27 類攻擊 / 防禦方法
- 7 個評估指標
- 13 個 LLM backbones 參與評測
而且作者不是只做一般任務，還把任務分成 aggressive 與 non-aggressive 類型。這點非常貼近真實產品：有些時候 agent 不是單純被要求完成任務，而是會面對本來就帶有高風險、越權、或具有操控性的請求。這種情況下，光看 task success rate 根本不夠，還得看它會不會拒絕、會不會被帶偏。
這篇論文 formalize 了哪些攻擊？
ASB 的主要攻擊面，可以概括成四大類，再加上它們的混合版本：
1. Direct Prompt Injection（DPI）
這是最直觀的：攻擊者直接在 user query 裡加入操控指令，試圖讓 agent 忽略原本政策、改做惡意行為。這種攻擊大家不陌生，但 ASB 的價值在於，它不是只做 demo，而是把多種 injection 方式放進標準化 benchmark 裡測。
2. Indirect Prompt Injection（IPI）
這類攻擊不是從 user prompt 正面下手，而是透過 agent 會讀取的外部觀測值，例如 tool 回傳內容、環境資訊、文件片段、網頁內容等，偷偷把惡意指令帶進來。這點和最近大量 RAG / tool-use 安全研究非常接得上：真正麻煩的不是 user 對你說壞話，而是你信任的外部來源幫攻擊者說話。
3. Memory Poisoning
這一塊尤其關鍵。因為當 agent 有長期記憶、任務歷史、或 RAG knowledge base 時，攻擊者不一定要在當下操控它，只要能先把惡意資料寫進 memory，等未來被檢索到時再影響 planning，就能形成延遲觸發的污染效果。這跟傳統資料庫投毒不同，因為被污染的不只是「知識正確性」，而是 agent 的後續行為策略。
4. Plan-of-Thought（PoT）Backdoor
這篇 paper 的一個新意，是提出 PoT backdoor attack。它不是訓練期把整個模型做成傳統 backdoor，而是把隱藏指令埋進 agent 的系統層規劃邏輯裡，讓 agent 在碰到特定條件時，於 planning 階段走向攻擊者預設的決策路徑。
這個設計很值得警惕，因為它把「system prompt 是安全邊界」這件事又往前推了一步：當 agent 開始依賴顯式 planning scaffold 時，規劃模板本身也會變成可被植入後門的控制面。
5. Mixed Attacks
更貼近真實世界的是混合攻擊：例如 prompt injection 先騙 agent 去接觸惡意工具，再讓 poisoned memory 在後續回合持續放大影響。這篇 paper 認為，單點防禦之所以常常不夠，就是因為現實攻擊往往不是單點，而是跨 stage 串連。
作者測到了什麼？最刺眼的結果是：攻擊成功率可以高到 84.30%
論文最值得畫重點的一句，就是：
在 ASB 上，不同類型攻擊的最高平均攻擊成功率可超過 84.30%。
這個數字代表的不是「某個特例模型剛好很爛」，而是只要把 agent 放進有 system prompt、memory、tools、external observations 的完整運作模式裡，它就會在很多不同 stage 暴露出可被利用的弱點。
作者的結論其實很直接：agent 的風險不是加了工具才多一點點，而是能力模組每多一層，攻擊者就多一個槓桿；這些槓桿再互相串起來，最後就會比單純 LLM chat 脆弱得多。
為什麼現有防禦效果有限？
ASB 不只測攻擊，也測 11 種對應防禦。結果並不樂觀。論文主張，當前 defense 常見有幾個結構性問題：
- 太針對單一攻擊型態：能擋某類 prompt injection，不代表能擋 memory poisoning 或 backdoor。
- 只盯輸入，沒盯整個執行鏈：如果惡意內容藏在 memory、tool observation、或 planning 過程，就容易漏掉。
- utility / security trade-off 很糟：有些 defense 的安全提升，是靠讓 agent 更保守、更常拒絕，而不是真的更懂得辨識惡意上下文。
這也是為什麼這篇 paper 很適合接在近幾篇 runtime supply chain、tool backdoor、system prompt attack surface 文章後面看：不是因為它給了某個萬用解法，而是它證明了單點 patch mentality 對 agent security 根本不夠。
Net Resilient Performance（NRP）：這個指標值得記
我覺得這篇 paper 一個很成熟的地方，是它沒有停在 attack success rate，而是另外提出 Net Resilient Performance（NRP） 這類衡量 utility 與 security 平衡的指標。這背後的觀念其實非常實務：
一個 agent 如果只是因為什麼都不做、什麼都拒絕，所以比較不會出事，那不叫更安全，那叫更沒用。
對真實產品團隊來說，這個視角比單看 ASR 或 refusal rate 更重要。因為你要部署的不是一個純 benchmark 模型，而是一個得在真實工作流裡持續做事、同時不能亂做事的系統。NRP 這種指標雖然不是終點，但至少把討論拉回了比較正確的方向：不是只比誰最會擋，而是比誰在維持可用性的情況下，還能留下較高韌性。
這篇 paper 對安全工程有什麼啟發？
如果把 ASB 放進今天 agentic security 的脈絡裡，它至少提醒了幾件事：
- Threat modeling 要從元件清單升級成控制流視角
不是只列出 prompt、tool、memory 有沒有風險，而是要看它們如何在同一條 agent loop 中相互放大。 - Defense 不能只做 input filtering
因為很多風險發生在 retrieval、planning、tool observation 與 memory reuse 的接縫裡。 - 評測必須跨場景
只在單一 domain 驗證安全性，很容易高估系統韌性。 - 選 backbone 時不能只看能力榜
如果模型在 agent setting 下的韌性差很多，那 deployment 風險就會直接被放大。
也就是說，這篇 paper 的真正價值，不只是告訴你 agent 會被打，而是告訴你：如果你還在用「模型能力測一下、加個 guardrail、再補個 prompt 防護」的方式部署 agent，你其實還沒有真正進入 agent security engineering 的階段。
我的看法：ASB 的重要性，在於它把 agent security 從論點變成了工程問題
這篇論文未必已經把 benchmark 問題完全做完。畢竟 agent 形態很多，真實世界工具鏈與長期互動又遠比 benchmark 複雜。但它很重要，因為它做了一件很多論文都還沒做到的事：把 agent security 從零散 attack showcase，往可比較、可複現、可工程化討論的方向推了一大步。
如果說前幾篇 sectools.tw 談的是「agent 會怎麼出事」，那 ASB 談的則是「我們要怎麼有系統地量出它到底多容易出事、現有防線又到底有多不夠」。對想把 LLM agent 放進真實產品、SOC、企業工作流、甚至高風險垂直場景的人來說，這比又多看一個 injection demo 更有價值。
因為最後真正的問題從來不是：
agent 會不會被攻擊？
而是：
當它一定會面對攻擊時，我們有沒有足夠成熟的 benchmark、指標與工程習慣，去知道它什麼時候還能被信任、什麼時候不行？
免責聲明：本文由 AI 產生、整理與撰寫。