AI Agent 的身份层生意：下一道入口，还是旧身份管理的新外壳？

开场：当 AI 开始替你办事

一个AI助手要替你查邮件、读文档、改代码、提交工单，真正难的地方很快就不在模型会不会做，而在它凭什么可以做。它用谁的身份登录，拿到多大的权限，做完之后谁来审计，出了问题能不能立刻收回。这些问题听起来像企业IT部门的老话题，却正在变成AI Agent走向实际工作的入口。今天要拆的，就是这道入口上的生意。

先把几个词说清楚。OAuth可以理解成一种授权委托机制：用户或系统不必把密码交给每一个应用，而是发一张有范围、有期限的通行证。应用拿着这张通行证去办事，权限可以被限制，也可以被撤回。AI Agent要接进企业的邮箱、文档、代码库和业务系统，绕不开这套通行证逻辑。它的关键不是证明你是谁，而是决定你能做什么。

这里要分清认证和授权。认证回答“你是谁”，授权回答“你能做什么”。很多Agent产品演示只强调登录成功，听起来很顺，真正的风险却在后半段：登录之后它能读哪些文件，能不能发邮件，能不能改数据库，能不能把数据带到外部。身份层的生意，主要不在认证那一下，而在授权之后的持续管理。

协议先解决连接

MCP则是另一层。它全称是Model Context Protocol，中文可以叫模型上下文协议。Anthropic把它定位成连接AI助手与数据源、业务工具和开发环境的开放标准。过去每个模型接每个工具都要单独适配，MCP想做的，是把接口和消息格式统一起来，让工具一次接入、多个AI应用复用。它更像插座标准，而不是某一件电器。

2024年11月，Anthropic开源了MCP，同时发布规范、软件开发工具包和服务器示例。这个动作的重要性不在于又多了一个协议，而在于它把“AI调用外部工具”从各家私有插件，推向可复用的公共接口。接口一旦统一，下一层问题就会暴露出来：谁来确认这个调用者有权调用，调用范围又该由谁划定。

连接和授权是两件事。MCP解决的是怎么连、怎么描述工具、怎么把结果传回来。它不自动回答另一个问题：这次调用代表谁。是代表用户本人，还是代表一个被用户委托的Agent，还是代表企业里一个独立注册的自动化账号。三种答案，对应的权限边界和审计责任完全不同。

这就是Agent身份层的起点。传统软件里，用户登录之后操作系统；Agent则常常是用户不在场时继续行动。它可能在你睡觉时整理资料，也可能在几秒钟内连续调用十几个工具。人类账号体系默认有一个人在屏幕前做判断，Agent体系必须假设行动可以由机器发起，而且速度远高于人工审批。身份系统因此要从“登录入口”变成“行动约束”。

2025年6月18日的MCP授权规范，把这个难题拆成了三个角色：MCP客户端、MCP服务器和授权服务器。客户端发起请求，服务器提供工具或数据，授权服务器负责发放和校验授权。规范把三者分开，等于承认身份与资源不应该是同一个黑箱。这个拆分看起来是技术细节，实际决定了责任能不能被追踪。

这三个角色换成日常语言就清楚了。客户端是那个想办事的Agent或AI应用；服务器是掌握数据或工具的一方，比如文档系统、工单系统；授权服务器是发通行证的窗口。分开之后，资源方不必自己实现一套完整登录，身份方也不必知道每个工具的具体业务逻辑。各自做擅长的事，授权关系才有机会被标准化。

这份规范还有一个关键细节：授权是可选能力。它主要界定HTTP传输方式下的授权流程，并借用OAuth 2.1草案，以及RFC 8414、RFC 7591、RFC 9728等机制。规范没有另起一套登录体系，而是在既有授权协议上做适配。可选，意味着不同MCP服务器可以给出完全不同的安全强度。生态会很长尾，也会很参差。

这会带来一个现实后果：Agent能不能接进企业，不取决于协议理论上多完整，而取决于具体服务器有没有把授权、范围限制、令牌刷新和撤销做扎实。企业采购时看到的将不是一份漂亮的规范，而是一堆接入方案，每一家的权限粒度、日志和失效机制都不一样。标准降低了连接成本，也把安全差异暴露得更清楚。

身份厂商开始补位

身份厂商已经开始往这个缺口里填产品。Auth0宣布其AI Agents产品进入开发者预览，列出的能力包括用户认证、OAuth令牌管理与刷新、异步授权，以及面向检索增强生成的细粒度授权。检索增强生成就是常说的RAG，让模型先查企业资料再回答。产品清单不长，但每一项都卡在Agent落地的痛点上。

令牌管理与刷新，解决的是Agent长期运行的问题。通行证不能永久有效，过期之后要有安全的续期方式；续期时如果不再确认用户意图，权限就可能悄悄扩大。异步授权解决的是用户不在场时如何确认一次敏感操作。细粒度授权解决的是Agent只能读某一份资料，而不能顺手读整个知识库。三件事都指向同一个方向：身份不再只是一次登录，而是一段持续的关系。

异步授权值得多讲一句。人类操作时可以弹窗确认，Agent在后台跑任务时，弹窗可能没人看。如果每次都要求本人在场，自动化就失去意义；如果完全不要求，风险又失控。身份产品要做的，是把确认变成可配置的流程：哪些动作可以预先授权，哪些必须实时批准，哪些只能在限定时间内有效。这套流程本身就是企业治理能力。

细粒度授权则直接决定RAG能不能进企业。企业知识库往往混合了公开资料、部门文档和敏感记录。Agent如果只有一个“读知识库”的总权限，检索时很容易把不该看的内容带进回答。身份层需要把权限细到文档、字段、标签或用户组，并且让检索过程也受同一套规则约束。否则模型越能干，越容易放大越权访问。

目录与平台争夺控制点

微软的动作更靠近企业目录。Microsoft Entra文档把agent identity描述为Entra ID中用于AI Agent的身份账户，提供独立识别和认证能力，文档日期是2025年11月6日。换句话说，Agent不再借用某个员工的账号，而是可以在企业目录里拥有自己的身份记录。这个变化看似只是多了一种账号类型，实际改变了治理对象。

一个独立身份可以被分配权限、加入策略组、被审计、被停用。员工离职时，企业不必再猜他名下的Agent还在不在跑；安全团队也能把Agent的行动和人类账号分开看。身份层真正的价值，往往不在登录那一刻，而在登录之后能不能持续治理。目录之所以重要，是因为它同时是权限、策略和审计记录的落脚点。

平台侧也在争这个控制点。OpenAI的Responses API文档允许模型通过远程MCP服务器，或者通过Secure MCP Tunnel安全隧道调用外部服务。工具调用可以设置为自动允许，也可以要求开发者显式批准；需要认证的MCP服务器可以使用OAuth访问令牌。这里出现了两种治理思路：平台内审批，和标准授权。一个靠近应用，一个靠近企业身份系统。

平台内审批的好处是立刻可用，开发者在自己的应用里就能控制风险。坏处是治理边界停在平台内部。企业如果同时使用多个模型平台、多个Agent框架和大量MCP服务器，就需要一个跨平台的权限视图。这个缺口，正是独立身份产品和云身份平台的机会。但机会能不能变成收入，还要看企业愿不愿意为“统一视图”单独付费。

2026年8月10日的OpenAI企业版与教育版发布说明，给了一个更明确的信号。OpenAI计划停止新的个人授权同步连接，并关闭既有的个人同步连接；管理员管理的同步不受这项变更影响。这条调整没有解释全部原因，但它把“个人授权”和“管理员管理”划出了不同待遇。企业产品的治理偏好，往往就藏在这种差别里。

对企业来说，这个方向不难读：连接可以开放，治理必须收口。个人用自己的账号把外部工具接进企业环境，权限来源分散，离职、审计和撤回都更麻烦。管理员管理的同步保留了集中授权路径，也就保留了企业身份系统作为总闸的位置。这不是某一家公司的独有逻辑，而是企业软件采购的常见逻辑：先问谁能管，再问好不好用。

控制点不等于生意

现在回到生意本身。要验证的问题是：当Agent大量接入企业工具后，身份、授权、令牌、审计和最小权限，会不会形成一个独立、可收费、可持续的软件层。两种判断，决定价值最终流向谁。

如果身份层独立，价值会流向专门管理Agent身份、委托关系和跨平台权限的厂商；如果只是功能延伸，价值会被微软这类既有身份平台，以及OpenAI这类Agent平台顺手吃掉。判断标准不能靠概念热度，要看谁掌握采购入口、谁的系统成为记录源、谁能证明自己不可替代。身份生意最怕的，是功能很重要，但谁都能免费送。

从历史看，OAuth和企业身份管理都不是新东西。真正变化的是调用者的数量和行动速度。过去一个企业里需要授权的应用数以百计，现在每个Agent都可能带着一组工具、一串令牌和一条委托链。应用数量增长还可以靠人工审批，Agent的调用频率和组合方式会把人工审批变成瓶颈。身份系统必须从静态配置转向动态约束。

这里要区分两种身份。第一种是用户委托：Agent代表某个具体的人行动，权限不应超过这个人本身。第二种是Agent自有身份：Agent作为企业目录中的一个独立主体，被授予一套专门权限。两种模式可以并存，但治理难度不同。委托模式考验的是范围收缩和代理链审计，自有身份考验的是生命周期和权限归属。

Auth0的产品描述同时覆盖用户认证和Agent相关能力，微软则把Agent做成目录中的身份账户，OpenAI在平台层提供审批和OAuth令牌。三条路线放在一起看，身份层并不是单一产品，而是一组控制点：谁发令牌，谁定义范围，谁记录行动，谁能一键停用。控制点越多，越容易出现责任缝隙，也越需要统一治理。

企业买单的理由通常很具体。安全团队要能看到Agent访问了哪些数据；合规团队要能回答某次操作是谁授权的；IT团队要能在员工转岗或离职时切断相关权限；业务团队要能快速接入新工具，而不是每接一个就重做一次登录。身份层如果能同时满足这四件事，它就不只是一个技术组件，而是采购流程中的必需项。

审计和撤销尤其关键。Agent的错误往往不是一次明显的入侵，而是一连串看似合理的越权调用。令牌有效期多长，刷新时要不要重新确认，权限能不能细到单个文档或单个工具，出问题后能不能只停某一个Agent而不影响其他自动化，这些细节决定了身份产品是锦上添花，还是企业敢不敢把核心系统交出去的前提。

竞争格局也不会只剩创业公司。既有身份与客户身份管理厂商、云身份平台、Agent平台，以及专门做MCP安全中间件的团队，都在这条线上。OAuth本身是公开标准，MCP规范也是开放的，企业目录和访问控制又早已存在。任何一家想收独立费用，都必须证明自己提供了跨平台、可持续、可审计的增量价值。单点登录不是护城河。

这就是独立身份层面对的最大压力：捆绑。微软可以把Agent身份放进Entra，云厂商可以把权限控制放进既有云平台，Agent平台可以把审批做进产品界面。对客户来说，少接一个供应商、少签一份合同，往往比多一个专门功能更有吸引力。独立产品若只做令牌转发，很容易被替代；若做跨平台治理和审计，才有议价空间。

商业化路径目前只能作为假设来讨论。可能按Agent数量收费，可能按连接数收费，可能按令牌签发或工具调用量收费，也可能把身份能力打包进更高等级的企业套餐。公开资料没有给出客户付费、续约、市场份额或单位经济数据，所以现在不能判断哪种模式已经跑通，也不能给出市场规模。能讨论的是收费位置，不是收入数字。

按调用量收费听起来顺理成章，实际很难。Agent的调用次数可能波动极大，企业会担心账单不可预测；身份校验又常常发生在后台，业务部门感知不到价值。按Agent或按连接收费更稳定，但也容易被平台内建功能压价。计费单位如果和风险控制脱节，客户就会把它当成过路费，而不是治理投资。

真正能支撑溢价的，可能是审计、跨平台策略和事故后的快速止损，而不是单纯的登录接口。登录接口容易标准化，也容易免费；审计记录、策略编排和撤销速度，牵涉企业流程和数据积累，替换成本更高。身份产品的价值曲线，往往随着Agent接入深度上升，而不是随着登录次数上升。这也是它需要时间验证的原因。

渠道、标准与路径依赖

渠道差异也值得看。微软的优势在企业既有目录和采购关系，Agent身份可以顺着Entra进入客户环境；Auth0的优势在开发者体验和身份接口，适合先把Agent应用接起来；OpenAI的优势在模型和工具调用的入口，开发者可能先在平台内完成审批，再考虑外部身份系统。三种渠道，决定三种不同的收费位置。

Auth0这类开发者优先的路径，起点通常是一个具体应用。开发者先解决登录、令牌和授权流程，再逐步把同一套能力扩展到更多Agent。好处是落地快，坏处是每个应用都要自己接一遍，企业级统一治理要等到规模上来才显现。开发者喜欢的东西，不一定是采购部门愿意单独买单的东西。

OpenAI这类平台路径，起点是模型调用。工具审批、OAuth令牌和远程MCP服务器都在平台文档里，开发者顺手就能用。平台因此掌握了第一道闸门，也容易把身份能力变成平台体验的一部分。对独立身份厂商来说，平台既是流量入口，也是潜在竞争者。合作与替代会同时发生，边界取决于企业是否坚持跨平台治理。

这也解释了为什么身份厂商要抢在Agent大规模落地前发布产品。等企业已经把权限写进某个平台的工作流，再迁移成本就高了。身份系统有很强的路径依赖：目录是记录源，策略围绕目录生长，审计日志也围绕目录沉淀。谁先成为Agent身份的记录源，谁就更容易拿到后续的权限治理预算。先发不一定赢，但晚到通常更贵。

不过，开放标准也会削弱先发优势。OAuth是公开的，MCP规范是开放的，授权服务器可以自建，云平台也可以内建。标准让互操作变容易，也让单点功能更难收费。厂商真正的壁垒，不在协议本身，而在企业目录的嵌入深度、审计数据的连续性，以及出了事故之后客户愿不愿意换掉它。标准负责扩散，信任负责收钱。

边界与观察点

要判断这个市场是否真的成立，下一步可以盯几类硬指标。第一，相关产品是否从开发者预览走向正式可用，价格是否公开；第二，企业身份平台是否提供Agent专用的审计、撤销和委托链管理接口；第三，MCP服务器生态里，真正实现标准授权的比例有多高；第四，是否有企业公开披露部署规模和事故处置案例。

还有一类指标更直接：收入。如果Agent身份能力开始成为独立收入线，厂商会在财报或产品分级里体现出来；如果它只是提高既有身份套餐的客单价，也能从定价结构里看出痕迹。目前公开资料只证明厂商在布局，没有证明这条线已经形成可量化的独立收入池。这是判断时必须保留的边界，也是下一阶段最值得追的证据。

规范边界也不能忽略。MCP授权规范主要界定HTTP传输方式，本地部署、远程部署和不同工具粒度下的权限如何统一，仍需具体实现来回答。授权是可选能力，这句话本身就意味着生态里会出现安全水平的巨大差异。企业不能因为用了MCP，就默认权限问题已经解决。协议给的是接口，治理要靠产品和流程补上。

委托链是另一个未解点。用户把权限授予Agent，Agent再调用另一个Agent或另一个工具，权限应该逐层收缩还是可以继承？令牌过期后由谁刷新？出现越权时，责任落在用户、Agent开发者、工具提供方还是身份平台？这些问题没有统一答案，也决定了身份层产品能走多深。谁能把委托链讲清楚，谁就更接近企业核心系统。

反方判断也值得认真对待。企业可能更愿意使用平台内建的审批、MCP服务器自身的授权，以及既有身份提供商的能力。若这三者已经覆盖主要场景，独立的Agent身份层就很难形成足够大的市场。它可能长期作为一个功能模块存在，而不是一家独立的平台公司。功能模块也能赚钱，但估值逻辑和平台公司完全不同。

结论

所以更稳妥的结论是：身份层正在成为Agent进入企业的控制面，但“控制面”不等于“独立生意”。短期内，最确定的赢家是那些已经掌握企业目录、开发者入口或模型调用入口的厂商；独立厂商的机会，在于跨平台治理、审计深度和事故止损速度。下一步的核心观察点，是正式商用与定价、标准授权的采用比例、企业部署案例，以及厂商是否披露相关收入。

如果要用一句话概括这期判断：AI Agent的身份层，先是一道采购门槛，然后才可能是一门生意。门槛来自企业不敢把核心系统交给一个无法审计、无法撤销的自动执行者；生意则取决于身份产品能不能在多家平台之间提供不可替代的治理能力。入口不在聊天框里，而在管理员的后台。谁掌握后台，谁就离预算更近。

下次看到某个Agent产品发布，不妨多问一句：它用的是谁的身份，权限到哪里为止，出事之后谁来按下停止键。这三个问题，比演示里能自动完成多少任务，更早决定它能不能进入真实的企业环境。身份层的故事，说到底就是一句话：让机器替人行动之前，先让责任找得到落点。