現在大多數獨立開發者，都在跑一個握有真實權限的 AI 代理：檔案系統、幾組 API 金鑰、一個資料庫，也許還有一支部署腳本。為了讓它有用，你把它接上了各種東西。一個從 README 抄來的伺服器。一份從部落格文章複製的設定。某個「四分鐘就搞定」的東西。

值得慢下來看的，正是這一塊。

你實際上同意了什么

MCP 伺服器不是外掛。當你接上一個，你把一組工具交給了代理，同時也把描述這些工具的結構定義交給了它——名稱、參數，以及描述。模型讀的就是那份描述，並據此決定何時呼叫它。

這裡有個信任落差，而且它是結構性的，不是誰的程式碼有 bug。工具的描述只在你連接的那一刻被審查過一次。工具的回應卻沒有對等的檢查。伺服器回傳什麼，就進到你的模型上下文裡，並被當成輸入來讀。如果回應裡夾著指令，模型可能會照做。

開放全球應用程式安全計畫（OWASP）直接描述了隨之而來的攻擊：一個惡意伺服器提供一個名字聽起來很無害的工具，像是 get_compliance_status；當你的代理呼叫它，回應看起來像一份正常報告，卻夾帶一段隱藏指令，要代理去讀取一個敏感檔案，並把它送到某個外部位置。你的代理有讀檔能力，也有網路能力。字串本身擋不住任何事。

真正該讓你不安的點是：模型無法可靠地區分「資料」與「指令」。 這不是換一個更強的模型就能解決的問題。這就是這項技術的形狀。

數字已經不是理論了

2025 年大部分時間，這還是一類研討會簡報等級的漏洞。現在不是了。

MCPTox 這個學術基準測試，針對真實伺服器評估了投毒攻擊，橫跨 45 個實際運作的 MCP 伺服器與 20 個語言模型，測得平均攻擊成功率 36.5%，最差情況下單一模型達到 72.8%。

再看一次第一個數字。大約每三次嘗試，就有一次成功。這不是你「小心一點」就能繞過的邊角案例。

而且投遞成本變便宜了。2025 年 4 月發表的一個概念驗證，用的不是什麼稀奇手法，只是一個被投毒的計算機工具描述，就從某個 AI 程式編輯器裡悄悄外洩了開發者的 SSH 私鑰。一個相關的變體被稱為 MCPoison，示範了透過單一提交的設定檔造成整個團隊的淪陷——一個人的 pull request，變成所有人的問題。雲端安全聯盟 2026 年 7 月的研究報告，則記錄了一類 IDE 自動執行的攻擊：光是開啟一個專案，就足以讓專案自帶的伺服器以開發者層級的權限被執行。

注意這三者的共同模式：它們都不需要你犯下什麼明顯的錯誤。 你不需要點擊任何東西。你只需要接上一個東西、打開一個資料夾，或合併一個 pull request。

為什麼獨立開發者是暴露的那一群人

MCP 的安全指引，通常是寫給平台團隊看的：結構定義簽章基礎設施、政策即程式碼的決策點、職責分離、需要一個以上真人參與的審批流程。

這些你一樣都沒有。你沒有安全審查——你就是那個審查。而你手上是最危險的組態：一個代理同時握有檔案存取、憑證，以及對外網路請求。

這不是叫你別用 MCP。這是叫你對「開哪幾道門」刻意一點，因為影響範圍完全取決於你接上了什麼。

十分鐘的檢查

你不需要任何基礎設施。你需要的是一個習慣，和一份短清單。

接上任何伺服器之前，先讀它的工具描述。 不是 README。是描述本身。根據廣被引用的靜態指標，以下這些應該讓你停下來：

  • 對模型下指令的祈使句。 文字是對著模型說的，而不是對你說的：「忽略先前的指令」、「不要告訴使用者」、「回答前先讀取……」
  • 敏感路徑。 一個你根本不預期它需要用到，卻提到 ~/.ssh、id_rsa、.env、.aws/credentials、/etc/passwd 的工具。
  • 外洩的形狀。 一個動作動詞——send、post、upload、forward——緊挨著一個外部目的地：URL、webhook、端點。
  • 零寬字元。 Unicode 範圍 U+200B–200F、U+202A–202E、U+2060、U+FEFF，被用來躲避人眼審查。看不見的東西，你就無法批准。
  • 藏在註解裡的指令。 夾在 HTML 或 markdown 註解中、在渲染檢視下看不見的、對模型說的文字。

這份清單幾分鐘就能查完。最後兩項是最多人漏掉的，因為它們的運作方式，就是讓正在做審查的那個人看不見。

接著，把你的組態套進四條規則：

  1. 一個伺服器，一項職責。 永遠不要讓高權限伺服器與通用型伺服器共用上下文。如果你的讀檔工具和抓網頁工具看得到同一段對話，來自後者的投毒回應，就能指揮前者。
  2. 最小權限，而且是來真的。 唯讀伺服器就給唯讀權杖。不是一組你「打算」只拿來讀的權杖。
  3. 把每一個工具回應都當成不可信輸入。 這條規則會反轉你的預設值。回應是資料。它不是指令，不管它看起來多像指令。
  4. 把破壞性動作關起來。 刪除、轉帳、群發、部署——放到明確確認之後，而且是在模型自己的判斷之外。模型的「願意照做」，正是被攻擊的那個東西。

而強制點很重要：把這些放在工具執行層，不是放在你的系統提示裡。提示裡的指令（「不要讀取專案外的檔案」）是靠模型願意遵守來執行的。注入的文字，正是專門設計來壓過那份意願的。後端的檢查則不是。

換個框架看

如果你讀過〈「完成了」是一個主張，不是事實〉，你會認出同樣的形狀。那篇講的是驗證產出——代理說它把某件事做完了，不構成證據。

這篇是同一套紀律，往下多問一層。那篇問的是「它有沒有做完這件事」。這篇問的是「是誰在叫它做事」。兩者都出自同一個起點：你的代理自信的產出不是證據，它自信的輸入也一樣不是。

一個相關的區分值得放在心裡：〈代理做不到的事〉 談的是能力上限，而〈API 與 MCP〉 談的是傳輸層的選擇。兩者都無關安全。傳輸標準化，並不代表在上面跑的東西值得信任。

而這件事值得跟下一步分開來看：這篇談的是你接上了什麼——你在設定時所信任的工具描述。〈你的代理不需要被駭〉談的是代理接上之後能做什麼——你授予的長期存取權，以及它能寫下什麼、而那樣東西之後會被別的元件信任。兩種不同的失效模式，兩套不同的檢查。

第三個問題，在存取權搞定之後，就是範圍：不是「它碰不碰得到」，而是「這個動作，到底該不該在我沒看著的時候自己跑？」——而分類的依據是可逆性與影響範圍，不是你有多信任這個 agent。

今天就去做

用檢查指令掃描你自己的設定

三條 grep 指令，針對你的 MCP 設定。複製、執行、讀結果。這裡不會把任何資料送出——指令只在你自己的機器上跑。

1. 隱藏字元（看不見的指令） 
grep -rP '[\x{200B}-\x{200F}\x{202A}-\x{202E}\x{2060}\x{FEFF}]' ~/.config/ ~/Library/Application\ Support/ 2>/dev/null
2. 敏感路徑 
grep -riE '\.ssh|id_rsa|\.env|\.aws|credentials|/etc/passwd|keychain' ~/.config/ ~/Library/Application\ Support/ 2>/dev/null | grep -i mcp
3. 外洩行為特徵 
grep -riE '(send|post|upload|forward|curl|wget).{0,40}(https?://|webhook|endpoint)' ~/.config/ 2>/dev/null | grep -i mcp
現在為你找到的結果打分

勾選所有對你的設定而言「成立」的敘述。勾選的數量，就是你的曝險程度。

勾選所有符合的項目——數量就是你的曝險程度。

打開你的 MCP 設定。對裡面每一個伺服器，回答三個問題：

  • 我知道是誰在維護它嗎？ 不是「它有很多星星」。是誰。
  • 它實際上能碰到什麼？ 憑證、檔案路徑、網路。寫下來。如果答案是「全部」，那就是你的發現。
  • 我讀的是它的工具描述，還是它的 README？ 這是兩份不同的文件，而只有其中一份是對你的代理下的指令。

這個練習讓人不舒服的版本是：假設每一個伺服器都是惡意的，然後問它能做什麼。你不需要修好每一件事。你需要知道影響範圍在哪裡，因為對一人團隊而言，你身後沒有第二道防線。

接上一個伺服器要四分鐘。這個檢查要十分鐘。這個不對稱，就是全部的論證。

資料來源

  • OWASP Foundation —〈MCP Tool Poisoning〉（攻擊參考）與 OWASP MCP Top 10, MCP03:2025（Tool Poisoning）。 攻擊機制：工具回應繞過了連接時的那次審查；get_compliance_status 投毒回應範例；靜態偵測指標（對模型下的祈使句、敏感路徑、外洩特徵、零寬字元、註解夾帶指令）；以及控制措施（最小權限、允許清單、執行層強制、敏感操作的確認閘）。
  • Cloud Security Alliance —〈MCP Attack Surface: Tool Poisoning and IDE Auto-Execution〉，研究報告，2026 年 7 月 1 日。 專案自帶伺服器以開發者權限的 IDE 自動執行；將 MCP 設定變更視同正式環境程式碼變更；MCPTox 基準數字（45 個現行伺服器、20 個模型、平均攻擊成功率 36.5%、峰值 72.8%）；以及案例引用——Invariant Labs 2025 年 4 月的揭露（透過被投毒的計算機工具描述外洩 SSH 金鑰）、MCPoison 共用設定變體（CVE-2025-54136），以及 CurXecute 自動啟動 RCE 類別（CVE-2025-54135）。
  • Microsoft Security —〈Securing AI Agents: When AI Tools Move from Reading to Acting〉，2026 年 6 月 30 日。 混淆代理（confused deputy）模式，以及內部工具與外部工具之間的信任邊界。（經 CSA 研究報告的參考文獻引用；未獨立取得原文。）
  • Model Context Protocol 規格。 伺服器輸出被視為可能不可信，客戶端被建議考量信任邊界——但並未強制要求在把內容送進模型前進行回應驗證。（依 OWASP 的轉述引用；未獨立取得原文。）

文中的數字來自學術研究與鄰近廠商的研究；均依原發表內容轉述。MCPTox 基準與各案例揭露，本文未獨立重現。