在開發 AI Agent 或使用 LLM 輔助開發工具時，我們經常需要讓 AI 存取外部資料（例如 GitHub、Slack 或內部資料庫）。為了達成這個目的，業界推出了一套名為 Model Context Protocol (MCP) 的開放標準。MCP 的核心目標是讓 AI 模型能以統一的方式與各種資料來源（MCP Server）溝通，而不需要為每個工具寫一套不同的對接程式碼。
然而，當 MCP 從個人開發者環境擴展到企業規模時，一個巨大的痛點出現了：認證疲勞。在早期的 MCP 設計中，權限管理是基於使用者個體的。這意味著每當員工想要讓 AI 連接一個新的資料伺服器時，系統都會跳出授權請求，要求使用者手動點擊同意。對於一家擁有數千名員工且連接數十個內部工具的公司來說，這種每個人、每個伺服器都要單獨授權的模式完全無法擴展，且對資安團隊而言，缺乏統一的管控手段。
為了克服這個問題，MCP 團隊推出了 Enterprise-Managed Authorisation (EMA) 企業管理授權擴充功能。簡單來說，EMA 將權限的決定權從個體員工手中移交給了企業的身份識別提供者 (Identity Provider, IdP)，例如 Okta 或 Microsoft Entra ID。
EMA 的運作邏輯是將認證流程轉化為單次登入 (Single Sign-On) 的體驗。當員工登入公司的帳號後，系統會根據公司預先定義好的策略，自動授予該員工存取特定 MCP 伺服器的權限。在技術實作上，這使用了 ID-JAG (Identity Assertion JWT Authorisation Grant) 機制。這是一種基於 JSON Web Token (JWT) 的認證授權方式，客戶端會攜帶這個身份證明去向 MCP 伺服器的授權伺服器交換存取令牌 (Access Token)。
這裡需要特別提醒工程師區分兩個重要的概念：連線層級控制與執行層級控制。
EMA 解決的是連線層級控制 (Connection-level Control)。它決定的是誰可以把 AI 客戶端連接到哪個伺服器，以及連線的範圍。一旦令牌核發，EMA 就不再干涉後續的流量。
而執行層級控制 (Per-action Control) 則是指 AI 在進入系統後，具體能執行哪些操作（例如：只能讀取文件，不能刪除資料）。EMA 並不負責這部分的細粒度權限控管。因此，企業在導入 EMA 的同時，仍然需要在後端系統中建立完善的運行時權限檢查，以確保 AI Agent 不會因為擁有連線權限而誤刪重要資料。
目前 EMA 已經進入穩定版本，並得到了 Anthropic、Microsoft 與 Okta 等大廠的支持。在客戶端，Claude 系列產品以及 Visual Studio Code 已經整合此功能；而在伺服器端，Asana、Atlassian、Figma 與 Supabase 等工具也陸續加入。
對於企業開發者而言，EMA 的重要性在於它將 AI 工具的導入從手動設定轉向了策略驅動。資安團隊現在可以在中央控制面板定義誰能存取什麼，而不需要在每個員工的電腦上重複配置。雖然目前的生態系仍處於過渡期，部分不支援 EMA 的伺服器仍需回退到舊有的個人授權模式，但這個方向明確地將 AI Agent 的基礎設施推向了標準化與企業級管理。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。