6 月 18 日晚，Anthropic 旗下的 Model Context Protocol 官方博客 登了一篇题为《Enterprise-Managed Authorization: Zero-touch OAuth for MCP》的文章。Core Maintainer Paul Carleton 写得克制，但消息不小：EMA（Enterprise-Managed Authorization）扩展正式从草案转 stable，Hacker News 一小时内冲到 226 分。同一天，Anthropic、Microsoft、Okta 三家站台背书，Asana、Atlassian、Canva、Figma、Granola、Linear、Supabase 七家 SaaS 同步支持，连 Visual Studio Code 都在 IDE 层面接好了。
如果用一句话翻译成普通人的语言：MCP 终于给 AI Agent 发了一张正经的公司工号。
一、过去两年卡住企业落地的，到底是什么
过去 18 个月，MCP（Model Context Protocol）一直是 Agent 工具调用的事实标准。Anthropic 推出来、生态大爆发、几千个 server 冒出来——但企业 IT 一聊就摇头。原因写在官方博客的痛点段里，原文是这三条：
- 每个员工都得给每个 server 单独授权一次。Onboarding 一个新同事，IT 要陪着他把 Asana、Slack、Linear、GitHub、Notion 一个一个点同意；
- 安全团队没法强制策略。每个人自己点了什么就有什么，没有中心审计；
- 工作账号和私人账号混在一起。员工很容易用个人 Google Drive 接到 Claude 公司实例上。
这三条不是技术不行，是协议层就没给企业留入口。每家公司都自己造轮子，结果是 patch 套 patch。
二、Zero-Touch 到底 zero 掉了什么
新扩展的技术核心叫 ID-JAG（Identity Assertion JWT Authorization Grant）。把流程翻译成人话：
以前：员工登录 Claude → Claude 跳到 Asana → Asana 弹"是否允许 Claude 访问" → 员工点同意 → Asana 给 Claude 一个 token。每接一个工具都得来这么一轮。
现在：员工用公司 Okta 登录 Claude → Okta 在背后签发一个 ID-JAG → Claude 拿这个 ID-JAG 去跟 Asana 的授权服务器换 access token。屏幕上什么弹窗都没有，Asana 直接接上。
三个性质从这套流程里自然掉出来（这是官方原文的重点）：
- Authorise once, inherit everywhere：管理员在 Okta 后台勾一次"工程组可以用 Asana"，整个工程组就都能用，scope 跟着员工已有的 group 和 role 走；
- Centralised policy and audit：所有授权决定都在 IdP 后台产生，审计日志一站搞定；
- Personal / enterprise 不再混：交互式选账号那一步被砍掉了，“用私人账号连了公司数据"这种事故在协议层就被堵死。
对一个 500 人的公司来说，原来 IT 给新员工配 MCP 工具链要 2 小时，现在应该是 2 分钟。
三、首批吃螃蟹的 11 家，说明谁才是这次真正的甲方
博客里把首批合作方分了三组，我重新排了一下，因为分组本身就在讲故事：
身份提供方（也就是真正出钱的人）：Okta 一家。注意是 Okta，不是 Auth0、不是 Azure AD。背后是 Okta 在 2024 年发起的 Cross-App Access (XAA) 规范，这次直接被 MCP 拿来当底层。
客户端（消费方）：Anthropic 自家 Claude、Claude Code、Cowork 一条线全打通；Visual Studio Code 单独支持。Microsoft 的位置偏"投资方+生态合作”，不像 Anthropic 那么深扎进去。
服务方（被 Agent 调用的那批）：Asana、Atlassian、Canva、Figma、Granola、Linear、Supabase 七家。注意这七家全部是协作型 SaaS，没有一家是 ERP、没有一家是 Salesforce——这恰恰说明 MCP 在企业里最先跑通的，是"知识工作者日常用的工具"，而不是核心业务系统。
第一波客户画像很清楚：用 Notion / Linear / Figma 写文档画原型、用 Claude 读文档改稿的中小型科技公司。制造业、银行、保险——离这条线还远。
四、HN 评论里吵出来的两件事，博客没写
我把 HN 那 19 条置顶评论翻了一遍，有两条值得拎出来：
第一条：摩擦到底是敌是友？ 一个叫 amluto 的开发者直接说"这很疯狂"——他的论点是：
“假设我开一个 Claude 会话，让它去 fork 一个第三方 repo 并提 PR。如果那个 repo 里塞了 prompt injection，要触发一个把公司钱转走的 tool call，我绝对希望在这个动作发生前被弹窗提示。”
这条评论是对零摩擦最尖锐的反对。Okta 的 group / role 控制粒度再细，也拦不住"已授权账户被 prompt injection 操纵"这件事。换句话说，Zero-Touch 解的是 onboarding 摩擦，但task-level 的二次确认摩擦不能去掉——去了就是给攻击者发工资。
第二条：multi-hop delegation 还是个洞。 EMA 解决的是"用户登录 MCP host"这一跳。但 Agent 自己 fork 出来的子 Agent、sub-task 的 token 该怎么传？HN 那条评论里 niyikiza（就是发帖人自己）承认：OAuth 工作组里 multi-hop delegation 的草案还在写，WorkOS 出了一篇不错的 overview（OAuth Multi-Hop Delegation for AI Agents），但距离稳定还早。
换句话说：今天的 EMA 是企业 IT 的入场券，但还不是 Agent 自己的身份证。
五、对 builder 意味着什么
我自己在做产品时的判断，分两档：
如果是企业 IT / 安全团队：从今天起可以认真规划 MCP 部署路线图了。重点不是"接哪些 server"，而是先在 Okta 里把 group / role 矩阵梳理清楚。Asana / Linear / Figma 这些 server 已经 ready，公司一旦点头，部署周期是按天算的。
如果在做 Agent 产品：接下来 6 个月会出现两类明显的分化——
- 能讲清"我的 Agent 在企业里如何不越权"的产品会拿到合同。这不是营销话术，是采购流程里的硬问题；
- 只演示"Agent 怎么好用"的产品会卡在 PoC 阶段。不是产品不好，是 IT 那边过不了。
我个人下注的方向是：multi-hop delegation 的实现层。这是目前协议还没填上的洞，先做出来的会变成 Agent 时代的"session token provider"。WorkOS 已经在抢，但产品还很早期。
最后
MCP 这次 stable 之所以值得专门写一篇，是因为它不是模型层的新闻、不是融资新闻、不是产品发布新闻。它是协议层的入场券。Anthropic 一年前把 MCP 推开源的时候，社区最大的疑问是"它能进企业吗"。今天这个问题有了答案：能，但必须按企业的规矩来。
Agent 这一年的下半场，不再是"谁家模型更聪明"，而是"谁家的 Agent 能进会议室"。