摘要： MCP 的企業託管授權 EMA 於 2026 年 6 月 18 日進入穩定規格擴充，把授權決定從個別使用者同意改到企業 IdP。員工完成 SSO 後取得 ID-JAG，核准的 MCP 伺服器自動接通，不需逐一跳出同意頁。文章認為這降低管理摩擦，但提示注入與工具濫用防制仍在客戶端。
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 的落地障礙
目前各界支援的狀態如下：IdP 端由 Okta 率先支援。客戶端方面，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 的原生支援尚未到位，橫跨多個身分平台的大企業勢必得靠代理層的權宜方案，而這些應急手段正是日後升級時要償還的技術債。