让 AI 自己调用工具前,公司要先解决这件小事

MCP 官方把 Enterprise-Managed Authorization 标为稳定，表面看是一次登录流程更新；更实际的变化是，Agent 要进公司系统，先得解决“谁给它钥匙、钥匙能开哪些门”。

这次 MCP 更新说了什么

它更像一层权限底座，决定 Agent 能不能安全进入企业系统。

6 月 18 日，MCP 官方博客宣布 Enterprise-Managed Authorization 扩展进入稳定状态。它允许组织通过可信身份提供方集中配置 MCP server 访问。用户第一次登录 MCP host 时，管理员批准过的 server 会自动接上，不需要每个应用再弹一次 OAuth 同意。

这件事听起来很后台，但它解释了 Agent 落地时常被忽略的一步：模型可以决定调用工具，企业要先决定它有没有资格调用。官方提到 Okta、Anthropic、VS Code，以及 Asana、Atlassian、Canva、Figma、Granola、Linear、Supabase 等早期参与方。名单本身说明，这不是实验室里的小修小补。

Agent 调用工具之前，企业先要决定它能拿到哪些权限。

为什么会卡在登录这里

消费者场景可以让用户自己点同意，企业场景不能把权限交给临时选择。

标准 MCP 授权偏向个人交互：每个员工自己给每个 server 授权。问题很快出现。新人入职要一个个连服务；安全团队难以统一策略和审计；员工可能把个人账号接进工作工具，把数据边界搅在一起。

放到 Agent 场景，这个问题会放大。过去人点错登录账号，只影响一次操作；现在 Agent 可能连续读文件、查工单、写数据库、发消息。权限如果靠个人临时点选，后面很难解释谁批准了哪一步。

每个工具各弹一次授权，企业很快会看不清权限从哪里来。

授权一次，也不是放开所有门

企业托管授权的价值，在于集中治理，而不是让 Agent 更自由。

官方方案把组织的身份提供方放在决策位置。管理员先定义策略，用户登录后，系统再按组织、角色和条件访问规则决定哪些 MCP server 可用。底层流程会用身份断言换取 server 访问令牌，用户不必在每个 server 前重复走同意页面。

这里要克制一点。少点几次按钮不等于安全。真正有价值的是三件事：统一策略、统一审计、减少个人账号和企业账号混用。换到日常语言，就是公司知道这把钥匙发给了谁，也知道它开过哪些门。

统一授权的重点是能审计、能收回。

普通团队该怎么判断

以后看 Agent 产品，先别只问它能连多少工具。

Gemini CLI 把 Agent 放进终端，n8n、Dify 这类工作流平台在接更多自动化节点，AWS 也把 Web Search 做成 AgentCore 里的 MCP 兼容工具。工具越来越多，问题会回到同一个地方：这些连接由谁授权，由谁撤销，由谁复盘。

团队可以直接问四个问题：它能否使用公司身份登录；权限能否按部门、角色或条件继承；每次工具调用有没有日志；个人账号能不能被挡在工作流外。四个问题说不清，这类 Agent 先别急着进核心系统。

Agent 产品能不能进核心系统，要先过身份、角色、审计和账号隔离四关。