Model Context Protocol 团队已将其企业托管授权扩展提升至稳定状态，为企业通过身份提供商集中控制对 MCP 服务器的访问提供了一种方式。该项目的目标是取代每个服务器的单独授权提示，实现零接触访问流程：用户只需登录一次即可访问已获批准的服务器，无需进行额外的设置。
在发布声明中，MCP 团队表示该扩展现已稳定，并已被 Anthropic、Microsoft、Okta 以及越来越多的 MCP 服务器采用。文章指出，社区普遍反馈重复的授权提示是企业 MCP 部署中的一大痛点，因为标准模型是以用户为范围的，且与交互式身份验证惯例绑定，这在大型企业中难以规模化落地。
实际的效果是将授权决策转移到企业身份提供商，而非留给每位员工和每个服务器单独处理。文章指出，该方案可实现连接各类服务端时的“单点登录”体验，同时配置为用户自动继承企业已审批通过的服务端访问权限。该流程采用身份断言 JWT 授权授予机制（简称 ID-JAG），由 MCP 服务器的授权服务器将其兑换为访问令牌。
文章着重强调了这一架构的重要性：它将身份策略与工具调用本身分离。企业托管层决定用户是否可以将客户端连接到服务器，以及对应的权限范围，但在令牌颁发后不会检查 MCP 流量。指南中明确提示，这并非针对单步操作的运行时授权，这意味着企业仍需自行搭建管控体系，用于约束智能代理接入系统后的各类操作行为。
“企业可集中统一管理 MCP 服务端的授权权限，终端用户仅需一次登录，即可访问全部已对接的 MCP 服务端。”
—— Model Context Protocol 博客
本次发布称该扩展是针对 MCP 实际落地使用痛点推出的解决方案。文中表示，过去面向单用户的旧模式会产生大量人工接入配置工作，安全团队难以统一实现权限策略，还会混淆个人账户与工作账号的边界。与之相反，全新扩展支持管理员一次性配置权限策略，并通过其现有的身份控制措施应用该策略。
多篇第三方文章也得出了相同结论。Ehsan Hosseini 将 EMA 视为解决由每用户、每服务器 OAuth 机制造成的“混乱”的解决方案，并认为企业身份提供商将成为决定哪些客户端可以访问哪些服务器的主体。文章还提出了连接级控制与操作级控制之间的一个关键区别，认为 EMA 并不能取代针对敏感运行时行为的独立策略。Okta是本次发布中提到的第一个适配身份提供商，其跨应用访问方案是企业可选的首条接入路径。本次上线虽具备重要意义，但仍只是阶段性举措，因为该机制需要身份提供商与 MCP 服务端双方同时支持此扩展才能生效。Hosseini 指出，该协议仍然是附加性的，因此不使用支持身份提供商的企业仍然需要备用方案。
社区整体反响积极，大家尤为认可该扩展能够大幅降低使用门槛。Jiquan Ngiam 在 LinkedIn 上写道，该扩展有助于解决使用智能体处理数据时最棘手的一大痛点，并且可以通过避免尴尬的身份验证流程来改善安全性和可观测性。其他文章称 EMA 是 MCP 服务器访问的结构性修复，核心变革在于将逐用户弹窗授权模式切换为统一的企业控制平面。
“我们从社区了解到，来自已连接 MCP 服务器的授权和重复同意提示是企业管理连接性时最大的痛点之一。”
—— Model Context Protocol 博客
本次发布还强调了适配该扩展的生态系统。公告称，Anthropic 已在其面向 Claude、Claude Code 以及 Cowork 的通用 MCP 层中实现支持，Visual Studio Code 也新增了相关支持。在服务器端，Asana、Atlassian、Canva、Figma、Granola、Linear、Supabase 均已支持企业托管授权扩展，Slack 等产品的适配工作正在推进中。如此广泛的适配范围表明，该项目旨在让企业集中式授权成为标配能力，而不是需要额外定制对接的特殊功能。此次更新消除了企业落地 MCP 过程中最突出的运维阻碍之一，对于需要大规模将 AI 助手对接内部工具的团队而言，意义重大。
查看英文原文：https://www.infoq.com/news/2026/07/mcp-ema-enterprise-auth/
