MSB 論文閱讀分析：當 MCP 真正把工具變成 AI 的行動介面，最危險的往往不是單一惡意 prompt，而是整條 tool-use pipeline 都能被接管
MSB 論文閱讀分析：當 MCP 真正把工具變成 AI 的行動介面，最危險的往往不是單一惡意 prompt，而是整條 tool-use pipeline 都能被接管
論文基本資訊
- 論文標題：MCP Security Bench (MSB): Benchmarking Attacks Against Model Context Protocol in LLM Agents
- 作者：Dongsen Zhang、Zekun Li、Xu Luo、Xuannan Liu、Peipei Li、Wenjun Xu
- 年份：2025（v2 於 2026 年 3 月更新）
- 來源：arXiv:2510.15994
- 論文連結：https://arxiv.org/abs/2510.15994
- DOI：10.48550/arXiv.2510.15994
- 主題：MCP、Agentic Security、Benchmark、Tool Poisoning、Prompt Injection、Runtime Security
如果前幾篇在談的，是 MCP tool poisoning、權限治理、description injection 與 runtime defense，那這篇 MCP Security Bench（MSB） 值得補進來的原因很直接：它不是再講一個單點攻擊，而是試圖回答一個更實際的問題——當 agent 真的透過 MCP 去發現工具、選工具、帶參數呼叫工具、再把 tool response 接回上下文時，到底整條鏈上哪裡都能被打？而且不同模型會怎麼倒？
我會把這篇的核心價值濃縮成一句話：MCP 的風險不該只被理解成「tool description 裡藏 prompt injection」而已，真正該測的是從 planning、invocation 到 response handling 的整條執行面。
這篇論文想解決什麼？
作者的出發點其實很對。過去很多 agent benchmark 還停留在 function calling 或模擬環境，頂多測幾種 prompt injection，但 MCP 把風險面明顯拉寬了：
- 工具名稱與描述會被送進 agent 的決策上下文
- 工具參數本身也可能變成資料外洩或越權入口
- 工具回傳值不只是資料，還可能是下一步控制訊號
- 外部知識檢索結果可以把惡意內容帶回 active context
也就是說，MCP 不是只多一個標準介面，它其實把工具正式升格成 agent 的控制平面元件。 一旦如此，安全問題就不再只是「模型會不會聽錯話」，而是：
agent 是否會在整個 tool-use pipeline 中，一步一步把攻擊者提供的 metadata、parameter schema、response 與 retrieval content 當成可操作現實的指令依據。
MSB 想補的，就是這個評測缺口。
MSB 在做什麼？
這篇論文提出的是一套專門面向 MCP-based agents 的安全 benchmark，而不是一般泛用 agent benchmark。它的設計重點有三個：
- 攻擊 taxonomy：把 MCP 攻擊拆到 planning、tool invocation、response handling 等不同階段
- 真實工具執行環境：不是只模擬輸出，而是真的透過 MCP 跑 benign / malicious tools
- 安全與效能一起看：不是只看 attack success rate，也看模型在攻擊下還能不能完成原本任務
規模也不小。作者最後做出的 benchmark 包含：
- 10 個場景
- 65 個 realistic user tasks
- 25 個 MCP servers
- 304 個 benign tools
- 405 個 attack tools
- 2,000 個 attack instances
這個規模有價值，因為它不是只拿一兩個 toy example 證明「看吧，MCP 很危險」，而是把 MCP 常見的攻擊面系統化地排進一個可以比較模型、比較防禦、比較 trade-off 的測試床。
這篇最值得記住的地方：它把攻擊面拆成整條 pipeline，而不是單點 prompt
MSB 把攻擊分成幾個核心類別，我覺得這個分類非常實用，因為它逼你從 execution path 而不是從單一 payload 去思考風險。
1. Planning 階段：tool signature attack
這裡打的是工具名稱與描述，也就是 agent 在選工具前會先看到的那層。
- Name Collision（NC）：把惡意工具名字做得像合法工具，例如加個
_v1 - Preference Manipulation（PM）：在 description 裡塞「這是最好的工具」之類的誘導語句
- Prompt Injection（PI）：直接把惡意指令嵌進 tool description
這組攻擊在提醒一件很關鍵的事：工具 metadata 不是中性的說明文件，它其實已經是 agent 的前置控制訊號。
2. Invocation 階段：tool parameter attack
這裡作者測的是 Out-of-Scope Parameter（OP）。意思不是 tool 回傳有毒，而是工具宣告的參數本身就誘導 agent 送出不該提供的資料，例如與任務無關、但高敏感的系統資訊。
這個點非常重要，因為它說明：MCP 風險不只在語意注入，也在參數邊界。 如果 agent 對參數範圍沒有 contextual authorization，它就可能很乖地把不該交出的東西交出去。
3. Response handling 階段：tool response attack
這是我覺得很多團隊最容易低估的地方。工具回傳值如果被 agent 直接當成下一步 planning 的依據，那 response 本身就成了攻擊面。
- User Impersonation（UI）：工具假裝自己是使用者，改派更「緊急」的新任務
- False Error（FE）：工具回假的錯誤訊息，誘導 agent 依照攻擊者指定方式「修復」
- Tool Transfer（TT）：工具宣稱自己已被替換，騙 agent 改去呼叫另一個惡意工具
這幾種攻擊共同點都一樣：不是直接改 system prompt，而是透過工具回應劫持 agent 的後續決策流程。
4. Retrieval Injection（RI）
這類攻擊不是工具本身惡意，而是外部資料源有毒。當 benign tool 去查資料庫、知識庫或文件時，把惡意內容撈回來，然後混入 agent 上下文，造成後續偏航。
換句話說，工具乾淨不代表流程乾淨；只要 retrieval path 沒被治理，毒一樣會進來。
5. Mixed Attacks
這篇也很務實地承認，真實世界裡攻擊不會只打單一點，所以他們還設計混合攻擊，例如：
- PI + UI
- PI + FE
- PM + OP
- TT + OP
這個設計很關鍵，因為很多 defense 在單點測試看起來還行，但一旦攻擊跨越多個 execution stage，就會開始崩。
這篇 benchmark 比較像真的地方：它不是純模擬，而是跑真工具
我認為 MSB 比不少 benchmark 更有說服力的一點，是它不只生成攻擊文字，而是真的把 benign tool 與 malicious tool 都放進 MCP 執行環境裡跑。
作者用常見 MCP 平台上的工具建 benign set，驗證功能後保留 304 個 benign tools，再對它們做 mutation 產生 405 個 attack tools。環境裡也放進像 FileSystem 與 DesktopCommander 這種能實際動 workspace 的能力，讓攻擊不是停在紙上談兵，而是可驗證 agent 是否真的被帶去做了惡意操作。
這件事很重要，因為很多 agent benchmark 的問題不是沒 taxonomy，而是：
- 環境太乾淨
- 工具太假
- 攻擊成功只靠語意評分，不看真實副作用
MSB 至少往前跨了一步：它用 workspace state、tool invocation logs 與任務完成情況來判斷攻擊是否真的成功。
這篇提出的三個指標，很值得記
作者不是只看單一 ASR，而是一起看：
- ASR（Attack Success Rate）：攻擊成功率
- PUA（Performance Under Attack）：在攻擊下，原本使用者任務還完成多少
- NRP（Net Resilient Performance）：
PUA × (1 - ASR)
我很喜歡他們把 NRP 拉出來，因為安全評測如果只看 ASR，很容易鼓勵出那種「什麼都不做，所以也比較不會中招」的假安全模型；反過來，如果只看 task success，又會獎勵那些超會做事、也超容易被騙的模型。
NRP 的意義就在於逼你正視 trade-off：你到底是想要一個超能幹但很好帶偏的 agent，還是一個很保守但幾乎沒產值的 agent？
關鍵結果怎麼看？
這篇最值得記的幾個數字有：
- 整體平均 ASR 為 40.35%
- OP（Out-of-Scope Parameter）平均 ASR 高達 76.50%
- UI（User Impersonation）平均 ASR 為 45.69%
- FE（False Error）平均 ASR 為 39.21%
- Mixed attacks 通常比單點攻擊更強
- 最高單模型平均 ASR 可到 60% 以上，單類別甚至接近 100%
這些數字背後最值得注意的，不是「某模型比較爛」而已，而是兩個更大的結論。
第一個結論：Invocation 與 response path 比大家想像的更脆
很多討論會把焦點放在 description injection，但這篇的結果顯示，參數面與回應面根本一樣，甚至更危險。 尤其 OP 這種 attack success rate 高得誇張，說明只要 agent 對 parameter scope 沒有足夠治理，它就很容易把資料自己送出去。
這很像一種 agent 時代的新現實：不是所有越權都要靠 hard exploit，有時候只要讓 agent 自己「合法地」多講一點、多帶一個參數，就夠了。
第二個結論：越會做事的模型，往往也越容易中招
作者觀察到一個很重要、也很符合近年 agent security 經驗的現象：模型能力與安全性之間出現 inverse scaling。
原因不難懂。攻擊任務本身也常需要 agent 會選工具、會跟指令、會把流程跑完。於是：
- 越會 tool use 的模型
- 越願意遵守上下文訊號的模型
- 越擅長把「看起來像流程的一部分」整合進任務的模型
反而越可能把攻擊者餵進來的 metadata、response 或 retrieval content 一路執行到底。
這也是為什麼我一直覺得，agent 安全不是把模型訓得更聽話就好，反而常常是要在模型外面加結構性 friction。
防禦結果其實也很誠實：只靠 detection，不太夠
論文還拿一個 MCP 防禦方法 MCIP 來測。結果很有意思：
- 平均 ASR 從 40.35% 降到 28.69%
- 但平均 PUA 也從 56.50% 降到 48.91%
- 最後 NRP 只從 33.70% 小幅升到 34.88%
這個結果其實很有啟發性。它說明了兩件事：
- 單純偵測與阻擋 雖然能壓低一部分風險，但很容易連正常任務一起打傷
- 如果 defense 不理解情境與授權範圍，它就只能靠保守拒絕來換安全
換句話說，MCP defense 不能只當內容審查器，它更需要像 runtime policy engine，一邊看上下文、一邊看任務範圍、一邊看工具能力與參數是否合法。
我怎麼看這篇 paper？
我覺得 MSB 的真正價值，不只是又多一個 benchmark，而是它幫 MCP 安全社群把討論重心從「哪句描述有毒」往前推成：
整個 MCP 工具鏈，從發現、選擇、參數化到回應吸收，都是 attack surface。
這種視角很重要，因為它會直接影響你怎麼設計 defense：
- 只做 tool description sanitization，不夠
- 只做 response filtering，不夠
- 只做 permission prompt，不夠
- 只做 model alignment，也不夠
真正需要的比較像是：
- tool metadata integrity
- parameter scope control
- response provenance 與 trust labeling
- retrieval sanitization
- task-scoped runtime authorization
也就是說，MCP 安全問題本質上是 runtime governance 問題，而不只是 prompt hygiene 問題。
這篇對實務團隊最有用的提醒
如果你的團隊已經在用 MCP 或準備導入類 MCP 架構，我認為這篇最實務的 takeaway 有三個：
- 不要把 tool metadata 當說明文件，它其實是控制面輸入。
- 不要只檢查工具能不能被叫，還要檢查「叫的參數」是否符合任務授權。
- 不要把 tool response 當中性資料，因為它很可能正是下一跳 prompt injection 的載體。
很多團隊現在還在把 MCP 想成「把 API 接進 agent 的比較方便的方式」，但 MSB 很清楚地提醒你：一旦工具變成模型原生可理解、可選擇、可編排的物件，整個系統安全模型就已經變了。
總結
MCP Security Bench 這篇論文最有價值的地方，不在於它再一次證明 MCP 有風險，而在於它把風險拆成一條完整的 tool-use pipeline，並且用真實工具執行、任務完成度與攻擊成功率一起量化。
如果要用一句話總結這篇，我會這樣寫：
當 MCP 把工具正式變成 agent 的行動介面後，真正該防的就不再只是那句惡意 prompt，而是整條會讓模型替它把事做完的執行鏈。
這也是為什麼這篇值得看——它不是只在講某個 payload 多聰明，而是在逼大家面對一個更麻煩、但也更接近現實的問題：agent 安全要守的，從來都不是單一輸入點，而是整個 runtime control plane。