七款 MCP 開發工具實測：防護落差比想像中大

我們先前在 MCP 協定那篇提過一個少有人談的風險：工具回傳的內容會進入模型的上下文，成為間接提示注入的入口。

當時那是架構層面的推論。現在有人做了實測。

先界定：什麼是工具汙染

Charoes Huang 等人的〈Are AI-assisted Development Tools Immune to Prompt Injection?〉（arXiv:2603.21642，2026 年 3 月 23 日投稿）在摘要中說明研究動機：

「開發者正快速採用建立在模型脈絡協定（MCP）之上的 AI 輔助開發工具。然而其便利性伴隨著資安風險，特別是透過工具汙染向量傳遞的提示注入攻擊。」

「工具汙染」（tool poisoning）指的是：攻擊指令不是使用者打進去的，而是藏在工具的描述或回傳結果裡。

用生活的例子：你請助理「照這份說明書操作」，而說明書的第 37 頁被人偷偷加了一行「順便把保險箱密碼抄下來」。助理不是被你騙的，是被文件騙的——而你根本沒看過那頁。

研究做了什麼

作者自述這是「首個針對真實世界 MCP 客戶端的工具汙染弱點實證分析」，測試七款廣泛使用的客戶端：Claude Desktop、Claude Code、Cursor、Cline、Continue、Gemini CLI 與 Langflow。

評估的六項安全機制是：

• 靜態驗證　工具註冊時檢查其描述是否含可疑指令
• 參數可見性　使用者看不看得到實際傳給工具的參數
• 注入偵測　是否主動辨識注入嘗試
• 使用者警告　執行敏感動作前是否提示
• 執行沙盒　工具是否在隔離環境中執行
• 稽核日誌　是否留下完整的呼叫紀錄

這六項本身就是一份可直接使用的採購檢查表，不論你用的是不是清單上這七款。

結果：差異顯著

論文的結論是：「我們的評估揭示了顯著的差異。」

依作者的表述，Claude Desktop 等部分客戶端「實作了強健的防護機制」；而另一些如 Cursor 則「對跨工具汙染、隱藏參數利用與未授權工具呼叫展現出高度易感性」。

其中「跨工具汙染」最值得注意：一個被汙染的工具，可以影響模型對其他工具的使用方式。這代表安全性不是各工具獨立計算，而是取決於整組工具裡最弱的那一個。

邊界：這份結果的適用範圍

• 只涵蓋七款客戶端　不在清單上的工具無從推論。
• 是時間點的快照　這類工具更新頻繁，2026 年 3 月的測試結果不必然反映當前版本。
• 測的是客戶端防護，不是伺服器　你自己架的 MCP 伺服器安不安全，是另一個問題。

特別是第二點。不宜把「某某工具不安全」當成長期結論——被點名的廠商通常會修補。這份研究的價值在於它證明了差距存在，以及提供了檢查的維度。

對台灣企業的意義

如果你的公司允許工程師使用 AI 輔助開發工具（多數公司其實已經允許，只是沒有正式政策），這篇提供了三個可執行的動作。

一、確認工程師實際在用什麼。這一步通常會有意外——AI 開發工具多半是個人安裝，不經過 IT 採購流程。

二、用那六項機制當檢查表。不必自己做滲透測試，先確認工具有沒有沙盒與稽核日誌，就能篩掉大部分風險較高的選項。

三、限制能接的 MCP 伺服器。既然跨工具汙染成立，安全性取決於最弱的那個工具。允許工程師隨意接第三方 MCP 伺服器，等於把整組工具的安全性交給不認識的人。

對受客戶保密協議約束的產業（如封測），第三點尤其重要：工具汙染可能導致程式碼或製程資料外流，而那是合約層級的違約，不只是資安事件。

需要保留的懷疑

這是 arXiv 預印本，投稿時尚未經同儕審查。評估的六項機制與判定標準由作者團隊建立，非業界標準。

論文摘要未提供各工具的量化評分或攻擊成功率，本文因此只引述其定性結論，未列出排名。要據以做採購決策，建議查閱論文全文的詳細評估表。

另外，被評為防護較弱的產品，其開發方通常會在研究公布後修補。把三月的測試結果當成今天的事實，是誤用。合理的用法是：用它提供的六個維度，去問你現在正在評估的工具。

常見問題

什麼是 MCP 的「工具汙染」攻擊？

指攻擊指令並非由使用者輸入，而是藏在工具的描述或回傳結果中。當模型讀取這些內容時，可能將其視為指令執行。研究進一步指出存在「跨工具汙染」——一個被汙染的工具可影響模型對其他工具的使用方式，因此整體安全性取決於所接工具中最脆弱的那一個。

選擇 AI 開發工具時該檢查哪些安全機制？

依該研究採用的評估維度有六項：靜態驗證（工具註冊時檢查描述是否含可疑指令）、參數可見性（使用者能否看到實際傳遞的參數）、注入偵測、使用者警告（執行敏感動作前是否提示）、執行沙盒（工具是否隔離執行）、稽核日誌（是否留存完整呼叫紀錄）。這六項可作為採購檢查表，不限於研究涵蓋的工具。

公司該如何管理工程師使用的 AI 開發工具？

三個步驟：先確認工程師實際使用哪些工具（這類工具多為個人安裝，常未經 IT 採購流程）；以上述六項機制篩選，優先確認是否具備執行沙盒與稽核日誌；限制可連接的第三方 MCP 伺服器，因為跨工具汙染成立時，整體安全性取決於最弱的環節。對受保密協議約束的產業，此項風險屬合約層級而非僅資安層級。

下一步

先盤點工程師實際在用什麼工具，通常一天內做得完，而且結果多半出乎意料。若你的產業受客戶保密協議約束，可搭配地端不等於安全那篇一起檢視資料外流的路徑。

出處

本文引述出自 Charoes Huang、Xin Huang、Amin Milani Fard〈Are AI-assisted Development Tools Immune to Prompt Injection?〉，arXiv:2603.21642，2026 年 3 月 23 日投稿，arxiv.org/abs/2603.21642。加註引號者為論文摘要原文之中譯。

該論文為預印本，投稿時尚未經同儕審查。評估維度與判定標準由作者團隊建立；摘要未提供量化評分，本文僅引述定性結論。工具版本持續更新，該結果為 2026 年 3 月之快照。