你的代理，信任所有你接上去的東西
現在大多數獨立開發者，都在跑一個握有真實權限的 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 註解中、在渲染檢視下看不見的、對模型說的文字。 這份清單幾分鐘就能查完。最後兩項是最多人漏掉的，因為它們的運作方式，就是讓正在做審查的那個人看不見。 ...
