MCP 现在遇到的一个企业问题很具体：一个 AI 客户端要连 Asana、Figma、Atlassian、Linear 等服务，员工可能要一个个点 OAuth 同意。

个人用，这不算大事。放到公司里，就变成安全团队很难放心的事：谁授权了什么、用了哪个账号、权限有没有越界，都可能散在不同流程里。

MCP 社区在 2026 年 6 月 18 日宣布，Enterprise-Managed Authorization（EMA）扩展进入稳定版。我的判断是，EMA 更像是 MCP 进企业前必须补的一块治理拼图，而不是面向普通消费者的登录体验改版。

逐个 OAuth 同意，在企业里会失控

标准 MCP 授权沿用的是常见互联网应用模式：用户看到授权页，自己决定是否允许某个应用访问某项服务。

这套模式适合个人。因为数据归个人，选择也归个人。

企业场景不同。员工代表公司使用工具，访问的是团队文档、项目记录、设计稿、代码和客户相关数据。授权按钮看似只是一次点击，背后却牵着账号边界和审计责任。

问题主要出在三处：

问题传统逐服务 OAuth企业真正需要的做法
谁来决定员工逐个点同意管理员按组织策略配置
权限怎么控依赖用户选对账号、选对权限继承组、角色、条件访问规则
怎么审计授权记录分散在各服务里回到身份平台和授权链路里看
出错风险工作账号和个人账号容易混用用企业身份边界约束访问

所以，EMA 要解决的不是“少点几个按钮”这么简单。

它要把 MCP 服务器访问权，从员工临场判断，移回企业身份系统。对 IT 和安全负责人来说，这才是关键。

如果一个 AI 工具只支持手工 OAuth，企业采购时就会多问几句：能不能按部门开通？离职后权限怎么收？日志在哪里？个人账号混进去怎么办？这些问题答不清，上线就可能被延后。

EMA 的零接触，不是无权限

EMA 的流程可以压缩成一句话：用户通过企业 IdP 单点登录，客户端拿到 ID-JAG，再向 MCP 服务器的授权服务器换取访问令牌。

这里的 ID-JAG，全称是 Identity Assertion JWT Authorization Grant。它是客户端向后续授权服务器证明企业身份与授权上下文的一段凭据。

用户体验上，变化很直接：员工不再被逐个重定向到每个 MCP 服务器的 OAuth 同意页。只要企业策略允许，客户端就能自动连接已授权服务。

但“零接触”不等于“无控制”。

访问仍由 IdP 决定。组、角色、设备状态、条件访问规则，仍然会影响用户能连哪些 MCP 服务器、能拿到什么范围的访问令牌。

这和企业软件里常见的 SSO、SCIM、条件访问是同一类思路。Slack、Google Workspace、Microsoft 365 这类工具能进大公司，不只是因为好用，也因为它们能被管住。

MCP 如果要成为 AI 代理连接企业系统的通用层，也绕不开这道门槛。能连，是产品能力；可控地连，才是企业能力。

现在能说明什么，还不能说明什么

EMA 已进入稳定版，说明它不再只是纸面设想。早期生态也有了几个锚点。

Okta 是首个支持的 IdP，依托其 Cross App Access。客户端侧，Anthropic 在 Claude、Claude Code、Cowork 的共享 MCP 层支持 EMA，Microsoft 的 Visual Studio Code 也加入支持。

服务器侧，已有 Asana、Atlassian、Canva、Figma、Granola、Linear、Supabase 等支持。Slack 仍在添加支持中。

这批名单说明，EMA 已经具备早期落地基础。但边界也要说清：它是 MCP 的扩展机制，不是强制替换现有 OAuth；也不能据此认为所有 IdP、所有 MCP 客户端、所有服务器都已经支持。

企业现在更应该做的是检查条件，而不是直接把它当成默认可用能力。

落地前要确认为什么重要可能动作
IdP 是否支持 EMA没有身份平台支持，集中授权无从谈起Okta 用户可优先评估；其他 IdP 用户先等路线图
客户端是否支持 ID-JAG客户端拿不到凭据，就无法完成后续交换采购 AI 客户端时把 EMA 列入安全要求
MCP 服务器是否支持授权交换只支持旧 OAuth 的服务仍要手工授权优先接入已支持的 SaaS，内部系统排期改造
审计日志是否可查没有日志，安全团队很难复盘访问链路要求供应商说明日志字段、留存和导出方式
回退方案是否清楚早期生态难免有覆盖空白保留传统 OAuth 或分批开放，避免一次性迁移

对企业 IT 和安全团队，比较现实的做法是：把 EMA 当成 MCP 工具采购和试点的加分项，甚至是高风险数据场景的前置条件。

对 MCP 客户端和服务器开发者，压力也很直接。客户端要处理 ID-JAG，服务器要支持对应授权交换，身份平台要把策略和审计能力接稳。谁先补齐，谁更容易进入企业试点；谁只保留手工 OAuth，谁在合规评审里会被卡得更久。

接下来真正要看的变量有三个。

一是 Okta 之外的身份提供商是否跟进。二是 Claude、VS Code 之外的主流 MCP Host，是否把 EMA 做成企业配置里的常规选项。三是服务器侧支持能否从第一批 SaaS 扩到更多内部系统和私有部署。

如果这三件事推进顺利，EMA 很可能成为企业部署 MCP 时替代逐个 OAuth 的默认安全路径。反过来，如果支持范围长期停在早期生态，它就会更像少数先进客户的治理插件，而不是企业 MCP 的通用底座。