Multi-Agent Defense Pipeline 論文閱讀分析：當 Prompt Injection 已經變成流程戰，防線也該是多角色聯防

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

論文基本資訊

• 論文標題：A Multi-Agent LLM Defense Pipeline Against Prompt Injection Attacks
• 年份：2025
• 來源：IEEE WIECON-ECE 2025 / arXiv:2509.14285
• 論文連結：https://arxiv.org/abs/2509.14285
• DOI：10.48550/arXiv.2509.14285
• 主題：Prompt Injection、Agentic Security、Multi-Agent Defense、LLM Security、Runtime Filtering

這篇 A Multi-Agent LLM Defense Pipeline Against Prompt Injection Attacks 很適合拿來放在最近這串 agentic security 論文的中段看，因為它代表的是一種很直觀、也很工程師會先想到的防守路線：既然單一 agent 容易被 prompt injection 帶偏，那就不要把所有判斷都壓在同一個模型身上，而是拆成多個專職角色，讓它們串成一道防線。

它的重點不在於重新定義 prompt injection，也不在於做很深的 formal guarantee；它更像是在問一個很務實的問題：如果我們現在就想把 defense 做成能跑的 pipeline，多個專門 agent 串接起來，是否真的能把攻擊成功率壓下去？

這篇論文想處理什麼問題？

作者聚焦的是最典型的 prompt injection 風險：攻擊者把惡意指令藏在輸入裡，試圖覆蓋 system prompt、改寫既有任務，或誘導模型做本來不該做的事。這類攻擊麻煩的地方，在於它不是單純的 toxic content 問題，而是控制權競爭：誰的指令最後進入模型的決策核心。

論文的基本判斷很直接：如果把所有輸入理解、意圖判定、安全檢查與最終回答都丟給同一個 LLM，一旦那個環節失守，整條鏈就一起失守。所以作者改採 multi-agent defense pipeline，讓不同 agent 分工處理：

• 檢查輸入中是否含有可疑注入訊號
• 分辨正常使用意圖與惡意操控意圖
• 在必要時中止、清洗或覆寫有風險的內容
• 最後再交給回應 agent 處理合法請求

換句話說，這篇 paper 的核心精神是：不要指望單一模型一邊做事、一邊永遠正確地保護自己；把防禦責任拆散，讓多個角色彼此補位。

方法：兩種 multi-agent 防禦架構

作者實作並比較了兩種不同的 defense 架構：

• Sequential chain-of-agents pipeline：多個 agent 依序檢查、過濾、交接
• Hierarchical coordinator-based system：由較高層的協調者 agent 分派與整合防禦任務

這兩種設計其實代表兩種很常見的安全工程思路。

前者像是傳統的多層 gateway：每一關都先看一遍，再交下一關。優點是流程清楚、容易追蹤哪一層擋下攻擊；缺點是 latency 可能更高，而且前面某一層設計太弱時，後面還是會吃到髒內容。

後者則比較像有個 policy brain 在做決策編排：它不只是照順序傳球，而是依照偵測情況決定要不要升級處理、改派不同分析 agent，或直接阻擋。這種架構比較接近現代 agent orchestration 的味道，也比較像未來真實 agent platform 可能採用的方式。

評估設計：55 種攻擊、8 大類、400 個實例

這篇論文的可取之處之一，是它沒有只做幾個 toy examples。作者整理了 55 種獨特 prompt injection attacks，分成 8 個類別，總共測了 400 個攻擊實例，並在兩個模型平台上評估：

• ChatGLM
• Llama2

攻擊類型涵蓋的方向也算完整，包括：

• 直接覆寫型指令（direct overrides）
• 程式碼執行嘗試（code execution attempts）
• 資料外洩導向 payload（data exfiltration）
• 混淆與繞過技巧（obfuscation techniques）

這個設計透露出一個重要訊號：作者不是只把 prompt injection 當成一句話的 jailbreaking，而是當成一族會變形、會換包裝、會朝 side effect 延伸的攻擊集合。這點是對的。

核心結果：ASR 從 20–30% 壓到 0%

論文最吸睛的結果很明確：

• 在沒有防禦的 baseline 下，Attack Success Rate 在 ChatGLM 上達到 30%
• 在 Llama2 上則達到 20%
• 加入 multi-agent pipeline 後，作者報告 ASR 下降到 0%

如果單看數字，這當然非常漂亮。但這裡更值得看的，不是「0% 很厲害」這件事本身，而是它反映出一個比較實際的工程事實：把安全判斷從單次、單點、單模型輸出，改成多角色交叉檢查，確實有機會大幅提高 prompt injection 的攔截率。

這和很多 runtime security 論文的方向其實一致：真正有效的防禦，往往不是讓主 agent 變得更聰明，而是在主 agent 行動之前，多放幾個不完全相信它的結構性檢查點。

這篇論文的價值在哪裡？

我會把它的價值分成三層。

1. 它把「分工式防禦」講得很明白

這篇 paper 雖然不是最理論化的一篇，但它很好地示範了：prompt injection defense 不是只能靠單一 classifier 或單一 system prompt wrapper。 你也可以把安全做成一條 pipeline，讓不同 agent 各自負責偵測、審核、決策與最終生成。

2. 它證明多層檢查在工程上是有感的

很多人知道 defense-in-depth 很重要，但沒有實作與數據時，這句話常常只是口號。這篇研究至少提供了一個可操作的實驗例子：在多類攻擊上，multi-agent 檢查鏈確實明顯優於裸奔 baseline。

3. 它把安全問題從「模型人格」拉回「系統編排」

這也是我覺得最重要的一點。這篇論文隱含地提醒我們：LLM 安全不只是 model alignment 問題，也是 orchestration 問題。 如果系統願意把判斷責任拆開，很多原本集中在單一 agent 身上的風險，就能被結構性地稀釋。

但這篇論文也有幾個限制

當然，這篇 paper 不能被看成 prompt injection 已經被解掉。至少有幾個限制要記住：

• 0% ASR 不代表通用安全保證：這是對作者整理的攻擊集合成立，不代表面對更強、會自適應的攻擊者時仍然不破
• 多 agent 不等於天然安全：如果每個 agent 都共享同樣脆弱的判斷模式，可能只是把同一個盲點複製好幾遍
• 延遲與成本問題：每多一層 agent，就多一層 token 消耗與 latency，實務上未必能無痛部署
• 可能影響合法請求通過率：若 guard 太保守，容易出現 false positives，讓正常操作也被攔下

所以更精準地說，這篇論文證明的不是「multi-agent defense 已經完美」，而是：把 prompt injection defense 做成分工式、可編排、可疊層的安全流程，是一條值得投資的方向。

和近期 agent security 主線怎麼接？

如果把這篇放進近來常見的 agent security 脈絡裡，它剛好站在幾篇論文之間：

• 像 CaMeL、ClawLess 這類工作比較偏 architecture / isolation / security-by-design
• 像 AgentSentry、AttriGuard、PlanGuard 則更偏 runtime diagnosis、causal attribution、action consistency verification
• 這篇 paper 則落在中間：它不是完全重做 agent 架構，也不是只做單點 detector，而是把 defense 直接做成多 agent pipeline。

所以它的定位很清楚：它是在告訴你，安全 agent 自己也可以是 agentic 的。 不只是被保護的系統是多步驟的，連保護它的防線也可以是多步驟的。

一句話總結

這篇論文最值得記住的地方，不是它把 ASR 壓到 0%，而是它示範了一件很實際的事：當 prompt injection 已經是系統編排層的問題，防禦也不該再只是單一模型裡的一段提示詞，而應該是一條由多個專職角色共同守住的 pipeline。

如果未來 agent platform 真的要進入高風險環境，這種把「偵測、審核、生成、阻擋」拆成多角色的做法，大概會比再寫一段更兇的 system prompt 靠譜得多。