Okta 的 AI 身份押注取决于 MCP 的经济性

尽管企业是否愿意为又一层控制机制付费仍存不确定性，Okta 已凭借一项具体的 AI 身份战略进入 Google News 的视野。该公司正围绕 AI 智能体、Model Context Protocol 连接，以及跨业务应用的委托访问来布局身份基础设施。

这项战略使 Okta 的定位不再局限于保障员工登录安全。它要求企业注册智能体、限制其权限、治理下游连接，并保留每一项委托操作背后人类用户的身份信息。

这让 Okta 进入了一场更广泛的竞争：谁来掌控企业 AI 活动。Microsoft、云平台、安全厂商和应用提供商都拥有可信的优势。Okta 的优势在于中立性，但它也必须证明，独立的身份层能够降低风险与运营成本。

这一核心说法需要谨慎看待。MCP 可以标准化智能体访问工具的方式，但该协议并不会自动降低模型使用量或基础设施支出。成本控制取决于工具发现、响应过滤、权限范围、可观测性，以及围绕各个服务器构建的架构。

因此，Okta 面临两项彼此关联的机会。它可以保护智能体访问安全，也可以帮助企业避免将不必要的工具、数据和凭证带入每一条工作流。第一项机会已体现在其产品中；第二项仍是需要客户验证的业务成果。

Okta 正将 AI 智能体转变为受治理的身份

Okta 的核心举措，是将每一个企业智能体视为拥有自身权限、连接和生命周期的身份。

Okta for AI Agents 提供了一个用于发现和注册智能体的控制平面。它还将这些智能体与经过批准的应用、API、凭证和 MCP 服务器连接起来。MCP 服务器是一种通过标准接口向 AI 应用公开工具或数据的服务。

这一架构解决了自主软件带来的问题。人类员工通常通过已获认可的身份提供商进入应用。而智能体则可能在 API、服务账户、存储的密钥和用户委托令牌之间穿行。

这些路径往往会产生碎片化记录。一个系统看到的是人类用户，另一个系统看到的是应用凭证，第三个系统则可能只记录服务账户。安全团队可能难以还原究竟是谁发起了一项操作，以及为何该操作获得许可。

Okta 希望让智能体成为一等身份。管理员随后便可将其关联至负责人，定义其可访问的资源，并在条件发生变化时暂停其访问权限。

该公司的 AI agent controls 介绍了与 Salesforce、AWS、Microsoft 和 ServiceNow 等环境的集成。Okta 表示，智能体可以导入 Universal Directory，为管理员提供集中式清单。

这份清单之所以重要，是因为企业很少通过单一协调计划部署智能体。开发人员会构建内部助手，业务团队会采用供应商智能体，而 SaaS 应用则会加入自主功能。由此形成的集合中，既可能包括获批智能体，也可能包括安全团队从未审查过的影子智能体。

仅靠注册并不能解决问题。只有当清单能够推动策略、访问审查、监控和终止操作时，它才有价值。否则，它只会成为另一份逐渐过时的资产列表。

Okta 的资源连接模型提供了这一执行路径。管理员可以定义智能体能够访问哪些下游资源，也可以在委托令牌、经纪式第三方访问和受管静态凭证之间进行选择。

该公司将 MCP 服务器作为一种资源类型提供支持。Okta 的文档称，其平台负责管理服务器注册、配置、生命周期检查和令牌交换关系。其 MCP server architecture 还区分了由 Okta 控制的授权与外部授权服务器。

Okta 的开源 MCP 服务器则采用了一种与管理自动化相关的方法。它将自然语言请求转换为结构化的 Okta API 操作，同时通过 OAuth 范围限制可用工具。

该服务器会根据授予的范围筛选工具，并在发起 API 调用前再次检查范围。当会话期间凭证发生变化，或刷新后的令牌携带更少权限时，第二次检查尤为重要。

一个实际示例可以说明这种差异。IT 助手可能需要列出被锁定的账户，但不应停用用户。基于范围的工具加载可以直接隐藏停用操作，而不是要求模型记住这项策略。

该模型减少了向智能体呈现的危险选项数量。它还将授权置于模型推理之外，使提示注入或错误计划无法轻易将其覆盖。

直接的变化并不在于 Okta 发明了智能体认证。OAuth、服务身份和特权访问控制早已存在。Okta 正将这些要素围绕智能体这一受治理对象进行整合，而不是将每个连接视作孤立的集成。

这种整合为 Okta 提供了及时的产品叙事，但尚未证明客户会在多大程度上采用、整合或围绕其扩大支出。

Google News 故事的核心其实是企业控制权

更深层的 Google News 视角并非又一次 AI 功能发布，而是企业智能体策略将部署于何处的竞争。

AI 智能体增加了应用内部由机器发起的操作数量。它们可以检索记录、准备文档、更改配置、创建账户或触发工作流。每一项操作在成为智能问题之前，首先都是一个授权问题。

谁请求了该操作很重要。智能体自身的身份很重要。目标应用很重要。所请求的操作以及人类用户现有的权限同样重要。

传统单点登录往往只回答第一个问题：谁登录了。自主工作流需要在登录后持续获得授权，尤其是在智能体跨越应用边界时。

Okta 的 Cross App Access，即 XAA，正是为这种情况设计的。它允许智能体通过受控的令牌交换，将身份和授权上下文带入下游应用。

身份提供商不会将可重复使用的密钥直接交给智能体，而是评估该请求，随后可为特定资源和获批范围签发令牌。

Okta 最初将 XAA 作为用于智能体到应用连接的开放协议推出。其最初的 Cross App Access plan 指出了一项常见弱点：用户往往需要针对每项集成分别进行身份验证并授予同意。

随着智能体连接到更多服务，这种方式愈发难以治理。授权同意页面将决策分散给员工，而静态凭证的存续时间可能超过创建它们的人员或项目。

XAA 将更多权限转移给身份提供商和企业管理员。策略可以在智能体请求访问之前完成配置，下游应用则可以验证由此产生的身份断言。

该模型已通过 Anthropic 的 Enterprise-Managed Authorization 工作获得实际支持。Okta 在 2026 年 6 月发布的一份 beta 指南将 Claude 描述为请求应用、Okta 描述为身份提供商，并将参与其中的 MCP 服务描述为资源应用。

Okta 记录的流程使用 Identity Assertion JWT Authorization Grant，简称 ID-JAG。Claude 提交已认证用户的 Okta 令牌，并为所请求的连接获取单独的断言。

该机制保留的上下文多于通用服务凭证。资源可以了解请求涉及的企业、智能体和用户。

此后，稳定版 Enterprise-Managed Authorization 已进入 MCP 生态系统。authorization extension 允许组织通过身份提供商配置受支持的服务器连接，而无需让用户分别完成 OAuth 流程。

这一进展为 Okta 的战略增添了分量。专有功能可能难以吸引生态系统参与者，而获得智能体客户端和资源提供商支持的协议，则更有机会成为基础设施。

Okta 于 2026 年 6 月宣布扩大 XAA 合作伙伴群体。名单包括从事智能体平台、企业应用和 MCP 基础设施的公司。这些关系只有在促成生产环境连接时才真正重要，但它们表明 Okta 并非孤立地构建这一机制。

压力落在多个群体身上。应用厂商必须决定是否接受企业管理的身份断言。AI 平台必须在工具调用过程中保留委托身份。安全团队则必须决定是否应由现有身份提供商来治理智能体。

Microsoft 构成了最清晰的结构性挑战。它掌控着重要的企业身份平台、生产力应用、云服务以及不断扩展的智能体环境。这种整合可能使 Microsoft Entra 成为已高度集中于其技术栈的客户的默认选择。

云平台同样管理工作负载身份和服务权限。SaaS 厂商可以在其自身应用中执行授权。API 网关和专用 AI 安全产品则可以在更接近执行的位置检查智能体流量。

Okta 的反驳理由是独立性。中立的身份层可以治理在一个云中构建、却访问多个其他厂商应用的智能体。当没有单一平台掌控完整工作流时，这一点很有价值。

如果集成仍然流于表面，中立性的价值便会下降。企业不会仅因为某个控制平面位于竞争产品之上便采用它们。它们需要一致的策略执行、可用的审计轨迹，以及对其智能体实际调用应用的支持。

MCP 成本控制始于更少的工具与更小的响应

身份策略可以影响 MCP 成本，但仅靠授权并不会让智能体变得低成本。

MCP 为模型发现和调用工具提供了一种通用方式。这种一致性减少了自定义集成工作，但当部署公开过多工具或返回过量数据时，也可能引入新的令牌、延迟和可观测性成本。

模型可能会将工具名称、描述、参数和响应模式作为上下文接收。更大的工具目录会消耗更多输入令牌，也让工具选择变得更困难。一次调用后的大型结果可能会消耗更多上下文。

这正是 Okta MCP 安全与成本控制可以交汇之处。权限范围狭窄的智能体应当只能看到其角色所需的工具。移除未经授权的工具，既能减少攻击面，也能降低上下文开销。

Okta 的开源服务器会根据授予管理应用的 OAuth 范围动态注册工具。如果凭证无法管理用户，相应工具便无需出现在模型的可用工具集中。

这是一项有用的架构特性。它让模型的工作环境能够反映外部策略，而不依赖于“不要使用危险工具”之类的系统提示词。

以调查登录失败的支持代理为例。它可能需要检索用户、检查系统日志并审查身份验证因素，但并不需要访问品牌设置、删除群组或移除应用的权限。

范围严格限定的服务器可以隐藏这些无关功能。模型需要处理的工具目录更小，管理员也能更清晰地界定其用途边界。

响应设计同样重要。请求列出所有用户可能返回数千条记录。将完整结果发送给模型会带来 token 成本、延迟和不必要的数据暴露。

服务端筛选可以只返回被锁定的用户，或按策略分组的数量统计。在靠近数据的位置执行代码，也能先完成计算，再向模型提供紧凑的结果。

独立研究进一步印证了更广泛的成本担忧。一项针对智能体编程任务的 2026 年研究发现，输入 token 占据了成本的大部分，而重复运行的总用量可能存在显著差异。研究作者还发现，更高的 token 消耗并不能稳定地带来更高准确率。

这些发现并未衡量 Okta 的产品。它们说明，买方应要求工作负载层面的证据，而不应假设标准化工具连接会降低支出。

因此，MCP 成本控制需要多个层面：

• 身份策略限制哪些智能体可以访问哪些服务器。

• OAuth 范围限制服务器暴露哪些操作。

• 工具发现机制避免在每次请求中加载全部架构。

• 服务端筛选减少返回数据的规模。

• 使用遥测将模型和工具消耗归因到某个智能体或团队。

• 预算和速率限制在循环产生失控活动前将其停止。

• 人工审批会中断破坏性或异常昂贵的操作。

Okta 直接覆盖前两个层面，并有助于实现最后的审批层。其 2026 年 MCP 发布说明描述了对 MCP Elicitation API 的支持，该 API 可在破坏性操作前要求人工监督。

该公司并不控制完整的成本结构。模型提供商决定 token 行为，智能体平台决定工具如何进入上下文，MCP 服务器开发者决定响应大小，企业团队则配置范围和审批策略。

这使得“MCP 成本控制”成为一个共享的系统问题，而非 Okta 的单一功能。Okta 可以通过确保智能体只获得经授权的访问来改善输入条件，但无法保证授予访问权限后的推理效率。

安全性和成本也可能背道而驰。一个权限严格受限的智能体，仍可能因其计划失败而反复调用已获批准的工具。一个成本低廉的工作流，如果使用了权限过高的凭证，仍可能不安全。

企业应同时衡量这两个维度。安全指标包括被拒绝的请求、未使用的权限、过时智能体、凭证年龄和特权操作。成本指标包括输入 token、输出 token、工具调用、重试、响应大小和延迟。

最可信的客户成果应将两者联系起来。例如，减少智能体获授权的工具集，既可以降低架构 token，又能减少攻击者可利用的特权路径数量。

在客户公开这类证据之前，成本论点仍只是最小权限原则可能带来的合理结果。不应将其表述为 Okta 本身已经验证实现的节省。

Okta AI Agents 仍面临采用与验证鸿沟

Okta 已建立连贯的控制模型，但其商业前景取决于超越演示和合作伙伴公告的生产环境采用。

第一个不确定性在于客户的紧迫性。企业显然担心智能体访问问题，但许多部署仍停留在有限试点阶段。只有少量内部助手的公司，可能会通过现有云角色和应用 OAuth 设置来管理权限。

当智能体在部门和供应商之间大量扩展时，Okta 的价值会更加凸显。届时，分散的资产清单、凭证和审批流程会造成运营摩擦。

该公司必须证明客户正在达到这一门槛。已注册智能体、活跃资源连接、受治理的 MCP 服务器和定期策略评估，比笼统的兴趣表述更能说明问题。

第二个不确定性是生态覆盖范围。XAA 在请求应用、身份提供商和资源应用都实现兼容流程时效果最佳。任何一个参与方缺失，都可能迫使工作流退回到静态密钥或单独的同意流程。

Okta 的合作伙伴扩展令人鼓舞，尤其是在 Claude 和参与的 MCP 提供商方面。不过，Beta 文档也暴露出部署限制。管理员必须正确配置应用、凭证、颁发者详情、委托调用方和资源连接。

这种设置因其明确性而提供控制力，但也会增加管理工作。买方会将这种负担与更简单的网关配置，或云和应用平台中已内置的原生控制措施进行比较。

第三个不确定性是协议成熟度。MCP 演进迅速，授权支持也随之变化。企业可能会遇到采用不同 OAuth 假设、不完整元数据或不兼容注册行为的服务器。

Okta 当前的帮助文档称，MCP 客户端必须预先注册，并使用机密授权码客户端。该工作流不支持动态客户端注册。

预先注册可以强化企业监督，但也可能拖慢围绕自动客户端接入设计的工具集成。Okta 必须在集中治理与推动 MCP 普及的开发者体验之间取得平衡。

第四个问题是人工委托。智能体可能完成了正确认证，却仍会超出用户意图行事。有效 token 证明某项请求满足了授权流程，但并不能证明模型正确理解了指令。

提示注入带来了相关缺口。恶意内容可以在认证后影响智能体。最小权限能够限制潜在损害，但不能消除模型层面的脆弱性。

持续授权可以有所帮助。身份层可以在签发 token 前评估范围、上下文和风险。应用可以对敏感操作要求更强验证。人工审批可以阻止破坏性操作。

这些控制措施减少的是暴露，而不是彻底消除风险。应将 Okta 视为更广泛智能体安全设计中的一层，该设计还包括模型防御、数据控制、运行时监控和应用授权。

第五个不确定性涉及竞争性回应。Microsoft 可以连接身份、生产力数据、Copilot、Azure 和安全遥测。Google 可以整合 Workspace、云身份和智能体开发服务。Cloudflare、API 管理公司及安全初创企业则可以在网关层治理 MCP 流量。

Okta 的主要防线是跨平台一致性。拥有混合云和 SaaS 组合的企业，可能更偏好一个独立的策略层。集中于单一平台的客户，则可能较少有理由增加这一层。

Okta 的财务状况使其有空间追逐这一机会，但投资者应将当前业务表现与未来 AI 收入区分开来。该公司在 2026 年 3 月公布了 2026 财年业绩，但其公开发布内容并未单独披露 AI 智能体产品带来的实质收入。

fiscal 2026 results 将 Okta 的更广泛使命描述为保护 AI、机器和人类身份。该表述确认了战略优先级，而非客户采用情况或产品贡献。

一个站得住脚的投资论点需要的不只是庞大的潜在市场。它还需要证据证明 Okta 能够将 AI 智能体治理纳入续约、扩大合同价值，并在捆绑式身份服务面前捍卫自身角色。

Google News 的关注可以放大这一叙事，但无法替代已披露的使用情况、客户案例或可持续的商业成果。

Okta 的 Google News 时刻之后应关注什么

三个信号将显示，Okta 的智能体身份战略是在成为基础设施，还是仍停留在有吸引力的产品叙事。

第一个信号是围绕 XAA 和 Enterprise-Managed Authorization 的生产环境采用。合作伙伴标志在标准制定期间很有用，但实时集成决定管理员能否治理真实工作流。

关注主要 SaaS 提供商是否会在正式可用产品中启用由 XAA 支持的 MCP 访问。同时也应关注企业客户是否描述跨越多个供应商的部署，而非单一受控演示。

广泛的生产支持将强化 Okta 的中立性论点。有限的支持则会让客户不得不在新系统之外继续管理例外、静态凭证和独立同意流程。

第二个信号是可衡量的产品使用情况。Okta 最终应提供诸如已注册智能体、活跃连接、受保护 MCP 服务器，或使用 AI 智能体治理的客户等运营指标。

收入披露将更具参考价值。买方和投资者需要了解，Okta for AI Agents 是推动新购买、扩展现有部署，还是主要用于保护核心平台免受竞争压力。

客户案例研究应包含安全成果。减少常驻权限、加快智能体取消配置、减少未受管理的凭证，或提升审计覆盖范围，都能在不依赖泛化 AI 需求的情况下证明价值。

成本成果需要独立证据。有用的衡量指标包括更小的工具目录、更低的输入 token 消耗、更少的重复调用和更低的管理工作量。Okta 应将这些实测结果与理论收益区分开来。

第三个信号是竞争对手和标准机构如何回应。Microsoft、云提供商、智能体平台和 MCP 网关供应商都可能采用类似的身份交换模式，或推广替代方案。

如果它们趋向于可互操作的企业授权，Okta 就可以在更大的市场中作为中立实施方案参与竞争。如果每个平台都构建封闭控制系统，客户覆盖范围和分发能力将变得决定性。

标准趋同并不能保证 Okta 的商业成功，但会验证对委托智能体身份的底层需求。碎片化则会增加集成成本，并削弱统一控制平面的承诺。

评估 Okta MCP 安全性的安全团队，应从一个受约束的工作流开始。选择一个代表已知用户访问敏感应用的智能体。定义狭窄的工具集，要求明确的范围，并记录每一项请求。

记录基于范围的工具筛选前后 token 消耗的变化。比较服务器在本地筛选数据时的响应大小。测试当用户、智能体或连接被暂停时，访问权限是否会消失。

随后对系统施压。引入一项超出智能体角色的请求，在活跃会话期间撤销某个范围，并对破坏性操作要求审批。结果会比精心打磨的演示揭示更多信息。

知识工作者同样与结果息息相关。智能体正日益在文档、日历、消息和内部知识系统之间移动。清晰的委托身份可以帮助用户了解，哪个助手在谁的授权下访问了哪项资源。

通过 google news 跟进这一事件的读者，应将三项主张区分开来。Okta 已为智能体推出了有实际意义的身份基础设施。MCP 治理能够减少不必要的访问权限与上下文暴露。但这两点都不能保证运营成本下降，或带来显著新增收入。

这一战略机遇确实存在，因为智能体连接正逐渐成为一个授权问题。Okta 现在需要证明，企业希望采用独立的控制平面，供应商会支持其流程，以及严格的访问控制能够产生可量化的成果。

这些证据将体现在部署情况、使用指标和客户成果中，而非下一条新闻标题。问题在于，Okta 能否将其在 google news 上的曝光度，转化为跨竞争性企业平台运行的智能体所默认采用的身份层。