MCP 不是連結器－它是您在代理時代的治理平台

框架問題：「連接器」一詞低估了您實際做出的決策

2024 年 11 月，Anthropic 公司推出了模型上下文協定 (MCP)，作為連接人工智慧系統、資料來源和業務工具的開放標準。然而，業界對新整合規範的處理方式卻一如既往：將 MCP 歸類為「管道」。適配器、傳輸協議，以及避免為每個模型和工具編寫一次性粘合代碼的簡潔方法，這些都被歸類為 true，但對於首席資訊長 (CIO)、首席技術官 (CTO) 或首席資訊安全官 (CISO) 來說，這些都無關緊要。

以下是企業需要重新建構的框架。當客服人員能夠呼叫讀取客戶資料或寫入記錄系統的工具時，無論你是否為其命名，你都創建了一個新的控制點。 MCP 正是明確定義該控制點的地方。它不僅關乎客服人員如何存取你的工具，更關乎你如何決定誰在呼叫、使用誰的身份、哪些工具可見、如何記錄每次通話以及每次通話的允許費用。這些都是管理問題，而非連結問題。

如果將MCP視為連線功能，您將優化錯誤的目標—覆蓋範圍、整合數量、首次呼叫時間。如果將其視為治理介面，您將優化真正決定代理是否可以安全大規模部署的因素：一個單一的、標準化的、可審計的接口，策略只需執行一次，即可在所有地方生效。

為什麼「眾多自訂整合」會悄悄重塑治理 N 次？

大多數企業在進入代理商時代時並非一無所有。他們往往帶著一套整合方案：這裡一個客製化連接器，那裡一個服務帳戶，還有一個團隊兩個季度前開發的 API 封裝器，現在幾乎沒人記得了。這些方案在當時都是合理的。但加在一起，它們就構成了一個治理問題，因為每個方案都以自己的方式重新實現了身份、授權、日誌記錄和費率/成本控制——或者完全跳過了其中的一些環節。

可以預見的是，三種故障模式隨之而來。首先，身份漂移：一個集成作為共享服務帳戶運行，另一個集成模擬最終用戶，第三個集成使用由更換團隊的人創建的長期密鑰 - 那麼“這是誰幹的？”有N個不同的答案，沒有一個是完整的。其次，授權片段，因為工具可以執行的操作規則存在於具有 N 個審查節奏的 N 個程式碼庫中；你在一個地方收緊的控制在另一個地方卻默默地保持鬆散。第三，財務和審計首先感受到的是數字的變化，因為透過兩個整合路徑回答的相同問題會回傳兩個答案。一旦利害關係人不再信任這些數字，代理計畫就不再重要。

標準化方案並非萬能或免費，但它改變了工作方式。無需管理 N 個整合 N 次，只需管理一個接口，並透過該接口公開工具即可。身份資訊在單一位置建立。授權是介面的屬性，而非每個連接器的習慣。日誌記錄統一，因此審計追蹤真正有效。而且，由於計算方法單一，數據不再波動。

身分和租戶上下文：在入口處決定，而不是在工具中決定

治理介面首先要回答的問題是：呼叫代表誰的權限？在多租戶 SaaS 環境中，這個問題比較微妙，因為其中涉及兩個不同的因素：呼叫者的身分（哪個代理，代表哪個使用者或服務）以及呼叫所在的租用戶環境（適用哪個客戶的資料和權限）。如果將兩者混淆，就會出現經典的「代理權限混亂」錯誤，即一個合法認證的代理被引導去執行它本不應該擁有的權限。

值得遵循的原則是從伺服器端租用戶綁定中取得租用戶上下文，而不是從呼叫者會話中偶然斷言的任何內容中取得。在我們自己的實作中，用於控制功能存取權限的客戶層級是根據租用戶上下文確定的，絕不會從呼叫者的會話中讀取——正是為了防止呼叫者透過提供更豐富的會話資訊來擴大其影響範圍。身分資訊告訴您是誰在提問；租用戶上下文資訊告訴您答案必須在哪些資料和權限範圍內計算。這兩項資訊都在任何工具運行之前確定。

這裡也需要明確說明代理不是使用者。控制台中的使用者有眼睛、會猶豫，並且有經理。而代理則有循環。你賦予它的身份和上下文應該反映出，它可以比你配置的任何用戶更快、更直接地採取行動。

工具授權：曝光是一種選擇，而非預設設定

早期代理部署中最常見和最危險的預設設定是「全有或全無」暴露：將代理連接到平台並讓它到達底層憑證可以到達的所有內容。在演示中很方便，在生產中卻站不住腳。治理介面將每個工具的可見性和權限視為經過深思熟慮的、可審查的決策。

具體來說，授權應該是多軸的，而不是單一的開關。我們使用三軸模型——範圍和層級，層級資訊來自租戶上下文（如上所述）——這樣，只有當呼叫者的範圍允許且租戶的層級包含該工具時，才會公開該工具。第二個軸的意義在於，能力不僅取決於誰在要求，還取決於哪些客戶的授權有效。這確保了權限的公開程度：向目錄中新增工具不會自動使其對所有租用戶中的每個代理程式都可用。

要提供給架構師的思考模型是一個產品目錄，而不是一個總機。目錄中的每個工具都透過決定誰可以呼叫它以及在什麼租用戶條件下呼叫它而獲得其位置。目前代理商不需要的工具根本不在目錄中。 「要麼全有，要麼全無」是一種 false 經濟模式；「根據每個工具進行精心選擇」是唯一能夠經受住真正審核的策略。

失敗關閉策略：讀取與行動之間的不對稱性

讀取和寫入在本質上並不等同，您的管理機制不應假裝它們等同。讀取操作出錯會傳回過時或空的資料－可恢復，通常不可見。寫入操作出錯則會改變記錄系統、向真實客戶發送訊息或轉移資金。犯錯的代價是不對稱的，因此預設姿態也必須是不對稱的。

我們堅持的原則是，寫入工具失敗時預設為關閉。如果授權不明確、租戶上下文無法清晰解析或守衛條件無法評估，則寫入操作不會發生。這與許多整合所繼承的便利性預設設定截然相反，後者會將未評估的檢查解析為“允許”，以確保流程順暢。失敗時預設會打開，可以讓您在幾週後發現某個代理程式在未經批准的情況下進行了寫入操作。對於任何會改變狀態或涉及客戶的操作，安全的預設設定是拒絕，並且舉證責任在於呼叫方，由其證明該操作是允許的。

這裡存在著文化層面的問題。工程師優化的是系統正常運作；安全人員優化的是系統不以最糟糕的方式崩潰。治理層的作用在於明確規定，最糟糕的方式——未經授權的靜默寫入——是不可接受的，即使這意味著偶爾會拒絕一些原本可以接受的寫入操作。

預算帳簿和終止開關：將成本控製作為一項重要控制措施

代理引入了一種傳統整合方式通常不會涉及的風險：自主支出。呼叫工具的循環可能會因為漏洞或惡意提示而導致呼叫次數遠遠超出預期——耗盡 API 預算、觸發下游費用或導致客戶資料過載。因此，成本控制應該納入治理層面，而不是事後作為計費警報附加在造成損失之後。

我們採用的機制是在任何支出之前評估預算帳簿，並設定了每次運行、每天和滾動 30 天的限額，此外還有一個在執行前檢查的終止開關。請注意順序：預算和終止開關是在支出之前評估的，而不是在支出之後進行核對。超支警報是事後分析；拒絕超支通知的帳簿則是一種控制措施。三個時間範圍至關重要，因為故障模式的形式各不相同——失控循環會超出單次運行上限，配置錯誤的計劃會超出每日上限，而緩慢蔓延只有在 30 天的時間窗口內才會顯現出來。

終止開關在設計中應該單獨列出。它是您在不了解情況且需要立即停止活動時可以使用的控制選項。它在執行前進行評估，是一種斷路器，而不是清理工具。每個代理程式都應該能夠立即回答一個問題：我們如何停止它？如果答案需要通知三個團隊並手動撤銷金鑰，那麼您沒有終止開關——您只有希望。

審核與編輯：範圍明確、時間限定且可觀察

無法被觀察的治理並非真正的治理，而是意圖。最終的治理層使得其上層的一切事後都可驗證。代理密鑰應限定在實際需要的工具範圍內，並設定時間限制，以便憑證的失效範圍按計劃逐步縮小至零，而不是無限期地存在。一個可以永久執行任何操作的金鑰，是事件審查中最常見的遺留問題。

同樣，審計追蹤本身也必須尊重其記錄的數據。我們採用逐次呼叫脫敏技術，確保日誌能夠準確記錄事件經過——使用何種工具、在何種身分和租戶環境下、以及最終結果——而不會成為控制措施旨在保護的敏感資料的副本。悄悄累積明文客戶記錄的稽核日誌並非控制措施，而是披著善意外衣的新風險。

這些特性——作用域金鑰、時間限制、每次呼叫時的脫敏處理、統一審計——共同幫助首席資訊安全官 (CISO) 回答事件發生後實際會遇到的問題：此憑證可以做些什麼？可以持續多久？它實際做了什麼？以及我們能否在不洩漏更多資訊的情況下證明其有效性？

將其與持續風險掛鉤—並坦誠面對剩餘的風險

這一切都不是一次性的設定。 NIST 人工智慧風險管理框架 (AI RMF 1.0) 明確指出，人工智慧風險管理是一個持續的過程，而不是一份填寫完畢後就束之高閣的清單。治理介面之所以有價值，正是因為它為持續治理流程提供了一個統一的操作平台：當出現新的風險時，您只需在一個介面中調整授權、預算、風險敞口或審計，而無需在多個整合中疲於奔命。正是這種標準化使得持續治理切實可行，而非僅僅停留在理想階段。也正因如此，深思熟慮的風險敞口決策才能帶來雙重收益——一次是在做出決策之時，另一次則是在每次需要重新審視該決策時。

坦誠面對剩餘風險，因為董事會也會如此。治理機制可以縮小攻擊面，使活動可審計；但它並不能使代理人萬無一失。即使是臨時注入，也可能試圖引導合法授權的代理人進行看似合法的濫用行為。即使故意暴露的工具，在其權限範圍內仍可能被濫用。預算限制了成本，但無法限制判斷。德勤的《企業人工智慧現狀》研究一再表明，人工智慧的雄心壯志與治理人工智慧的營運成熟度之間存在差距——而這些剩餘風險恰恰存在於此差距之中。正確的應對措施不是聲稱差距已經消除，而是要縮小差距，使其可觀察並持續管理。

我們正是基於此理念建構了我們的平台。 SocialHub.AI 透過 HTTP 串流協定在 MCP 之上公開語意層工具，可從 Claude、GitHub Copilot 和 Microsoft 365 Copilot 等代理程式存取。此處所述的控制措施應用於接口，而非分散在各個連接器中：基於租戶上下文的三軸授權、故障關閉寫入、帶有執行前終止開關的按運行/按天/按 30 天計費的預算賬本，以及帶有每次調用編輯和審計功能的有範圍、有時限的代理密鑰。這種治理原則與我們先前在忠誠度工作中所使用的原則相同，我們曾幫助 McDonald's China 會員的 GMV 貢獻率從大約 5% 提升至 85%——如此規模的成果只有在數據介面本身就值得信賴的情況下才能實現。

如果您正在決定代理程式如何存取您的記錄系統，那麼您應該向團隊提出的問題不是“使用哪個連接器”，而是“身份、授權、日誌記錄和成本在哪裡確定，以及是在一個地方還是多個地方”。如果您想了解以治理為先的 MCP 介面在實踐中是如何運作的，請預約演示，或訪問 /platform/ai-frontier 以了解更多關於我們方法的資訊。