模型上下文協議（MCP） 是一種讓大語言模型（LLM）與外部工具、數據源打通的機制，能夠讓模型不再局限于內部知識，而是可以實時調用各種工具、訪問各種文檔。隨著AI技術的不斷發展，MCP的應用也日益廣泛，OpenAI、Anthropic和微軟等主要AI技術公司都開始采用它，已然成為了實現第三方數據、工具與AI智能集成的事實標準。

然而在MCP應用爆火的背后，現實遠比設想的要復雜。由于MCP在設計之初并未定義統一的安全認證機制，各MCP服務器在威脅防護方面參差不齊，組織只要接入了MCP，就可能在數據安全、調用邏輯、用戶預期以及性能表現等方面出現各種安全隱患。在本文中，收集整理了已被真實驗證的MCP應用10大安全風險隱患，并給出了相應的安全防護建議。

1、跨租戶數據暴露

這一安全威脅與跨站腳本攻擊類似，攻擊者可借此訪問其他租戶（包括內部團隊、合作伙伴和客戶）的數據。事實上，已有科技公司在其 MCP 服務器實現中被發現存在該安全威脅，這為所有部署 MCP 服務器的企業敲響了警鐘。

安全建議：為防范此類風險，企業應確保 MCP 服務器嚴格執行租戶隔離，并采用最小權限訪問原則。

2、AI寄生攻擊

攻擊者會偽裝成員工、合作伙伴或客戶，向人工客服發送包含隱藏提示注入的請求，這些注入的指令只有 AI 能夠讀取。當人工客服將請求轉交 AI 助手后，AI助手憑借與 MCP 服務器的連接，可訪問到能接觸敏感數據和業務流程的工具，進而被攻擊者利用實施惡意訪問行為。這并非理論上的威脅，實際上有很多擁有先進技術的科技公司也都受到其影響。

安全建議：企業應該通過限制 AI 操作的最小權限、實時分析提示中的可疑內容以及記錄 MCP 活動審計日志等方式來防范。

3、工具中毒

初次搭建 MCP 服務器并非易事，好在有大量現成的服務器可供使用，目前谷歌上可被檢索的MCP 服務器目錄已列出超過 15,000 個應用。但這些從網上下載的 MCP 服務器在安全性方面卻未必可靠，可能存在惡意指令。比如，Invariant Labs實驗室曾實際演示了惡意MCP服務器是如何通過在描述字段添加惡意指令，繞過加密和安全措施從其他系統提取信息。而且，這種惡意指令不僅存在于描述字段，還可能出現在函數名、參數、錯誤信息等通過MCP服務器生成的各類信息中。

安全建議：組織要判斷下載的 MCP 服務器是否惡意，應首先檢查其來源是否為可信組織，然后再查看其請求的權限是否合理，如僅提供貓咪搞笑圖片的服務器無需訪問文件系統。若有可能，還應該完整審核其源代碼。MCP 服務器在被信任后，也可以通過更新被植入惡意代碼，因此定期進行安全復查是十分必要的。

4、借助可信平臺的惡意代理流

有很多可信的公共平臺（如 GitHub）可讓攻擊者注入惡意提示，當企業的AI代理按常規處理這些內容時，就會通過可信的MCP服務器訪問敏感數據。例如，攻擊者在公共代碼倉庫創建含提示注入的 issue，AI代理在檢查該 issue時，可能會按照注入的指令，通過 GitHub MCP 服務器訪問私人倉庫的私密數據。盡管 GitHub 服務器本身未被直接攻破，卻成了輔助攻擊的第三方渠道。研究人員利用 Anthropic 的 Claude Desktop 演示了這一攻擊向量，盡管平臺默認要求用戶確認每次工具調用，但許多用戶仍會選擇 “始終允許”的確認策略，從而增加了風險。

安全建議：清晰記錄第三方工具行為，使用戶在授權前了解每個工具的功能；同時將工具限制在預先批準的操作范圍內，監控異常或意外行為，防止工具被污染。

5、令牌竊取與賬戶接管

Pillar Security 最新發布的安全報告指出，若攻擊者獲取了MCP 服務器中存儲的未加密 OAuth令牌，就能用該令牌創建自己的MCP 服務器實例。這些OAuth令牌可能因存儲在未加密的配置或代碼文件中，被攻擊者通過后門、社會工程學等方式竊取。以 Gmail 為例，攻擊者可借此訪問受害者的全部郵件歷史、發送偽造郵件、刪除郵件、搜索敏感信息及設置轉發規則等。且與傳統賬戶入侵可能觸發可疑登錄通知不同，通過MCP服務使用被盜令牌看上去就是合法的 API 訪問，難以被安全機制檢測到。

安全建議：企業需要加密存儲常用的OAuth 令牌，并防范相關竊取；使用即時訪問、持續驗證和行為監控來最小化風險。

6、組合鏈攻擊

未經檢查的MCP服務器可能有隱藏的深層惡意指令。如果用戶下載并使用第三方MCP服務器，而沒有驗證其中數據的來源，則可能向第二個遠程MCP服務器發送請求。CyberArk將這種MCP服務器攻擊向量稱為“組合鏈攻擊”。第二臺MCP服務器可以返回有效輸出以及隱藏的惡意指令，第一臺服務器將這些信息與自身的響應合并，然后將所有內容發送給AI代理，后者就會執行這些惡意指令。如果組織在其網絡環境中存儲了敏感數據，攻擊者可能利用此方法進行數據竊取，而受害者甚至從未直接與惡意的MCP服務器建立連接。

安全建議：遵循縱深防御和零信任原則，不假設隱式信任，持續驗證和授權每個MCP交互；結合多層安全控制全面保護MCP環境。

7、用戶同意疲勞攻擊

很多企業開始要求對AI代理的訪問行為進行審批，這當然是一種安全防護措施，卻實際上可能產生反效果。Palo Alto 安全專家表示，已經發現一些惡意MCP服務器會向AI代理及其用戶發送大量無害請求（如多次讀取權限申請），使用戶逐漸放松警惕。這種攻擊方式與多因素認證疲勞攻擊類似，都是利用用戶在持續提示下的某些細微疏忽。在其變體采樣攻擊中，惡意指令會隱藏在冗長的消息中，讓人工審核時難以發現，無論是直接發送給LLM的消息還是其返回的結果中，都可能存在這種情況。

安全建議：

應提供清晰、透明的用戶界面，實施精細的同意選項，使管理人員能夠基于每個訪問操作來合理審批、控制權限。

8、管理權限繞過威脅

在這種攻擊模式中，企業往往設置了一個無需進行身份驗證的MCP服務器，就像很多組織會設置MCP服務器用于其文件目錄管理，以便用戶通過AI代理輕松查詢信息一樣。如果用戶僅被允許以低級別權限訪問這些信息，但MCP服務器并不檢查發起初始請求的人員的身份，那么AI代理就可能獲取到超出個人被允許知曉的范圍的信息。如果此MCP服務器也暴露在外部用戶（如業務合作伙伴、客戶，甚至公眾）面前，這種特權提升就可能會造成巨大的損害。

安全建議：集中記錄所有重要的MCP事件（工具調用、數據請求、錯誤）以供分析和審計；實施持續監控和異常檢測，及早識別可疑的MCP活動。

9、命令注入威脅

現在很多 MCP 服務器實現方式基本上就是“照著用戶的輸入直接執行代碼”，因為按傳統的安全防護思路來看，MCP 里的動作本來就是用戶自己定義、自己控制的，不需要管控。而如果MCP服務器在沒有適當驗證的情況下直接將用戶輸入傳遞給其他系統，那么就可以以類似SQL注入的方式注入自己的攻擊命令。攻擊者會全面尋找并利用MCP服務器暴露的所有工具中的命令注入漏洞發起攻擊。

安全建議：

要對MCP服務器的用戶輸入進行安全審查和控制，不能直接傳遞給shell命令，而是應該使用正確的輸入驗證和參數化命令。

10、影子工具威脅

組織面臨未經安全團隊知曉私自安裝的MCP服務器（"影子MCP"）風險，這帶來了安全盲點和未監控的訪問路徑。這些影子MCP可能被利用于未授權訪問、數據泄露或意外破壞性操作。當 AI 代理可訪問多個 MCP 服務器時，其中一個服務器可能誘使代理不當使用另一個服務器。Solo.io 公司CTO Christian Posta 在其研究中就特別提到了這種惡意MCP攻擊方式，他指出企業需重點加強對AI代理操作行為的監控，并定期檢查不同MCP服務器之間的異常交互。

安全建議：部署統一的MCP服務管理工具；結合數據丟失防護(DLP)技術，如基于模式的編輯和與DLP系統集成，防止數據泄露。

參考鏈接：https://www.csoonline.com/article/4023795/top-10-mcp-vulnerabilities.html