跳到主要內容
/閱讀約 5 分鐘/
mcpai-securitysupply-chain-securityai-agentprompt-injection

MCP 的工具描述也要當成程式碼審查：Tool Poisoning 怎麼防

avatar
Akira@akiraxtwo

MCP 讓 agent 連接工具，也讓工具描述成為新的指令注入面。Invariant Labs 的 Tool Poisoning 研究提醒我們：接上一個 MCP server，不只是安裝整合，而是把一份可影響 agent 行為的規格載入系統。

目錄+

把 MCP server 加進 Claude Code、Cursor 或自建 agent，很多人仍把它想成「多裝一個 connector」。更精確的說法是：你把一組工具名稱、參數 schema 與自然語言描述送進模型的推理上下文，並允許它影響後續行動。

這正是 Tool Poisoning 的危險之處。Invariant Labs 在 2025 年公開的研究指出，惡意指令可以被放在 MCP 工具描述中；使用者看見的是一個合理的工具名稱，模型讀到的卻可能包含誘導它讀取敏感資料、選錯工具或執行未授權動作的文字。今天的貼文再度提起這個風險，但它不該被當成單一事件新聞，而應該改變團隊安裝 MCP 的流程。

MCP 的攻擊面不只在工具程式碼

傳統套件安全主要看 dependency、原始碼、簽章與權限。MCP 多了一層容易被低估的東西：模型會閱讀的工具 metadata。即使 server 本身沒有明顯惡意程式碼，描述文字仍可能引導模型做出危險選擇。

這是一種典型的 confused-deputy 問題。模型擁有使用者授權的工具權限，卻可能因為外來文字而把權限用在使用者沒有意圖的地方。最糟的情況不是它回了一段奇怪文字，而是它真的碰了檔案、GitHub、雲端憑證或內部資料。

因此，工具描述不能再被當成純 UI copy。只要它會進模型 context，就應視為可執行策略的一部分。

不要把「模型很聰明」當成防線

今天的貼文提到某些模型會跟隨藏在描述中的指令。該貼文的百分比沒有在本文使用，因為單一測試設定不足以代表你選用的模型、client 或工具組合。更重要的是，就算某一模型在某一次測試拒絕了攻擊，也不能把這當成安全保證。

安全控制應該放在模型之外：工具的能力範圍、資料流、明確的使用者核准，以及可稽核的政策層。模型可以協助判斷，但不應成為唯一 policy engine。

一個可落地的 MCP 安裝流程

對團隊來說，最實用的改變是把 MCP server 納入和依賴套件相近的審查程序。

  1. 只從可識別的來源安裝。 記錄 server 的來源、版本、維護者與實際能力；避免把搜尋結果裡的任意安裝指令直接貼進開發環境。
  2. 審查 manifest 與工具描述。 特別留意要求讀取環境變數、SSH 金鑰、雲端憑證、全域檔案或把資料送往外部網址的描述。長得像說明文字的指令，仍是指令。
  3. 縮小可用權限。 給 agent 獨立、短效且最小範圍的 token；不要讓一個研究型工具同時拿到 production GitHub、雲端與客服資料。
  4. 為有副作用的動作設核准點。 讀取、發送、刪除、部署與變更權限應有不同門檻。高風險行動需要顯示將要使用的工具、參數與目標。
  5. 把變更納入持續檢查。 MCP server 的工具清單與描述會改變。要記錄版本、比較 diff，並在更新時重新審查，而不是只在第一次安裝時看一眼。

Invariant Labs 的 MCP-Scan 可以協助掃描本機 agent 環境與潛在 toxic flows，但它是輔助檢查，不是讓團隊跳過權限設計的通行證。

先做一個小型演練

本週可以做的第一步很簡單：列出團隊目前啟用的 MCP servers，為每一個填寫「它讀什麼、寫什麼、用什麼憑證、失敗時誰會知道」。如果無法在幾分鐘內回答，就先不要再加新的 server。

接著挑一個低風險環境，以唯讀權限跑一次掃描與描述 diff。目標不是抓到某個神祕後門，而是建立一個明確習慣：MCP integration 是供應鏈元件，也是 agent policy 的輸入。

來源與閱讀