讀完這篇文章，你將能夠用一句話定義 MCP 閘道、向資訊安全主管解釋為何缺少它的代理項目往往卡在上線前一步，並且掌握五個足以分辨「受管治部署」與「示範環境」的供應商提問。
這件事之所以在本季度變得緊迫，原因很簡單：企業 AI 代理底層的連線層，已經悄悄變成風險真正所在的位置。
什麼是 MCP 閘道？
MCP 閘道是一個受控的單一入口，位於你的 AI 代理與所有 Model Context Protocol 伺服器之間。它負責驗證請求身分、檢查該身分獲准使用哪些工具、記錄每一次呼叫，然後才將請求轉送出去。可以理解為代理工具存取的 API 閘道。
Model Context Protocol 本身由 Anthropic 推出，目前已獲大部分主流模型供應商支援，作用是讓模型以標準方式發現並呼叫外部工具，例如客戶關係管理系統、檔案儲存、工單系統或內部資料庫。
這個協定解決了整合問題，卻沒有解決控制問題。閘道正是企業為了填補這個落差而加上的一層。
為什麼 MCP 一開始需要閘道層？
MCP 的設計前提是單一開發者在自己電腦上，把一個模型連上幾件工具。企業部署卻把每一項前提反轉：數百名使用者、數十個伺服器、共用憑證、審計義務。缺少集中收窄點，每個代理各自握有連線與密鑰，最終沒有人能回答「誰呼叫了什麼」。
規模已經不是假設。根據 Digital Applied 於 2026 年發表的分析，約 28% 的《財富》500 強企業已部署 MCP，而受訪軟件組織中有 41% 已在有限或廣泛的生產環境運行 MCP 伺服器。
同一份分析引述 CData 的估算，指 2026 年內將有 30% 的企業應用供應商推出自家 MCP 伺服器。截至 2026 年 5 月 24 日，官方 MCP Registry API 收錄的現行伺服器紀錄為 9,652 項。
結構性問題可以一句話說完
一個假設「操作者是可信本機使用者」的協定，正被部署到「操作者其實是一個代表數百名員工行動的非確定性模型」的環境之中。
MCP 閘道實際上如何運作？
閘道會攔截每一次工具呼叫，並在請求抵達目的地之前施加四項控制：把呼叫綁定到真實的人員或服務身分、對照允許清單檢查該身分可用的工具、寫入審計紀錄，以及把高影響力操作暫停等待人手批准。通過之後，呼叫才會繼續。
這四項控制功能，其實與你的保安團隊早已為 API 運行的控制一一對應。
--- 身分綁定。呼叫透過單一登入或 OAuth 攜帶已驗證的使用者或服務身分，而非使用一個令追溯無從入手的共用服務帳號。
--- 工具允許清單。財務代理可以讀取總帳，但不能寫入。這項權限存在於閘道，而不是存在於一段使用者有辦法繞過的提示詞之中。
--- 審計記錄。由於 MCP 已把工具呼叫的資料格式標準化，閘道能夠以同一套結構，記錄跨越所有伺服器的每一次呼叫。
--- 人手把關。超過既定門檻的操作，例如發出退款或刪除紀錄，會排入待批清單，而不是靜靜執行。
值得注意的是，閘道模式如今已列入協定本身的路線圖，並非純屬供應商發明。2026 年的優先工作集中在三方面：支援負載平衡器的無狀態 streamable HTTP 傳輸、長時間任務的重試與過期語意，以及包含審計軌跡與單一登入整合驗證的企業就緒功能。
沒有閘道的組織，實際出過什麼事？
公開的事故紀錄具體得令人不安。問題主要落在三類：存取邏輯缺陷導致的跨租戶資料外洩、伺服器本身遭供應鏈入侵，以及透過登錄庫基礎設施造成的憑證竊取。三者都是連線層的控制失效，而非模型出錯。
跨租戶外洩。2025 年 6 月，Asana 的 MCP 伺服器出現存取邏輯缺陷，令項目名稱、任務描述與元資料在不同客戶租戶之間互相曝露，時間約兩星期，逾 1,000 名客戶可能受影響。這是 Asana 自行披露、並經 UpGuard 後續分析的事件。
登錄庫供應鏈。GitGuardian 發現 Smithery 的建置設定存在路徑遍歷漏洞，攻擊者可令系統以建置者的家目錄建立映像，進而外洩憑證，受影響的 MCP 伺服器約 3,000 個。
已披露漏洞的數量。保安界的統計顯示，僅 2026 年 1 月至 2 月就有超過 30 個與 MCP 相關的 CVE 被提交，其中包括 CVSS 9.4 的 CVE-2025-49596，以及影響下載量逾 437,000 次套件的 CVE-2025-6514。
若想理解為何「身分」是反覆出現的主題，可以參考我們關於代理身分與每個 AI 代理背後治理落差的解析。
香港監管機構對代理部署有什麼期望？
香港並沒有單一的人工智能法例，義務來自《個人資料（私隱）條例》、私隱專員公署的指引，以及金管局與保險業監管局等業界規則。公署已由「發布框架」轉向「主動查核」，而其 2026 年 3 月針對代理式 AI 的提示，讀起來幾乎就是一份閘道規格書。
根據 Mayer Brown 就新加坡與香港 AI 監管所發表的 2026 年中期回顧，公署於 2026 年 1 月對 60 間機構展開合規查核，並於 2026 年 5 月公布結果。結果顯示 95% 的機構在日常運作中使用 AI，其中超過一半同時運行三個或以上的 AI 系統。
查核並未發現違反《個人資料（私隱）條例》的情況。不過公署仍然建議機構建立治理架構、進行私隱影響評估與 AI 審計、開展員工培訓，並制定事故應變計劃。
2026 年 3 月的代理式 AI 提示走得更遠，明確指出能夠接觸本機檔案、電郵、憑證、瀏覽器內容與外部服務的代理，屬於較高的私隱風險。其實務建議是：把代理限制在最低存取權限、避免給予管理員權限，以及把執行環境與本機基礎設施分離。
把這份清單當成架構要求再讀一次。最低存取權限，就是工具允許清單。避免管理員權限，就是身分綁定。把執行環境與本機基礎設施分離，就是那道居中的閘道。
如何評估 MCP 閘道？五個問題
有五個問題足以分辨「受管治的部署」與「一場示範」。它們測試的並非系統在理想路徑上能否運作，而是這道閘道在審計面前能否自我交代。在供應商會議上逐一提出，並就每一項索取證據，而不是保證。
--- 問題一：能否完整展示單一次工具呼叫的紀錄？如果答案需要把三個系統的紀錄拼起來，你手上並沒有審計軌跡，只有碎片。
--- 問題二：下游系統看到的是哪一個身分？如果所有呼叫都以同一個服務帳號抵達，你既無法調查事故，也無法回應公署關於「誰存取了什麼」的查詢。
--- 問題三：新增伺服器的流程如何，由誰批准？有審批流程的登錄庫，與影子 AI 之間的差別就在這裡。公開可用的 MCP 伺服器已超過 10,000 個，自助安裝正是最常見的失效模式。
--- 問題四：工具呼叫含糊或失敗時會發生什麼？重試與過期政策十分關鍵，因為代理的重試相當積極。請問清楚：是什麼機制阻止重試循環把同一筆交易發出四次。
--- 問題五：單一伺服器被入侵，影響半徑有多大？如果答案不是「一組受允許清單限制的工具，加上一組受限制的身分」，那麼這套架構本身就是承繼下來的風險。
在實際運作中是什麼樣子？
兩個香港場景可以說明，為何閘道的決策來得比多數管理層預期更早。兩個案例的共通點是：代理在試點中運作良好，卻在保安審查前停下，因為試點採用直連，而生產架構容不下直連。
一家中型金融服務公司。營運團隊試行一個代理，讓它讀取客戶紀錄並草擬回覆。試點使用單一 API 憑證，附帶廣泛讀取權限。到了上線前審查，第二道防線提出一個問題：每一次讀取，是以哪位員工的權限進行的？沒有答案，項目因此停滯一個季度。
一家使用舊有系統的物流集團。代理需要連上倉庫管理系統、報關代理平台與財務套件。三個團隊持有三組憑證，卻沒有人負責回答「代理可以寫入什麼」。加上閘道並非為了保安做樣，而是因為那是唯一能夠讓一套寫入政策存在的位置。
已公開的生產數據顯示，控制層一旦到位，回報是實在的。Pinterest 於 2026 年 3 月記錄的 MCP 生態，每月約有 66,000 次工具呼叫、844 名活躍使用者，估算每月節省約 7,000 小時。
如果你同時在衡量平台層面的選項，我們關於OpenAI Presence 與企業代理平台結構的解析，涵蓋了相鄰的自建或採購問題。
缺乏指引時，組織通常錯在哪裡？
四種失敗模式反覆出現，而它們都不是什麼技術奇觀，而是次序錯誤：一個本該在項目開頭作出的決定，被拖到第五個月由預設值代替，而逆轉的代價已由「改設定」變成「重建」。
陷阱一：把閘道當成第二階段的事。代理上線之後才補回身分綁定，等於重寫每一個整合。一開始就決定，只需一星期的架構時間。
陷阱二：用提示詞而非政策做允許清單。系統提示寫「不得刪除紀錄」，那是一項建議。閘道從不曝露刪除工具，那才是一項控制。
陷阱三：沒有指定負責人。2026 年多份治理指引指向同一結論：除非在代理進入生產之前，有一位具名主管持有明確的決策權，責任就會在資料、MLOps、保安與業務團隊之間分散消失。
陷阱四：只用能力衡量試點。一個證明了代理做得到，卻沒有產出審計證據的試點，其實沒有降低任何風險，只是把困難的對話推遲，同時累積更多沉沒成本。
策略性結論
MCP 標準化了 AI 代理接觸你系統的方式，卻沒有決定誰有權接觸什麼，以及事後由誰負責。這個決定屬於架構層面，主導權在你手上，而在第一個代理上線之前作出，成本最低。
能在 2027 年走得最快的組織，不是代理數量最多的那些，而是能夠用一行紀錄說清楚每個代理做過什麼、憑誰的權限做的那些。這項能力在項目開頭是一星期的設計工作，在項目末段則是一次重建。
懂AI，更懂你 UD相伴，AI不冷。28 年為香港企業建設基礎設施的經驗告訴我們：那個看似枯燥的控制層，往往決定了精彩的部分究竟能否上線。
本文由 UD 企業 AI 團隊（香港）審閱。最後更新：2026 年 8 月 24 日。
準備好規劃你的代理架構？
在選擇閘道之前，你需要先看清組織的真實位置：代理會接觸哪些系統、已有哪些控制、哪些缺口會令保安審查卡關。由 UD 的 AI 體檢開始。UD 團隊手把手帶你完成每一步，從準備度評估、架構檢視，到部署上線與成效追蹤，28 年香港企業服務經驗，全程陪你走。
