Model Context Protocol 團隊已將其 Enterprise-Managed Authorisation 擴充功能提升至穩定狀態，為組織提供集中式方式，透過其身份提供者控制對 MCP 伺服器的存取。該專案表示，目標是取代每個伺服器的同意提示，改為零接觸流程，使用者只需登入一次，即可存取已核准的伺服器，無需進一步設定。

在 發佈公告中，MCP 團隊表示該擴充功能現已穩定，並已被 Anthropic、Microsoft、Okta 以及越來越多的 MCP 伺服器採用。該篇文章指出，社群已明確表示，重複的授權提示是企業 MCP 部署中的主要痛點，因為標準模型是以使用者為範圍，且綁定互動式驗證慣例，無法在大型組織中良好擴展。

Enterprise Managed Auth diagram, courtesy MCP Blog

實際效果是將授權決策移至企業身份提供者，而非交由每位員工與每個伺服器自行處理。企業端文章指出，結果是連接的伺服器可獲得「單一登入」體驗，使用者可繼承其組織已核准之伺服器的存取權限。該流程使用 Identity Assertion JWT Authorisation Grant（ID-JAG），由 MCP 伺服器的授權伺服器交換為存取權杖。

該篇文章強調此架構的重要性：它將身份政策與工具呼叫本身分離。企業管理層決定使用者是否能將用戶端連接至伺服器，以及連接的範圍，但不會在權杖發行後檢查 MCP 流量。指南明確警告，這不是針對個別動作的執行期授權，意即組織仍需自行控制代理進入系統後的行為。

"組織可以集中管理 MCP 伺服器的授權，而終端使用者只需單一登入即可存取所有已連接的 MCP 伺服器。"
-- Model Context Protocol blog

此公告將此功能定位為對 MCP 實際採用方式的回應。文章指出，舊有的每位使用者模型會產生手動 onboarding 工作，讓安全團隊更難執行政策，並模糊個人帳戶與工作帳戶之間的界線。相較之下，新擴充功能讓管理員只需定義一次政策，即可透過現有身份控制機制套用。

多篇外部文章也得出相同結論。Ehsan Hosseini 將 EMA 描述為解決每位使用者、每台伺服器 OAuth 所造成的「混亂」之道，並主張企業身份提供者將成為決定哪些用戶端可存取哪些伺服器的權威。該篇文章也對連接層級控制與單一動作控制做出實用區分，認為 EMA 並不能取代敏感執行期決策的獨立政策執行。Okta 是發佈公告中第一個被提及的身份提供者，使用其 Cross App Access 方法作為企業支援的第一條路徑。這使得目前的推廣成為有意義但仍屬部分的步驟，因為該模型依賴身份提供者與 MCP 伺服器皆支援此擴充功能。Hosseini 指出，該協定仍為附加性質，因此未使用支援身份提供者的組織仍需備援路徑。

社群反應普遍正面，特別是關於減少摩擦的承諾。Jiquan Ngiam 在 LinkedIn 上表示，此擴充功能有助於解決使用代理處理資料時最混亂的部分之一，並可透過避免繁瑣的驗證流程，同時改善安全性與可觀測性。其他貼文則稱 EMA 是 MCP 伺服器存取的結構性修正，指出從每位使用者的提示轉為共享企業控制平面。

"我們從社群聽到，來自已連接 MCP 伺服器的授權與重複同意提示，是管理企業環境中連接性時最大的痛點之一。"
-- Model Context Protocol blog

此次發佈也強調新擴充功能周邊的生態系。公告表示，Anthropic 已在 Claude、Claude Code 與 Cowork 的共享 MCP 層中實作支援，而 Visual Studio Code 也已在 IDE 中加入支援。在伺服器端，Asana、Atlassian、Canva、Figma、Granola、Linear 與 Supabase 已列為支援 EMA，Slack 等其他服務則正在進行中。這項廣度顯示該專案正試圖讓集中式企業驗證成為預設功能，而非特殊整合。此版本移除了企業採用 MCP 時最明顯的營運摩擦之一，對試圖大規模將助理連接至內部工具的團隊可能具有重大意義。

About the Author

Matt Saunders