讀完這篇文章，你將清楚了解 Model Context Protocol（MCP）是什麼、為何它在今年進入了保安團隊的風險清單，以及當供應商聲稱「我們支援 MCP」時，你必須追問的五個問題。
什麼是 Model Context Protocol（MCP）？
MCP 是一項開放標準，讓 AI 模型透過統一介面連接外部工具、資料來源與業務系統。企業不再需要為每一款 AI 工具與每一個系統逐一開發整合，而是把每個系統以 MCP 伺服器的形式公開一次，任何支援 MCP 的 AI 客戶端便可使用。
可以把它理解為企業 AI 的 USB-C 接口。在此之前，每一條「模型連系統」的通道都是度身訂造的工程；在此之後，接口變成標準件，真正的工作轉移到另一個問題上：誰有資格插上去。
正因如此，MCP 已經不再只是開發團隊的技術議題，而是治理議題。
為何 MCP 突然出現在管理層議程上？
MCP 從開發者話題升級為董事會層面的議題，原因是採用速度超越了控制機制的建立速度。企業 AI 代理如今被期望能讀取 CRM、工單系統與文件庫，而執行這件事的機制正是 MCP。這項協定在大約十八個月內，由「可選項」變成「承重結構」。
根據 Stacklok 的 2026 年軟件報告，受訪軟件機構中有 41% 已在有限或大規模生產環境中運行 MCP 伺服器。這不是試點階段的數字，而是生產基礎設施的數字。
《CIO》雜誌形容 MCP「突然出現在每一份管理層議程上」，理由很直接：這項協定決定了你的 AI 代理在你自己的系統版圖內能夠觸及什麼。
對一家在香港同時運行 Dynamics、本地人力資源平台與內部文件庫的企業而言，MCP 就是決定 AI 助理能否看到員工紀錄的那一層。這是存取控制決策，而存取控制決策應該掌握在你手上，而不是交給供應商的產品路線圖。
MCP 實際如何運作？
MCP 由三個部分組成：使用者實際操作的主機應用程式、主機內的客戶端，以及一個或多個各自封裝了系統或資料來源的伺服器。客戶端向伺服器詢問可用工具，模型選擇其中一項，伺服器再對底層系統執行。
有三個概念值得管理層掌握。
--- 工具（Tools）是模型可以呼叫的行動，例如「建立工單」或「查詢發票」。這一類會改變系統狀態。
--- 資源（Resources）是模型可以讀取的唯讀資料，例如政策文件或客戶紀錄。
--- 提示（Prompts）是伺服器可以提供的可重用指令範本，用於標準化任務的執行方式。
對決策者而言最關鍵的一點是：一次工具呼叫，等同軟件依據語言模型的判斷，在生產系統內採取了一項實際行動。凡是你對「由人執行該行動」所設下的控制要求，理應同樣適用於此。
MCP 與一般 API 整合有何不同？
有分別，而分別在於「由誰決定」。傳統 API 整合是確定性的：開發人員撰寫程式碼，在特定條件下呼叫特定端點。在 MCP 之下，伺服器公佈自己能做什麼，然後由語言模型在執行當下決定要做哪一項。
這個轉變搬動了一個控制點。在傳統整合中，邏輯存在於經過審查、有版本控制的程式碼裡；在 MCP 部署中，部分邏輯存在於模型對請求的詮釋之中。
實務後果是測試的性質改變了。你不再只是測試端點會否回傳正確資料，而是要測試：當請求含糊、帶有敵意，或只是由一位下午六點疲累的員工草率寫成時，代理是否仍然會選擇正確的工具。
這也解釋了為何「我們有 AI 整合」這句話幾乎沒有資訊量。真正有用的問題是：模型是否正在自行選擇行動？如果是，什麼在約束這些選擇？關於如何分辨真實代理能力與行銷語言，可參考代理漂白（agent washing）的實際樣貌。
MCP 真正的保安風險是什麼？
這個保安問題是結構性的，而非偶發的。MCP 為了開發便利與不設限的執行方式，標準化了一個非常龐大的攻擊面，而且速度遠快於多數機構建立相應控制的速度。保安因素目前一直被列為企業採用 MCP 的首要障礙。
對企業領袖而言，有四項風險最為關鍵。
--- 工具下毒（Tool poisoning）。惡意或已被入侵的伺服器，以特定方式描述自己的工具，誘導模型執行使用者從未要求的行動。指令以資料形式送達，模型卻當成命令執行。
--- 權限過寬。伺服器獲授的存取權遠超任務所需，於是單一次入侵所觸及的範圍，遠不止一個資料集。
--- 傳輸中的憑證外洩。保安評估發現，相當比例的 MCP 伺服器使用明文 HTTP 端點，令 OAuth 權杖、API 金鑰與工作階段中繼資料暴露於被攔截的風險。
--- 供應鏈仍未成熟。單是 2026 年首兩個月，就有超過 30 個針對 MCP 相關軟件的 CVE 被登錄。這是年輕生態系統的特徵，而非崩壞的訊號，但意味著你需要頻繁修補。
問題的嚴重性，可以從「誰在發佈指引」看出來。美國國家安全局於 2026 年 6 月就 MCP 保安設計發出網絡安全資訊文件，雲端保安聯盟（CSA）亦已發佈代理式 MCP 保安最佳實務。協定若非承重結構，不會吸引這個級別的關注。
Enterprise-Managed Authorization 改變了什麼？
Enterprise-Managed Authorization（EMA）是把 AI 工具存取權交還給機構身分供應商（IdP）的 MCP 擴充規格。它於 2026 年 6 月 18 日成為穩定版規格，對任何負責企業存取控制的人而言，這是目前最重要的發展。
在 EMA 出現之前，每一個 MCP 伺服器都會逐一向每位使用者索取授權。員工在 IT 部門從未審閱過的畫面上按下「允許」，而機構完全沒有中央紀錄可以說明：哪些 AI 代理能觸及哪些系統。
EMA 以零接觸流程取代這種做法。在單一登入過程中，客戶端將使用者的身分權杖，換取一個僅限單一目標伺服器的授權，所依據的都是成熟標準：OIDC 或 SAML 登入、RFC 8693 權杖交換，以及 RFC 7523 JWT bearer grant。
用白話說：你的身分供應商成為「哪個 AI 代理可以觸及哪個系統」的權威，而所依據的，是你早已套用在其他所有應用程式上的同一套政策。
Okta 是首個獲支援的身分供應商，透過其 Cross App Access 功能實現。Anthropic 已在 Claude、Claude Code 與 Cowork 全面實作 EMA，Visual Studio Code 亦已在 IDE 內直接支援。微軟則已發佈指引，說明 Entra ID 與 App Service 目前可以做到什麼。
如果你的機構已經在運行條件式存取，EMA 意味著你的 AI 代理版圖終於可以進入這道防線之內，而不是停留在旁邊。
企業應如何評估 MCP 部署？
採用四階段流程，而非功能核對清單。這套流程之所以有效，是因為每一階段都會產出下一階段所倚賴的證據；而且若結論是「你尚未準備好」，它會以極低成本讓你及早知道。
--- 第一階段：盤點。列出機構內所有已連接 AI 工具的 MCP 伺服器，包括個別團隊自行啟用、未經審批的部分。大多數機構會對這份清單感到意外。
--- 第二階段：按影響半徑分類。逐一記錄每個伺服器能讀取什麼、能改動什麼，並把唯讀資源與會採取行動的工具分開。只能讀取公開產品目錄的伺服器，與能夠發出退款的伺服器，風險等級截然不同。
--- 第三階段：把存取決策收歸身分系統。透過 EMA 把存取決策由逐人授權畫面移至身分供應商，使員工離職時，其 AI 代理的觸及範圍同步被撤銷。
--- 第四階段：記錄並覆核「行動」，而不只是「對話」。多數 AI 日誌只擷取提示與回應。審計師真正會索取的，是工具呼叫紀錄：執行了什麼行動、在哪個系統、依據誰的授權。
一家香港金融服務公司走過這個流程時，通常會發現第二階段才是項目真正證明其預算價值的環節。盤點結果令人不安，但分類工作才是把無邊界風險轉化為可界定風險的關鍵。
供應商說「支援 MCP」時，應追問哪五個問題？
「我們支援 MCP」是關於連通性的陳述，不是關於安全性的承諾。以下五個問題，能分辨哪些供應商真正為企業部署做過工程設計，哪些只是開啟了一項功能。
--- 你們的客戶端是否支援 Enterprise-Managed Authorization？支援哪些身分供應商？如果答案只有逐人授權畫面，代表你的存取控制實際上被下放給了員工。
--- 你們的 MCP 工具中，哪些會採取行動而非只讀取資料？我可以逐項停用嗎？全開或全關的工具權限，不構成治理立場。
--- 你們如何防禦來自第三方伺服器的工具下毒？要求列出具體緩解措施，而不是接受口頭保證。
--- 你們的工具呼叫審計日誌包含什麼？保留多久？能否匯出到我們的 SIEM？如果日誌只存在於供應商的控制台，你的事故應變就取決於他們的客服排隊。
--- 你們對 MCP 元件的修補頻率如何？2026 年那批 CVE 是怎樣處理的？過往在壓力下的行為，最能預測未來的行為。
能就五個問題全部給出具體答案的供應商，是真的做過功課；只會回答「企業級」三個字的，並沒有。
機構在 MCP 上通常錯在哪裡？
常見的失敗多屬組織層面而非技術層面，而且模式相當一致。每一項都可以靠一個及早作出的決定避免，而不是靠事後補救。
--- 影子連接。個別團隊未經審核便把 MCP 伺服器連上生產系統，因為設定只需數分鐘、亦不涉及採購流程。IT 部門往往在事故發生時才發現整個版圖。
--- 把代理當成「工時無限的員工」。獲授人類權限的 AI 代理，可以每天行使該權限數千次。對人來說顯得多餘的速率與範圍限制，在此變成必要條件。
--- 用聊天機械人時代的治理文件。為「只回答問題的 AI」而寫的政策，無法涵蓋「會採取行動的 AI」。如果你的 AI 政策完全沒有提到工具呼叫，它的年代早於這個問題。
--- 沒有回退路徑。機構會規劃代理如何行動，卻不規劃如何撤銷它做過的事。撤銷程序應在上線前定義，而不是在第一個糟糕的星期中途摸索。
--- 把合規當成後續工序。在香港《個人資料（私隱）條例》之下，個人資料由 AI 代理而非員工移動，並不改變責任歸屬，資料使用者仍須問責，而私隱專員公署 2026 年的代理式 AI 指引已列明監管機構現時期望看到哪些文件紀錄。
結論：協定已成定局，治理尚未到位
MCP 已經贏得了整合方式之爭。生產環境採用率超過四成、企業授權擴充規格轉為穩定版、國家級保安機構開始發佈設計指引，這些都說明：問題不再是你的機構會不會用它。
真正未解的問題是：你的 AI 代理連接系統時，是經過你的身分供應商與審計軌跡，還是繞過它們。這是一個只作一次、而且必須及早作出的決定，刻意規劃的成本，遠低於日後補做的成本。
由盤點開始。它花你一星期，卻能告訴你真實的位置在哪裡。
科技週期總是回報那些在技術仍然年輕時就建好護欄的機構。懂AI，更懂你 UD相伴，AI不冷。
本文由 UD 企業 AI 團隊審閱。
你的機構應由哪裡開始？
在把任何一個系統接上 AI 代理之前，你需要對機構現況有一個誠實的評估。UD 團隊手把手帶你完成每一步，由 AI 準備度評估、身分系統整合，到部署上線與審計設計，28 年服務香港企業的經驗，全程陪你走。
