2026 年 6 月 18 日，Model Context Protocol 官方部落格宣布「企業託管授權」（Enterprise-Managed Authorization, EMA）成為穩定的規格擴充，主打「零接觸 OAuth for MCP」。核心改變一句話可說完：MCP 伺服器的授權決策，從每位使用者手動按下「允許」，上移到企業的身分供應商（IdP）。員工登入 SSO 的當下，獲准的 MCP 伺服器自動接通，中間沒有任何逐站同意畫面。
對正在把 AI 代理接上內部工具的團隊，這解決的是最無聊卻最致命的問題：上線第一天，每個員工都要對每個連接器手動授權一次，而資安團隊既看不到誰核准了什麼，也無法集中回收。
ID-JAG 如何運作
技術核心是一種新的權杖格式：ID-JAG（Identity Assertion JWT Authorization Grant），對應 IETF 草案 draft-ietf-oauth-identity-assertion-authz-grant。流程是：使用者進行單一登入時，IdP 核發 ID-JAG 給客戶端，客戶端再拿它向 MCP 伺服器的授權伺服器換取存取權杖——全程不會把使用者重新導向到逐站的同意頁。整套機制建立在 Okta 的 Cross App Access（XAA）協定上，規格前身是 SEP-990，而且不限 MCP：任何共用同一個 SSO 的應用程式之間的資料共享，都能用它保護。
管理面的邏輯是「授權一次，處處繼承」：管理員在 IdP 依群組、角色與條件式存取規則把政策定義一次，之後誰能連哪台伺服器、何時撤銷，全部由 IdP 統一裁定，並留下單一可稽核軌跡。
解決的三個痛點
- 上線摩擦：過去每位員工要對每台 MCP 伺服器手動授權，EMA 之後第一天就自動連通。
- 缺乏中央控制：存取範圍等於每個人自己按過「允許」的總和，稽核與資安看不到全貌；現在政策集中在 IdP，一條軌跡可查。
- 帳號混合：員工可以把個人帳號接到公司工具上，把企業資料悄悄匯出到個人工作管理帳號——標準 OAuth 沒有防堵機制，EMA 在協定層封住這條路。
安全辯論：零摩擦是雙面刃
Hacker News 討論中最實質的批評來自提示注入視角：如果一個被注入惡意提示的儲存庫誘發工具呼叫，摩擦減少是否讓攻擊更容易？有評論者主張，銀行類的 MCP 伺服器至少應該在連線當下跳一次確認。反方則回應：工具呼叫的管控本來就是客戶端的職責，而且 MCP 伺服器向來是「每人驗證一次」而非「每段對話驗證一次」，EMA 沒有改變這件事。
也有明確的安全加分：與動態用戶端註冊（DCR）相比，有評論者認為 EMA「從安全角度大幅優於 DCR」，因為攻擊者不再能自行註冊用戶端，緩解混淆代理人（confused deputy）與釣魚類攻擊。另一個被點名的隱憂是能見度：授權發生在 IdP 政策層，使用者可能永遠不知道哪些應用被允許共用彼此的資料。
生態系現況與 Entra ID 落地難題
支援現況：Okta 是第一家支援的 IdP。客戶端方面，Anthropic 已在其共用 MCP 層實作，涵蓋 Claude、Claude Code 與 Cowork，VS Code 也已在 IDE 內支援。伺服器端則有 Asana、Atlassian、Canva、Figma、Granola、Linear 與 Supabase 上線，Slack 等正在跟進。
落地最大的痛點是 Microsoft Entra ID：許多 MCP 客戶端假設 DCR 存在、不接受預先註冊的 client_id，而 Entra ID 不支援 DCR。有開發者只能用代理層欺騙客戶端「DCR 可用」，暗中注入寫死的 client_id。Anthropic 的維護者表示「正與 Microsoft Entra ID 團隊保持聯繫」。另外，OAuth 工作組也在推進任務層級授權與多跳委派的後續草案，方向是每次委派逐步收窄權限、採用持有證明（proof-of-possession）而非持有人權杖。
對企業代理部署的啟示
第一，身分是代理安全的下一個戰場。當一個代理代表員工呼叫數十個內部 API，「誰批准的、憑什麼批准」必須有協定級的答案，EMA 把這個答案交給 IdP——這與企業級代理工具整體走向集中治理的方向一致（可參考先前對 Vercel 企業級代理布局 的整理）。第二，別把 EMA 當成完整防線：提示注入與工具濫用的控制仍然落在客戶端與代理框架層，零接觸上線省的是管理成本，不是威脅模型。第三，混合 IdP 環境要有過渡計畫：Entra ID 尚未原生支援，跨身分平台的大企業將需要代理層的權宜方案，而這些臨時做法正是將來升級時要還的技術債。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。