Okta AI Agent Security 瞄准企业困惑

Okta 为其 AI agent security 布局锁定了一个不同寻常的对手：客户的困惑，而非另一家安全厂商。总裁兼首席运营官 Eric Kelleher 于 2026 年 9 月 9 日在 Goldman Sachs Communacopia + Technology Conference 上提出了这一观点。

这一论点反映出当前市场的现状：企业希望采用自主软件，却难以界定究竟哪些内容需要得到保护。一个 agent 可能总结邮件、更新销售记录、批准退款，或管理完整的财务流程。每种角色都会带来不同的权限、风险和问责要求。

Okta 希望让身份成为整合这一混乱局面的核心层。其框架提出三个问题：agents 在哪里、它们能连接什么、以及它们能做什么？Microsoft 正通过 Entra Agent ID 和 Agent 365 追求类似目标，这使企业级分发能力与安全设计同样重要。

这种竞争改变了 Okta 信息传递的含义。困惑既可能为独立身份提供商打开市场，也可能拖慢采购进程，并让捆绑式平台更具优势。Okta 必须将紧迫的安全叙事转化为可重复部署、可衡量的采用情况，以及客户可跨供应商使用的标准。

Okta AI Agent Security 从三个问题开始

Okta 当前的举措是将庞杂的安全问题归结为 agent 发现、连接控制和授权。

在 9 月的会议上，Kelleher 表示，客户在看到有关自主 agents 的令人警惕的报道后，开始向 Okta 寻求帮助。这些买家了解 agents 会引入风险，但往往缺乏一套共同的模型来评估这种风险。

Okta 给出的答案是其 Blueprint for the Secure Agentic Enterprise。该公司于 3 月推出这一框架，并于 2026 年 4 月 30 日正式全面推出 Okta for AI Agents。该产品将熟悉的身份控制扩展至自主及半自主软件。

第一个问题“我的 agents 在哪里？”涉及资产清单和归属。员工可以在没有正式部署流程的情况下启用工具，而开发人员也可以在众多云平台上创建 agents。安全团队无法治理自己无法识别的 agent。

Okta 的 Agent Discovery 功能旨在暴露这些隐藏部署。根据该公司的 agent discovery details，它会检测 OAuth 授权活动，并识别涉及未经批准 agent 平台的连接。

OAuth 授权允许应用程序在不获取用户密码的情况下，获得访问另一项服务的许可。当员工授权未知 agent 读取邮件、文件、日历或客户记录时，这种便利就会转化为风险。

Okta 表示，浏览器信号可以揭示客户端应用、所连接的资源以及请求的权限范围。管理员随后可以注册该 agent、指定人工负责人，并应用基线策略。

第二个问题“agents 能连接什么？”将关注点从资产清单转向访问路径。一个 agent 可能与应用程序、API、数据库、工具或 Model Context Protocol 服务器交互。MCP 是一种标准接口，使 AI 系统能够访问外部工具和信息。

Okta 的蓝图包括用于协调这些连接的网关、凭据保险库和 API 访问管理。这些控制旨在用基于身份、上下文和风险的更精细决策，取代范围宽泛且长期有效的凭据。

第三个问题“agents 能做什么？”触及了最困难的一层。知道一个 agent 可以进入某个系统，并不能说明它是否能够读取、写入、转移、批准或删除信息。

Okta 提议记录单个工具调用和授权决策。它还推广 Universal Logout，作为一种可撤销 agent 在已连接系统中访问令牌的终止开关。

这一框架之所以重要，是因为 agent 并不只是另一种员工账户。它可以快速执行大量操作、组合跨系统的信息，并在周围上下文发生变化时改变其行为。

它也不同于传统服务账户，后者通常执行可预测的自动化任务。AI agent 可以选择工具、生成中间计划，并通过用户委托的权限采取行动。

因此，Okta 的三个问题构建了一种有用的采购框架。它们并不能证明每项底层控制都能跨所有 agent 平台正常运作，但为安全负责人提供了共同的语言，以决定必须测试什么。

这种共同语言是该公司战略的基础。Okta 希望企业将 agent security 视为身份治理的延伸，而非一个孤立的 AI monitoring 类别。

困惑同时带来了需求与延迟

促使客户转向 Okta 的同一份不确定性，也可能延长评估周期，并阻碍 agent security 成为一项可预测的业务。

Kelleher 称，困惑是公司当前在 agentic identity 领域最大的竞争对手。买家面临来自安全厂商、云服务提供商、AI 开发商和治理平台的相互竞争的主张。许多产品使用相似的语言，却保护着不同的层面。

一家厂商可能扫描 prompts 中的恶意指令。另一家可能发现 machine identities 或暴露的凭据。第三家可能控制网络流量，而身份提供商则决定哪个 agent 可以访问特定应用程序。

这些功能可以彼此补充，但企业仍需确立责任归属。安全团队可能控制访问策略，开发人员负责 agent，而业务部门则定义可接受的操作。

当组织无法回答有关部署的基本问题时，采购会变得更加困难。一家公司可能知道员工在使用 AI assistants，却不知道哪些 assistants 拥有长期有效的应用程序权限。

对 agent 的定义也仍不一致。有些系统是提出操作建议的聊天界面，有些会在人类批准后执行流程，而自主 agents 则可以在不逐步审核的情况下行动。

这种模糊性影响定价和产品衡量。Kelleher 表示，Okta 目前将其 agentic offering 定价为按用户计费的增值服务。他承认，这一模式并不完全适合 agent architecture，但称其便于客户采购。

根据他在会议上的发言，大多数早期交易都是一年期协议。Okta 预计，在续约前，双方都会对 agent 使用情况和运营成本获得更充分的信息。

这种方法降低了即时采购摩擦，也揭示出市场仍处于多么早期的阶段。成熟的安全类别通常具有更清晰的计量单位，例如用户、设备、工作负载、交易或受保护的数据量。

Agent 活动可能横跨所有这些单位。一名员工可能使用多个 agents，而一个 agent 则可能生成临时工作单元，或执行数千次工具调用。按用户计费的模式可能会与实际受保护的工作负载脱节。

Okta 的优势在于其与企业身份团队既有的关系。Kelleher 表示，已有超过 20,000 家公司将人类和非人类身份托付给 Okta。这一已安装基础为其进入安全讨论提供了直接路径。

不过，信任并不能消除实施工作。客户必须发现 agents、对其用途分类、识别负责人、减少过度权限，并将相关应用程序连接至执行点。

安全负责人还必须决定哪些操作需要人工批准。即使都使用同一身份平台，摘要 agent 和 quote-to-cash agent 也不应获得相同控制。

后者可能涉及定价、合同、计费系统和营收记录。一个错误可能演变为财务或合规事件，而不只是一次不便的回答。

只有当 Okta 能够引导部署时，这种困惑才能转化为产品机会。蓝图可以帮助客户提出更好的问题，但运营模板和集成必须提供答案。

这一要求给 Okta 的销售和专业服务模式带来压力。买家将期待该公司把抽象的身份框架转化为实际工作流程的控制措施。

开发人员面临相关挑战。他们需要安全的访问模式，而不必为每位客户的身份系统重建每一个 agent。这正是 Okta 的 standards strategy 成为其产品论点核心的原因。

Cross App Access 是 Okta 对开放控制层的押注

Okta 正押注于一个开放授权标准，使 agent 访问具备可移植性，同时让身份提供商仍是核心的策略执行者。

Cross App Access，即 XAA，是 Okta 提出的、通过标准化授权将 agents 与应用程序连接起来的方法。它扩展了 OAuth 概念，并与 MCP 协同工作；MCP 为 agents 发现和调用工具提供了通用方式。

这种区别很重要。MCP 可以描述可用工具并支持交互，但企业仍需决定某个特定 agent 是否可以使用它。XAA 旨在将身份和授权上下文带入该连接。

Kelleher 表示，Okta 将 Cross App Access 作为开放标准而非 Okta 专有格式提出。他还表示，该标准已被接纳为 MCP 的扩展，并正吸引广泛的行业兴趣。

Okta 于 2026 年 8 月正式全面推出 Agent SSO。Agent SSO 允许管理员将 agent 注册为 workload principal，即一种可独立管理的非人类身份。

当受支持的 agent 连接至应用程序时，Okta 可以将其与其他受治理身份一同纳入 Universal Directory。管理员随后可通过既有身份流程查看其归属、连接情况和适用策略。

这一方法试图解决 agent 部署中反复出现的弱点。许多早期 agents 借用用户的访问令牌，或依赖存储在工作流程内部的静态凭据。

借用访问权限会使归因变得不清晰。如果一个 agent 使用员工身份更改记录，审计日志可能无法区分这是软件操作还是人类直接操作。

静态凭据会带来另一个问题。它们的有效时间可能超过必要期限，并可能出现在配置文件、日志或开发环境中。一个暴露的 secret 可能让攻击者获得持续访问权限。

专用 agent identity 将行为主体与其发起人区分开来。业务负责人仍需承担责任，但安全系统可以对 agent 与个人应用不同策略。

这种分离支持最小权限原则，即将身份的访问权限限制在完成指定任务所需的最低范围。它也可以支持更短生命周期的令牌，并在 agent 退役时实现更清晰的停用流程。

Okta 表示，Auth0 for AI Agents 可以帮助开发人员构建能够与 XAA 协同工作的 agents。这些 agents 可以与不同身份提供商存储凭据，而无需采用仅限 Okta 的环境。

开放性强化了 Okta 对担心平台锁定客户的吸引力。企业可以在同一环境中使用来自 Microsoft、Google、Salesforce、自研团队和较小厂商的 agents。

可移植的授权层将让这些代理获得一致的访问决策。它还可减少向采用不同身份系统的企业销售产品时，开发者所需的定制集成工作。

但已发布的标准并不会自动实现互操作性。应用必须实施该标准，代理框架必须携带所需上下文，身份提供商也必须以一致方式解读请求。

安全团队还必须信任每项决策所使用的元数据。代理可以拥有有效身份，同时仍会接收被操纵的指令，或选择不安全的操作。

身份机制回答的是谁或什么在请求访问。它无法独立判定生成的计划是否准确、合乎伦理，或是否符合业务意图。

因此，Okta 的机制意义重大，但能力有限。XAA 可以让授权更加明确且可审计，但无法取代模型防护、数据治理、网络控制或应用层验证。

如果 XAA 成为中立的连接标准，公司将从中受益；若代理平台将身份强制执行保留在自身捆绑的控制平面内，Okta 则将面临更大压力。

Microsoft 不断扩展的代理身份体系已显现出这种压力。

Microsoft 将身份安全变成一场渠道之争

Okta 面临的主要竞争挑战，在于 Microsoft 能够将代理身份与企业已在使用的应用、云服务和管理工具捆绑在一起。

Microsoft Entra Agent ID 于 2026 年 4 月全面上线。它提供专为 AI 代理设计的身份构造、身份验证、授权、治理与安全控制。

其核心论点与 Okta 十分相似：代理应拥有可识别的所有者、受管理的生命周期、受限的访问权限以及可审计的活动记录。Microsoft 也支持 OAuth、MCP 和代理间通信协议。

差异在于渠道能力。Microsoft 控制着庞大的商业应用、开发者服务、云基础设施、数据平台和安全产品组合。

根据 Microsoft 的代理身份文档，Agent 365 充当公司的统一目录与管理层，而 Entra 则提供其底层身份基础。

Microsoft 可以将代理身份与 Conditional Access、Identity Protection、Microsoft Graph 及其更广泛的治理环境连接起来。已经在该技术栈中运营的客户，可能更偏好统一的管理体验。

Microsoft 的 Dataverse 集成展示了一个实际案例。销售开发代理可获得专属身份，以及用于读取潜在客户、记录外联活动和更新符合条件记录的有限角色权限。

管理员可以排除无关的数据表或敏感字段。操作仍可归因于该代理，而非显示在共享员工或应用账户之下。

这一场景展现了 Okta 面临的战略风险。Microsoft 无需将代理身份作为独立类别来销售，因为它可以在工作发生的应用中直接嵌入治理能力。

Okta 的回应是独立性。当企业同时使用多个云、代理构建工具和软件生态系统时，其价值会提升。中立的身份层可以在这些边界之间提供一致的策略。

Kelleher 强调，代理式身份兼具人类身份与非人类身份的特征。Okta 已管理这两类身份，因此在生命周期治理、应用访问和安全信号方面积累了经验。

其集成目录也为公司提供了坚实起点。Okta 在 3 月表示，其网络包含超过 8,200 项集成，其中涉及 Boomi、DataRobot 和 Google Vertex AI 的代理支持。

这种广度只有在集成能够提供有意义的强制执行时才重要。仅注册代理的目录条目，与能够授权单次工具调用并支持快速撤销的条目并不相同。

Microsoft 在其生态系统内也面临同样的考验。集中式身份可以描述权限，但应用必须在快速、多步骤的工作流中正确执行这些权限。

其他安全厂商又增加了一层竞争。特权访问公司可以管理敏感凭据，而端点与云安全提供商可以分析代理周边的行为。

AI 安全专业厂商可能会聚焦提示注入、不安全的工具选择、数据泄露和模型行为。代理获得专属身份后，这些威胁并不会消失。

未来的企业架构很可能包含多层控制。争夺的核心问题是：哪个平台将成为所有权、策略和调查的中心位置。

Okta 希望身份安全架构承担这一角色。Microsoft 则希望 Agent 365 和 Entra 提供统一控制平面，尤其是在 Microsoft 应用之间。

客户将通过混合环境来评判这些主张。一个只能治理其原生代理的平台，会让安全团队面对碎片化的资产清单和策略。

Okta 的独立性为碎片化提供了可信的答案。Microsoft 的集成深度则为运营复杂性提供了可信的答案。

这是本文最核心的竞争：中立身份层对阵捆绑式应用与云控制平面。混乱有助于 Okta 开启对话，但互操作性将决定谁能主导这场对话。

身份控制无法判断代理的意图

Okta 可以限制代理获准访问的内容，但有效凭据并不能保证推理安全或操作正确。

代理可能成功完成身份验证，也始终处于获批的权限范围内，却依然造成伤害。它可能误解请求、遵循恶意指令，或将获准操作组合成非预期的结果。

提示注入说明了这一缺口。攻击者可以在代理读取的内容中嵌入隐藏或误导性指令。代理可能将这些指令视为任务的一部分。

身份控制可以限制由此产生的影响范围，但并不总能识别出代理的决策过程已遭操纵。

同样的局限也适用于错误规划。获授权的财务代理可能选错账户、重复执行操作，或将审批规则应用于错误交易。

在检测到可疑行为后，终止开关就会很有价值。然而，在人工识别出模式并撤销访问权限之前，自主代理可能已经执行了许多操作。

运行时授权试图缩小这一窗口。系统不会授予广泛的长期访问权限，而是根据身份、上下文、风险和预期操作评估每一项请求。

这种评估的质量取决于可靠的上下文。策略必须区分正常变化与不安全行为，同时不能阻碍合法工作流。

组织还需要可信的日志。记录代理的工具调用有助于调查人员重建事件，但日志必须关联代理、人工责任人、指令、授权决策和最终变更。

仅显示一次成功 API 调用的记录，能提供的问责能力有限。安全团队需要了解代理为何调用该 API，以及哪些数据影响了其决策。

Okta 的系统日志与治理功能覆盖了这条链路的部分环节。该公司表示，工具调用、访问尝试和授权决策可以流入安全信息与事件管理系统。

在客户跨多种代理框架和应用进行测试前，这些能力仍只是公司的主张。Okta 自己的公告也警告称，尚未发布的功能可能延迟推出，或根本不会推出。

由于企业代理部署仍处于早期阶段，独立证据依然有限。学术界已开始研究代理系统的身份管理，但生产环境基准仍在发展中。

另一个担忧是所有权质量。指定一名人工责任人会在纸面上建立问责机制，但此人必须了解代理的数据、权限、依赖关系和退役条件。

当组织部署代理的速度快于管理者审查它们的速度时，所有权可能流于形式。访问认证随后可能沦为另一个缺乏充分上下文的审批队列。

代理蔓延会使问题进一步恶化。主代理可能会为研究、分析或执行创建临时子代理。安全策略必须决定这些临时身份是否继承权限。

广泛继承易于管理，却会增加暴露面。要求每个短生命周期代理分别审批，可能会削弱代理式工作流吸引人的速度优势。

这是 Okta AI 代理安全中的核心权衡。企业希望代理能够跨系统快速运行，而安全团队则需要确保每项操作都保持受限、可归因且可撤销。

控制过少会带来不可接受的风险。摩擦过多则会让自主工作流重新变成一连串缓慢的人工审批。

最强的部署将从狭窄的任务和明确的数据边界开始。例如，支持代理可以先对工单分类，之后才获得发放信用额度或更改客户记录的权限。

团队应测试失败路径，而不只是成功演示。他们需要证据来说明系统如何处理所有权过期、输入遭操纵、权限过度以及强制执行服务不可用等情况。

可搜索的知识库可以帮助团队记录所有者、策略和事件决策。它无法取代访问控制，但能保留审核人员所需的上下文。

当客户能够将身份决策与权限缩减及更快的事件遏制关联起来时，Okta 的策略才更具说服力。仅靠产品公告无法证明这一结果。

三个信号将显示 Okta 的推进是否奏效

标准采用、客户扩展和跨平台强制执行，将决定 Okta 能否将混乱转化为持久的身份安全类别。

第一个信号是 Cross App Access 在 Okta 自有产品之外的采用情况。代理开发者、应用厂商和竞争性身份提供商都必须实施该协议，它才能成为有意义的基础设施。

Okta 在 9 月的大会上表示，更广泛的公告即将到来。重要的细节不在于具名合作伙伴的数量。买方应审视这些集成实际能够授权哪些操作。

支持注册能提供资产清单。支持范围受限且具备上下文感知能力的授权能提供控制。支持快速撤销，则能在代理偏离预期角色时提供遏制能力。

不断增加的一组可用集成将强化 Okta 的中立平台论点。有限的采用则会让 XAA 成为 Okta 环境中的实用功能，而非行业控制层。

第二个信号是客户续约和扩展的形态。Kelleher 表示，大多数早期代理式交易采用一年期合同，让客户和 Okta 有时间了解使用情况。

这些续约将揭示企业是否已超越评估阶段。买方应关注那些在多个业务流程中治理生产级代理的部署，而非孤立的演示。

向更多代理平台扩展，将支持身份能够提供通用控制平面的主张。若增长仅与实验性项目相关，则表明混乱仍是销售障碍。

定价将提供另一个线索。Okta 按用户收费的加价模式简化了初始采购，但代理的数量和活动量未必与员工人数同步。

该模型可能会演进至受保护的智能体、连接、交易或授权事件。任何变化都将揭示客户重视什么，以及哪些运营成本最关键。

一个稳定、易于理解的模式将有助于这一类别走向成熟。复杂的按使用量计费可能会重新带来 Okta 的蓝图旨在消除的不确定性。

第三个信号是 Microsoft 和其他身份提供商的竞争回应。Microsoft 的 Agent 365 model 已将统一清单与由 Entra 支持的身份和治理结合起来。

如果 Microsoft 为第三方智能体扩展简化治理能力，Okta 的独立性主张将面临直接考验。如果 Microsoft 仍主要在自身环境内保持最强优势，Okta 就将在异构企业中获得更多空间。

客户应比较 Microsoft 365、Google Workspace、Salesforce、云平台和自定义应用中的执行能力。胜出者需要的不仅仅是一份集中的智能体清单。

它必须跨应用边界保持智能体身份，落实最小权限原则，明确展示所有权，并一致地终止访问。它还必须提供安全团队能够在调查和审计期间使用的证据。

竞争对手若支持通用标准，将验证 Okta 更广泛的论点，即使这会削弱产品差异化。专有方案则会让智能体身份成为又一道平台边界。

Okta 在会议上传递的信息值得关注，因为它并未将 AI 智能体安全视为单一的检测功能。该公司正围绕智能体整个生命周期中的问责与访问控制来界定这一问题。

这一框架契合实际运营挑战。企业需要知道是谁创建了智能体、它为何存在、它能够访问哪些资源，以及应如何将其停止。

不过，身份只是多个控制平面之一。模型防护、应用验证、网络监控、数据治理和人工审核仍然必不可少。

因此，安全采购团队应将 Okta 的蓝图视为一个测试框架。他们可以要求每家供应商在真实工作流中演示发现、授权、所有权、日志记录和撤销能力。

最有力的证明将来自一个有意设置约束的生产部署。团队可以从一个只读取有限信息、并为人工批准提出行动建议的智能体开始。

随后，他们可以衡量过度权限请求、策略拒绝、调查耗时和停用准确率。这些结果比经过精心打磨的自主演示更能说明问题。

Okta 的 AI 智能体安全归根结底是在押注：企业不会再通过分散的凭据和孤立的控制措施来管理自主软件。市场正走向专用身份、明确所有权和持续授权。

尚未解决的问题是谁将为混合环境提供这一层能力。首先关注 XAA 集成，其次关注生产续约，第三关注 Microsoft 对第三方的覆盖范围。

如果 Okta 在这三个方面都取得进展，混乱将转化为持久的身份管理机会。如果采用情况仍然碎片化，捆绑式平台将继续保有优势。

对于企业团队而言，下一步很实际：选择一个智能体，梳理每一项连接，并记录每一项获准操作。然后问问自己，现有身份系统能否无需定制工作就看到、限制、审计和撤销该智能体。