MCP 的信任模型讓一個遭投毒的代理觸及另一個代理
這個已成為串接 AI 代理預設方式的協定，存在信任問題，而在下一次事件發生前，值得先理解其問題的樣貌。
Ars Technica 於 10 月 5 日報導，獨立研究員 Syed Anas Mohiuddin 展示了一類他稱為「協定樞轉」（protocol pivoting）的攻擊。概念很簡單。在網路內部，代理彼此透過 Model Context Protocol（MCP）溝通。防護欄最弱的地方，正是某個代理把任務交給另一個代理之時，因為第二個代理預設信任第一個代理。把惡意指令植入一個缺乏嚴格輸入驗證的翻譯或資料分析代理，它就會把指令往下游傳遞。接收方會照做，因為一個受信任的同事為何要說謊。
Mohiuddin 的概念驗證觸及五個互不相關的組織：Google、JPMorgan Chase、Weviate、Rapid7、法國跨部會數位總署，以及一個美國聯邦機構。這些組織除了大量使用代理之外，幾乎沒有共通點。這正是重點。弱點在於底層管線，而非任何單一產品。
兩個 CVE 與評分落差
具體的漏洞很普通，而這正是這個故事令人不安的部分原因。Rapid7 的 MCP 伺服器帶有 CVE-2026-97228，該公司已於 2026 年 9 月修補，儘管該漏洞評分只有 10 分中的 2.7 分。Google 的問題評分較高，為 8 分，且涉及 googleapis/mcp-toolbox。其 HTTP 用戶端缺乏 CheckRedirect 原則與目標 IP 驗證，因此精心建構的路徑參數可將請求重新導向至內部端點。Google 新增了 IP 允許清單與封鎖清單，並讓該工具箱在啟動時拒絕不安全的基礎 URL。
嚴重性評分的不一致本身就是一堂課。兩個組織在同一套協定中發現了類似的弱點，卻給出截然不同的評分，這顯示業界尚未就代理對代理信任缺口應該付出多少代價達成共識。
並非所有人都接受「協定樞轉」是一個新類別。X41 D-Sec 研究員 Markus Vervier 告訴 Ars Technica，他將其解讀為間接提示注入，也就是安全團隊已追蹤兩年的同一種技術。這種界定很合理，也讓實務問題更加尖銳：針對提示注入的防禦手冊假設輸入來自外部。但在這裡，它來自內部，還帶著內部憑證。
缺口是架構性的，而非修補程式
安全廠商 ClawSecure 的另一份報告把分析推向更深一層。其研究人員測試了 Linear、Notion 與 Dropbox Dash，並主張缺陷在於 MCP 規格本身，而非任何廠商的實作。在 Notion 與 Linear 中，他們發現 MCP 伺服器會在內容建立的當下自動擷取攻擊者控制的連結，過程中完全沒有模型介入。任何對工作區有寫入權限的人都能把它變成洩漏管道，無須精心措辭的提示。
他們的數據很直白。在 20 種混淆技術中，包括零寬 Unicode 與同形異義字，有 17 種在來回過程中存活下來。在來自五個實驗室的 14 個模型中，沒有任何一個能一致阻擋這些威脅；表現最好的 Claude Opus 4.7，仍有約 26.7% 的時間遵循惡意指令。
ClawSecure 販售安全產品，且該報告尚未被獨立重現，因此對其平台層的主張應保持適當謹慎。不過，底層狀況很容易驗證。MCP 每月記錄超過 5 億次 SDK 下載，並有近 16,000 個公開伺服器，而根據某一統計，這些伺服器中只有 8.5% 使用 OAuth。採用速度跑在強化之前。
AWS 在 10 月 2 日發布的公告中提供了自己的證據。其開源 Loom 代理編排平台中的三個缺陷，可能導致未經身分驗證的系統管理權接管、OAuth2 憑證外洩，以及內部服務遭存取。最嚴重的是 CVE-2026-103956，在未設定身分提供者的部署中，可讓任何網路用戶端觸及代理控制平面。Loom 1.6.1 與 1.7.0 版已修補這些缺口。
為何預設信任假設才是真正的發現
撇開 CVE 不談，有一個設計選擇格外突出。代理是為了合作而打造，因此它們會彼此驗證身分，然後表現得彷彿有效憑證也代表有效請求。經典的零信任則主張相反：每一項請求都必須憑自身正當性獲得證明，即使來自周界內部也一樣。
Mohiuddin 的攻擊之所以奏效，正是利用了這種倒置。惡意指令之所以能通過系統之間的授權邊界，恰恰因為它在程式碼中從未跨越任何邊界。它在一張受信任的網狀結構內從一個代理移動到另一個代理，而沒有任何一層留下來質問這項請求是否合理。
團隊本週可以做的事
立即的修補並不光鮮，而且現在就能做到。把任何來自語言模型的指令都視為敵意輸入，不論是哪個代理產生的。強制執行嚴格的重導向處理，並驗證目的 IP。要求每個代理都必須先通過驗證，才能把工作委派給另一個代理，並記錄委派過程，以便事後重建一連串交接。
長期而言，預期標準組織會把協定樞轉列為具名威脅類別，這將推動廠商把零信任檢查內建於 MCP，而非置於其旁。稽核人員也會跟進，而關於代理對代理防護欄的問題，將開始像一個世代前的防火牆規則那樣，出現在合規審查中。
這個故事令人不安之處在於，一旦代理彼此信任，這個手法反而更有效。每個急於透過 MCP 連接自身工具的組織，現在都在建立那張信任網，而且其中大多在搭建時，都沒有為團隊成員到頭來竟在說謊的情況擬定計畫。
為何此事在此刻出現
這些底層技術都不是新的。伺服器端請求偽造與注入漏洞已列在 OWASP 清單上好幾年。改變的是它們運行的位置。代理給了這些舊漏洞新的傳遞途徑，因為代理會樂於依據文件中的一句話、資料庫某一列的欄位，或另一個代理輸出的某一行採取行動。指令不需要由攻擊者親自輸入。它只需要出現在模型會讀取的地方。
這就是為何這項揭露橫跨一家銀行、一個搜尋引擎、一家安全廠商與一個政府總署。它們並未共用程式碼或廠商。它們共用的是同一套架構，而這套架構帶有一種假設：每個參與者都值得信任。MCP 在大約一年內從新奇想法變成關鍵基礎設施，每月下載量以數億計，而通常會伴隨這種成長的安全審查，大多並未發生。
這個故事有一種結局圓滿的版本。漏洞正在修補，協定的管理者也積極回應，而且這些攻擊需要寫入權限或網路內部的立足點，這是相當高的門檻。但真正重要的修補是文化性的，而非技術性的。採用代理的團隊必須停止把有效的內部憑證當成請求合法的證明，並開始把每一項請求都當成來自陌生人般驗證。這比任何修補程式都更難推行，而下一輪事件將考驗的正是這一點。