MCP Threat Modeling 論文閱讀分析：真正危險的也許不是某個有毒工具，而是整個 client 還把 tool metadata 當成半可信控制面在吃

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

如果最近這一串 sectools.tw 的文章，已經一路把 MCP、tool poisoning、prompt injection、approval fatigue 與 runtime trust boundary 這些線慢慢接起來，那這篇 Model Context Protocol Threat Modeling and Analyzing Vulnerabilities to Prompt Injection with Tool Poisoning 很值得補進來，因為它把問題講得更白：很多風險其實不是出在某個特定 server「特別邪惡」，而是大量 MCP client 從設計上就還把 server 回來的 tool metadata、參數描述與 approval UI 當成可直接進決策鏈的半可信控制面。

這篇 paper 最有價值的地方，不只是再講一次 MCP 有風險，而是它把問題拆成兩層一起看：先做整個 MCP 生態的 threat modeling，再把最高風險的 client-side tool poisoning 拉出來做實測。 也因此它得到一個很實務、也很不舒服的結論：你以為自己在選模型，很多時候其實是在選 client 安全 posture；同一類 LLM 接在不同 MCP client 上，風險表現可以差到接近兩個世界。

• 論文標題：Model Context Protocol Threat Modeling and Analyzing Vulnerabilities to Prompt Injection with Tool Poisoning
• 來源：arXiv:2603.22489（2026）
• 研究類型：MCP threat modeling / tool poisoning security evaluation / client-side security analysis

這篇論文在做什麼？

作者先不是急著做 defense，而是先問一個更基本的問題：MCP 這整套 host、client、server、LLM、外部資料庫與授權流程，到底哪裡最容易出事？

他們用兩套很傳統、但放在 agent 世界依然很有用的安全方法去做分析：

• STRIDE：系統性盤點 spoofing、tampering、repudiation、information disclosure、DoS、elevation of privilege
• DREAD：替每個 threat 做風險打分，判斷哪幾類最值得優先處理

分析範圍橫跨五個 MCP 關鍵元件：

• MCP Host + Client
• LLM
• MCP Server
• External Data Stores
• Authorization Server

作者總共盤出 57 個 threats。而在這些 threat 裡，最值得注意的是：client-side 漏洞被評成整體最嚴重的一塊。 特別是 tool poisoning 被打到 DREAD 46.5/50，屬於 Critical 等級；prompt injection 本身甚至到 50/50。

換句話說，這篇不是在說「MCP 可能有問題」，而是在說：如果你不把 client 視為第一線安全邊界，而只是把它當一個把 tool list 餵給模型的 UI 容器，那整條信任鏈幾乎一開始就站不穩。

這篇最重要的 framing：漏洞不只在 server，而在 client 怎麼相信 server

我覺得這篇最該記住的，不是某一個攻擊 payload，而是一個觀念轉向：

工具是在 server 上執行，但 exploitation 常常發生在 client 端的 reasoning path 裡。

也就是說，server 只是提供了工具名稱、描述、參數 schema、提示文字；真正把這些東西當成可操作語意來理解、並進一步影響 agent 決策的，是 client 把 metadata 放進 LLM context 的那一步。

這就是 tool poisoning 的核心：攻擊者不一定要控制 user prompt，也不一定要先拿下模型本身；只要能讓惡意語意混進 tool description、parameter description、prompt template 或 approval flow，client 就可能自己把它送進 decision loop。

這也是為什麼作者一直強調：這不是單純的 server-side 漏洞，也不是單純的 model jailbreak，而是 client-server trust model 本身的設計問題。

他們實際測了什麼？

在 threat modeling 之外，作者把 focus 收斂到最危險、也最有操作性的 client-side attack：tool poisoning。

他們挑了 7 個主流 MCP clients 做實測，並用四種逐步升高風險的 attack 來看 client 到底能不能攔下來：

• 讀取敏感檔案：嘗試讓工具去碰使用者本機敏感資料
• logging surveillance：讓工具默默紀錄多輪 tool usage 或敏感操作
• phishing link creation：誘導產生表面正常、實際導向惡意位置的連結
• remote script execution：下載並執行遠端腳本，直接往 code execution 走

這四種攻擊很聰明，因為它們不是停在「模型有沒有中計」，而是一路往 data access、surveillance、user deception、RCE 這些真正有後果的層級推進。這比只比對模型答錯幾次更像 production risk。

這篇最值得記的發現：client 差異大到離譜

作者最有殺傷力的發現，是不同 MCP client 的安全落差非常大。

論文直接點名：最安全的一批是 Claude Desktop 與 Cline；最脆弱的是 Cursor；其他像 Continue、Gemini CLI、Claude Code、Langflow 則落在部分保護、但仍有明顯缺口的區間。

這裡真正重要的不是品牌八卦，而是這個結論背後代表的結構性訊號：

• client choice matters more than many teams think
• 同一類模型，接在不同 client 上，安全結果可以從接近 0% 攻擊成功到 100% 成功
• 光討論模型能力、拒答能力或 alignment，遠遠不夠

這其實很像近幾篇 agentic security 論文一直在講的那條線：真正該治理的不是 model output 這一點，而是從 metadata ingestion、context construction、approval UX、parameter visibility 到 execution boundary 的整條控制鏈。

為什麼很多 client 會失守？

這篇把幾個常見 failure mode 講得很清楚。

1. 大多數 client 根本沒有做像樣的 static validation

論文指出，7 個 client 裡有 5 個幾乎沒有真正落地的 static validation，剩下 2 個也只是部分補強。這代表什麼？代表大量 client 在面對 server 回傳的 tool metadata 時，基本上還是抱著「先信、再說」的態度。

如果你的架構預設 tool description 是說明文字，不是攻擊載體，那你就已經輸一半了。因為在 agent 世界裡，自然語言描述本身就是控制面的一部分。

2. 參數可見性很差，approval UI 只是看起來像安全機制

論文很實際地點出一個產品層細節：就算某些 client technically 會把所有參數顯示在 approval dialog 裡，也常常要橫向捲動才看得完。 這種 UI 對真實使用者幾乎等於沒防，因為 approval fatigue 一來，大家就直接按 approve 了。

這點我很認同。很多團隊把「有 approval」誤當成「有人類監督」，但如果：

• 內容太長
• 重要欄位被折起來
• 惡意參數埋在視窗外
• workflow 本來就要連按很多次

那這種 approval 比較像是把責任轉嫁給使用者，而不是一個可靠控制。

3. client 把 metadata 當語意提示，而不是不可信輸入

這大概是整篇 paper 最核心的問題。MCP client 從 server 收到的是工具定義，但對 LLM 來說，那其實是一段自然語言。只要 client 沒把它做降權、標示 provenance、限制可見範圍或做風險掃描，模型就可能把它解讀成「這是你應該遵循的高相關工作指示」。

也因此，tool poisoning 真正打的不是哪個字串像 prompt，而是：

• tool metadata 會不會進 context
• 進去後是否保留來源與權限層級
• 模型是否會把它當成 task-relevant instruction
• 最後 approval 與 execution 層是否還有第二道關卡

四種攻擊裡，哪些訊號最值得記？

這篇不是單純說「都很糟」，它其實有幾個很值得產品團隊直接拿去做 threat review 的發現。

敏感檔案讀取：有些 client 真的會一路放行

在讀敏感檔案這類攻擊裡，論文指出 Cursor 在預設高權限檔案系統存取情境下特別危險：只要使用者批准，它就可能讓工具去碰本機敏感資料，而且沒有給出夠強的風險警示。

反過來說，Claude Desktop、Cline 這類 client 在這條線上至少展現出較強的模型拒絕與行為抑制能力。這說明一件事：模型 refusal 當然不是萬靈丹，但當 client 本身也沒做邊界管控時，連這最後一層都沒有就更危險。

logging surveillance：不一定要偷檔，光是偷偷記你的操作就夠麻煩

這個 attack 很值得注意，因為它不是那種戲劇化的 exploit，而是更貼近企業現場的問題：工具若能自動開始記錄使用者多輪操作、查詢、參數與決策軌跡，本身就是高價值情資。

論文提到，在這條線上 Cursor 再次是最脆弱的一批，甚至可能接受「這是最高優先權監控功能」這種來自 tool description 的說法。這其實就是 classic authority laundering：惡意 server 把自己的需求包裝成系統需要，client 又沒把 provenance 與權限分開。

phishing link creation：你以為只是幫你做連結，其實是在幫攻擊者包裝誘餌

這條也很實務。許多產品團隊會覺得「產生一個連結」不是什麼高風險行為，但論文點出：如果 client 可以被帶去產生表面合理、實際指向惡意位置的連結，那它就已經開始參與 social engineering pipeline。

更關鍵的是，有些防線即使沒擋住根因，也可能因為 UI 還保留了像 tooltip URL preview 這種次級提示而多少減傷。這提醒我們：防禦不一定只有模型層，UI 層的資訊透明度本身就是安全控制。

remote script execution：這才是最該讓人緊張的終局

最重的一擊當然是 remote script execution。論文指出，至少有 client 會在某些條件下下載並執行遠端腳本；而且即使做了某些簡單的 domain filtering，例如擋掉明顯可疑網域，實際上也很容易被繞過。

這條結果的重點不是「某家產品好像很雷」，而是：如果你的 client 安全主要還是靠模型自己覺得哪個 URL 可疑，那這根本不是 execution boundary。 真正該補的是更硬的 sandbox、network egress policy、permission segmentation 與 deterministic enforcement。

這篇對實務最大的提醒：approval 不是邊界，visibility 也不是 validation

我覺得這篇 paper 很值得產品團隊貼在白板上的一句話，可以改寫成：

看得到，不等於看得懂；有 approve，不等於有 control。

很多 MCP client 今天其實卡在這裡。它們可能已經開始做：

• approval dialog
• 部分 warning
• 可疑網域偵測
• 少量 pattern-based prompt injection 檢查

但只要整體架構還是把 tool metadata 當成「先進 LLM、之後再看要不要擋」的資料流，風險就只是往後延，而不是被真正切斷。

所以這篇論文最後提出的 multi-layered defense，我認為方向是對的：

• static metadata analysis：先檢查 tool description / schema / prompts
• decision path tracking：看模型到底是被哪段 metadata 帶偏
• behavioral anomaly detection：觀察是否偏離正常 task intent
• user transparency mechanisms：讓使用者真的看懂高風險參數與動作

真正有效的方向不是只做其中一層，而是把它們串成 control chain。

我怎麼看這篇？

如果只看論文表面，這像是一篇 MCP client security evaluation；但如果再往下看一層，它其實是在提醒整個 agent 生態一個更大的問題：

Agent 的控制面，早就不只在 system prompt，而是分散在 tool metadata、parameter schema、UI approval、環境設定與 execution harness 的每個角落。

這也是為什麼我覺得這篇很值得接在最近幾篇 MCP / tool poisoning / runtime security 文章之後。因為它剛好把幾條線收斂起來：

• 不是所有 prompt injection 都發生在 user prompt
• 不是所有惡意控制都發生在 runtime output
• 不是所有風險都能靠更乖的模型解決
• client architecture 與 approval UX 本身就是 security posture

如果你今天在企業裡評估 MCP adoption，我會說這篇 paper 的核心結論可以濃縮成一句：

真正該審的，不只是你接了哪些 MCP servers，而是你的 client 到底拿什麼方式在相信它們。

結語

Model Context Protocol Threat Modeling and Analyzing Vulnerabilities to Prompt Injection with Tool Poisoning 這篇論文最重要的貢獻，不只是列出 57 個 threat，也不是只證明幾個 client 會中招；而是它把 MCP security 的焦點從「server 可不可信」再往前推一步，變成 client 怎麼處理不可信 metadata、怎麼讓使用者看見真正重要的風險、怎麼在 action 落地前做結構性阻斷 這些更接近實作真相的問題。

對我來說，這篇真正值得記住的句子是：

在 MCP 世界裡，工具描述不是說明文件而已；它常常就是 agent 控制面的另一種長相。

只要這件事還沒被很多 client 當真，tool poisoning 就不會只是論文題目，而會繼續是 production 風險。