編按:本文綜合整理自 MCP 官方部落格 (2026-06-18)、TechTimes — MCP Enterprise Authorization Goes Stable、AIWeekly — Anthropic Introduces Admin-Managed MCP Auth、GlobeNewswire — C1 Announces Enterprise-Managed Authorization Support 與 Hacker News 討論串,並加入 Siami 編輯部觀點與分析。
MCP(Model Context Protocol)社群在 6 月 18 日正式把 Enterprise-Managed Authorization(EMA)擴充 標記為 stable。這是 MCP 問世以來第一個進入穩定版的授權相關擴充,目標是把企業員工「逐一授權每個 MCP 伺服器」的麻煩流程徹底拿掉,改成由企業 IdP(身分提供者)在幕後一次配發所有授權。
為什麼舊的 MCP 授權在企業裡行不通
MCP 原生的授權模型從一開始就是為「個人使用者決定哪些工具能碰自己的資料」設計的。在消費者場景(例如個人 Claude 用戶串接自己的 Gmail、Notion)這種設計很自然,但搬到企業部署時立刻遇到三個瓶頸:
- 每個員工都要個別授權每個伺服器:新進員工 onboard 第一天就要把十幾個 MCP 連接器一個一個按同意,UX 摩擦極高。
- 資安團隊無法強制一致政策:誰能存取什麼,取決於每個使用者自己按了什麼同意鈕,沒有中央控制,沒有統一稽核軌跡。
- 私人帳號與工作帳號混用:沒有機制強制綁定公司身分,員工很容易用個人帳號串接公司工具,出事後難以切割。
「過去幾個月,我們從社群收到最多的回饋就是:在企業環境中,MCP 連接器不斷跳出 consent 提示是阻礙採用率的最大痛點。EMA 擴充就是為了正面回應這件事。」 — Paul Carleton,MCP 核心維護者
這三個瓶頸疊在一起,直接拖慢 MCP 的企業採用率。沒有「保留共享授權狀態」的統一標準,各家廠商只好各自刻自己的 workaround — 資料跟工具明明已經接好,卻因為「每次登入都要重來一次」的授權稅而被擱置。
EMA 的運作原理:把 IdP 變成唯一決策者
EMA 擴充的設計哲學只有一句話:讓企業的 IdP 成為 MCP 伺服器存取的權威決策者。管理員在 IdP 後台定義一次政策,使用者用既有身分登入 MCP host(IdP 透過 SSO 驗證身分),IdP 根據群組成員、角色、條件式存取規則決定授權與否。
底層的技術流程是這樣:
- SSO 觸發 ID-JAG:MCP client 在單一登入期間,從 IdP 取得一個 Identity Assertion JWT Authorization Grant(ID-JAG)。
- 換取 access token:Client 把 ID-JAG 拿去跟 MCP 伺服器的 authorization server 交換成正式的 access token。
- 不經過 per-server consent:使用者全程不會被導去任何「同意畫面」,因為 IdP 已經代為決定了。
從這個流程會自然掉出三個特性:
- 一次授權、處處繼承:管理員在 IdP 後台 enable 一個 MCP 伺服器,所有符合群組/角色的員工自動取得存取權。
- 集中政策與稽核:存取決定全部活在 IdP 管理員控制台,每個 connector 的授權紀錄統一可查。
- 公私帳號分流:拿掉「互動式帳號選擇」這個步驟,等於強迫 AI Agent 用企業身分,大幅降低個人帳號被誤接到企業工具的風險。
第一波採用者:Okta、Anthropic、VS Code 與七大 MCP 伺服器
這個擴充從 spec 到實作只花了幾個月,背後有三群角色同步推進:
身分提供者(IdP)
- Okta 是首個支援的 IdP。企業透過 Okta 的 Cross-App Access(XAA)機制,可以在任何支援的 MCP client 端配發 MCP 存取權。
- **C1(原本是 Strata Identity)**在 6 月 18 日同步宣布 day-one 支援,負責核發短效期的 scoped token,把整個治理流程收在一個控制平面。
Client 端
- Anthropic 在 Claude、Claude Code 與 Cowork 共用的底層 MCP 層實作了 EMA,管理員一次授權就能在整個 Claude 生態生效。
- Visual Studio Code 也直接在 IDE 裡加入 EMA 支援,開發者不必離開編輯器就能走完企業授權流程。
MCP 伺服器端
下列 MCP 伺服器已上線支援 EMA,Slack 與更多服務正在加入:
- Asana
- Atlassian
- Canva
- Figma
- Granola
- Linear
- Supabase
「把 Cross-App Access 通訊協定嵌入 MCP 作為 EMA 擴充,等於把企業身分變成 AI Agent 的中央治理平面 — 資安團隊取得嚴格的合規控管,使用者得到無縫且安全的體驗。」 — Aaron Parecki,Okta 身分標準總監
Linear 工程主管 Tom Moor 則直接說出使用者體驗面的觀察:
「登入一次就讓所有 MCP connector 自動設定好,這體驗真的像變魔術。」
對企業 AI 部署的真實意義
EMA 不只是「少按幾個同意鈕」這種 UX 小確幸,實際上是 MCP 從「個人開發者玩具」升級成「企業級基礎建設」的轉捩點。
對企業 IT 而言,從今天開始,他們第一次可以用「跟管理 SAML 應用一樣的流程」來管理 MCP 連接器。Onboard 一個新員工不再需要 IT 預先手動串接十幾個 connector,只要 IdP 群組設定好,員工打開 Claude 就會自動看到所有被授權的工具。這把 AI 工具的部署成本從「按人頭計算」壓回「按政策計算」。
對資安團隊而言,EMA 解掉的是 MCP 一直以來最大的稽核黑洞 — 過去 MCP 的授權紀錄散落在每個 client、每個使用者、每個同意動作裡,合規報告要拉資料等於要拼拼圖。現在所有決策回到 IdP,稽核軌跡只有一條。
對 AI Agent 開發者而言,EMA 的出現等於 MCP 終於給出了一個「企業客戶可以無痛採用」的授權方案。在 EMA 之前,要賣 MCP 整合給企業客戶,幾乎一定要走一段客製 OAuth 整合;現在只要客戶用的是支援的 IdP(目前 Okta),零程式碼就能上線。
為什麼這件事重要
EMA 的意義比表面上「方便企業登入」深得多,有三個層面值得攤開來看。
第一,它把 MCP 從「應用層協定」升級為「企業身分治理的延伸」。 過去企業裡 IdP 控管的對象是 SaaS 應用、內部系統、API;AI Agent 的工具存取一直處於灰色地帶。EMA 等於正式宣告:AI Agent 拿到的 token 跟人類員工拿到的 token 走同一條治理鏈。這對未來 AI Agent 在企業內的角色定位會有深遠影響 — 從「個人助理」變成「可被企業 IT 編制、稽核、限制權限的數位員工」。
第二,它把 OAuth 的 consent 模型從「人類使用者」重新定義為「AI Agent 代理」。 傳統 OAuth 的核心假設是:有個真人在瀏覽器前面,可以停下來看 consent 畫面、決定是否同意。但 AI Agent 沒有真人,無法做 consent 對話、不能持有長期憑證、也不應該。EMA 的 ID-JAG 機制是 OAuth 圈對「代理人授權」這個全新使用情境的回應 — 短效期 token、IdP 代理決策、企業政策優先,這套設計很可能會回頭影響 OAuth 2.1 與 OIDC 整體社群對 agentic use case 的標準化方向。
第三,它把「Cross-App Access」這個原本只在身分圈流通的概念正式帶進 AI 圈。 過去兩年 Okta 跟各大身分聯盟推 Cross-App Access,但一般工程師很少聽過這個詞。透過 MCP 這個 AI 圈最活躍的標準之一,XAA 一次性獲得 Anthropic、Microsoft VS Code、Figma、Linear 等頭部企業的實作背書。這條路線一旦在 AI 圈跑順,傳統 SaaS 圈很可能會加速跟進。
數據解讀與質疑
幾個值得追蹤的數據點與可質疑之處:
- 第一波只支援 Okta 一個 IdP。雖然 C1 已經 day-one 支援,微軟 Entra ID、Google Cloud IAM、Auth0 等主流 IdP 都還沒正式表態。對 Okta 之外的企業客戶來說,EMA 目前等於「看得到但用不到」。社群應在接下來 30 天內要求其他 IdP 端出時程表。
- 沒看到 SAML 或 OIDC legacy 整合方案。許多企業 IdP 還停留在傳統 SAML/OIDC,EMA 的 ID-JAG 機制基於 OAuth 2.x,理論上可橋接,但官方 spec 沒明確談 legacy 遷移路徑,實作風險要靠各家 IdP 自行處理。
- Anthropic 把 EMA 寫進「Claude、Claude Code、Cowork 共用底層」,等於把 Claude 系列所有版本的 MCP 連接器政策都收進單一治理面。對 Anthropic 客戶是大利多,但對其他 MCP client(例如 OpenAI 的 MCP 整合、Cursor 的 MCP 支援)來說,他們若沒有同步實作 EMA,使用者會看到一個分裂的體驗 — Claude 裡 connector 自動出現,Cursor 裡要手動授權。
- 「一次授權處處繼承」對員工個人隱私的影響值得企業法務關注。員工過去可以在 MCP client 端拒絕某個 connector 來保護自己的資料,EMA 把這個決定權整個上繳到 IdP。對 BYOD 裝置(員工自帶筆電)而言,等於企業 IdP 在員工私裝置上對所有 MCP connector 有了否決權,勞動契約與裝置政策應同步更新。
- EMA 是 spec-stable,不是 protocol-stable。MCP 的核心 protocol 版本(MCP 2026-07-28 release candidate 預定 7 月 28 日)才是真正的下一個大版本,EMA 是這個大版本的前哨。WorkOS 已經預告 2026-07-28 會帶來 stateless core、新的 authorization hardening,企業 IT 部署時程應直接抓 7 月底之後。
後續觀察與延伸閱讀
EMA 是 MCP 從「開發者嘗鮮」跨入「企業標配」的關鍵節點,接下來幾個月值得持續追蹤的是:
- 其他 IdP(尤其 Entra ID 與 Google Cloud IAM)的支援時程
- MCP 2026-07-28 release 帶來的 stateless core 與新 authorization hardening
- Anthropic 的「Claude 共用底層 EMA」是否會透過 MCP 標準影響到其他 client(如 Cursor、Cline、Windsurf)的實作
完整原始 spec、SEP-990 提案與 ext-auth repository 都公開在 GitHub,對實作端有興趣的開發者可以直接到 MCP 官方 GitHub 讀 draft specification。Anthropic 與 Okta 也分別在各自的工程部落格公布了導入細節,Okta 的 XAA 機制說明特別值得 IT 團隊參考。
對一般企業 IT 決策者,最直接的兩個動作是:
- 盤點目前所有 MCP client/connector 部署,找出哪些是靠 per-user consent 在撐場,哪些已經在 IdP 治理範圍內。
- 跟 IdP 廠商確認 EMA/ID-JAG 支援時程,把 MCP 治理納入下一季的身分策略 roadmap。
EMA 不會立刻改變日常使用 MCP 的體驗,但它把 AI Agent 在企業內的「身分邊界」正式畫好了 — 接下來半年,所有 AI Agent 進入企業流程的合規討論都會引用這條 baseline。
編按:本文綜合整理自 MCP 官方部落格 (2026-06-18)、TechTimes — MCP Enterprise Authorization Goes Stable、AIWeekly — Anthropic Introduces Admin-Managed MCP Auth、GlobeNewswire — C1 Announces Enterprise-Managed Authorization Support、Hacker News 討論串,並加入 Siami 編輯部觀點與分析。
網友熱門留言 (5)