OX Security CNAPP 平台将云态势与 AI Agent 运行时防御整合起来

OX Security 于 9 月 16 日推出 CNAPP 平台，将成熟的云控制能力与针对 AI Agent 的实时监控相结合。这一名为 OX Cloud 的 OX Security CNAPP 平台，旨在弥补自主软件获得身份、权限及企业工具访问能力后所形成的安全缺口。

此次发布并不只是对云安全功能列表的又一次扩展。OX 主张，安全团队需要一张统一图谱，连接代码、云配置、身份、数据、提示词以及实时 Agent 操作。这一主张同时挑战了传统 CNAPP 产品和独立的 AI 安全工具。

Palo Alto Networks 及其他大型安全厂商已提供运行时保护、AI 态势管理和 Agent 控制能力。因此，OX 必须证明其从提示词到运行时的上下文能够带来更优决策，而非仅仅提供一个更全面的仪表盘。

核心问题在于，整合这些信号能否帮助防御者识别可达风险和不安全的 Agent 行为。如果可以，OX Cloud 便可能缩小发现云端弱点与理解自主系统可能如何利用该弱点之间的差距。

OX Security CNAPP 平台将可见性延伸至实时 Agent 活动

OX Cloud 在云安全平台已收集的基础设施、身份、漏洞和数据信号之上，加入了 Agent 行为。

云原生应用保护平台，即 CNAPP，会在一个系统内整合多项云安全功能。这些功能通常包括配置监控、工作负载保护、权限分析、漏洞管理和攻击路径映射。

OX Cloud 包括云安全态势管理、Kubernetes 态势管理、数据安全态势管理、运行时漏洞检测、云资产清单以及基于图谱的攻击路径分析。该公司还在增加 AI Detection and Response，并将其简称为 AIDR。

差异在于 OX 希望平台观察的对象。传统态势工具会检查存储桶、容器、身份、网络路径和访问策略等资源。OX Cloud 还寻求识别在该环境中运行的 Agent、模型、提示词和 Model Context Protocol 服务器。

MCP 是一种标准接口，可让 AI 系统连接外部工具和数据。MCP 服务器可能向 Agent 暴露数据库、文件系统、工单服务、代码仓库或内部 API。

这种连接为 Agent 带来更多实用性，但也会将模型输出转化为操作。遭操纵的 Agent 可能检索受限记录、调用未经批准的工具，或在既定工作流之外使用有效凭证。

OX 表示，其平台会将这些操作与周边的云上下文关联起来。根据该公司的 OX Cloud 公告，该产品能够盘点工作负载、身份、数据存储、Kubernetes 集群和活跃的 AI Agent。

平台随后通过可达性分析来确定发现项的优先级。可达性决定了暴露组件、易受攻击的软件包或过度权限能否实际连接至高价值资源或执行路径。

这种方法很重要，因为云扫描器可能生成大量在技术上有效的发现项。隔离工作负载中的易受攻击软件包，与面向互联网且可访问客户记录的服务中的同一软件包，所带来的即时风险并不相同。

OX 将这一逻辑应用于 Agent。当相关 Agent 可以访问生产数据、管理 API 或部署系统时，可疑提示词或异常工具调用就变得更加重要。

该公司还表示，OX Cloud 能将运行时活动与触发活动的提示词或代码关联起来。这种关联可能帮助调查人员还原 Agent 为何采取某项操作，而不只是记录该操作已经发生。

这些仍属于厂商说法。OX 已介绍相关能力和产品架构，但尚未公布此次发布对应的检测率对比、误报测量、部署开销或独立评估结果。

这一证据缺口并不意味着该产品无关紧要。它界定了企业买家在将新平台视为统一控制平面之前必须验证的事项。

为何 AI Agent 给传统云安全带来压力

Agent 将多项熟悉的安全问题压缩进一个高速运行的身份主体中：它可以推理、选择工具并发起变更。

传统工作负载通常遵循工程师可在部署前审查的代码。其权限仍可能过多，依赖项也仍可能存在漏洞。但预期执行路径相对稳定。

Agent 的行为不同。它会在运行时解读指令、检索上下文、选择工具，并构建一系列操作。提示词、检索文档、模型版本或工具描述的微小变化，都可能改变该序列。

这种可变性并不意味着 Agent 行为无法了解，而是意味着防御者需要同时掌握决策路径和最终系统调用的遥测数据。

身份是这一问题的核心部分。通过共享服务账户执行操作的 Agent，会使日志难以解读。调查人员可能看到数据库查询或文件变更，却不知道是哪一个 Agent 发起、为何采取行动，或是谁授权了该工作流。

Microsoft 的最小权限指南建议将每个 Agent 视为独立主体。每个 Agent 都应具备托管身份、明确的所有者、范围严格限定的角色，以及获批准的工具清单。

这一模型建立了可衡量的边界。团队可以确定 Agent 应调用哪些工具、能够访问哪些资源，以及其运行时活动是否仍在指定用途范围内。

当 MCP 服务器继承广泛凭证时，问题会更加严重。MCP 支持包括 OAuth 在内的授权机制，但该协议不会自动为每种部署强制执行安全策略。

Microsoft 报告称，通过 Defender for Cloud 信号观察到的远程 MCP 服务器中，有 15% 允许未经身份验证访问敏感数据或运营能力。其 MCP 暴露发现包括与工单系统、私有仓库和人力资源工具的连接。

这一比例并不描述所有 MCP 部署。但它表明，当身份验证和执行边界配置错误时，Agent 连接能力可能暴露真实的企业系统。

态势扫描可能识别出暴露的服务器。身份产品可能发现其凭证。运行时工具可能记录可疑调用。OX 押注于共享图谱可以在分析师手动拼接链条之前连接这三者。

这是将 CNAPP 数据与 AI Agent 运行时防御结合的最有力论点。该威胁既不完全属于应用问题，也不完全属于云问题。

设想一个负责处理支持请求的 Agent。它可以读取工单、搜索内部文档，并更新客户记录。隐藏在工单中的间接提示词可能指示该 Agent 检索无关记录，或将数据发送至外部端点。

提示词过滤器可能会标记该指令。然而，严重程度取决于 Agent 使用何种身份、可调用哪些工具，以及这些工具可访问哪些记录。

反过来，异常 API 调用也并不总是意味着攻击。Agent 可能是在遇到罕见请求后完成一项正当任务。防御者需要足够的上下文，才能区分意外行为与未经授权的行为。

OX Cloud 正是围绕这一差异设计的。其承诺并不只是检测异常提示词，而是将实时行为与可达资产、有效权限及源软件路径关联起来。

OX Cloud 将可达性作为核心差异化能力

该平台的核心机制是证据关联的优先级排序，由运行时行为和攻击路径决定哪些发现项值得关注。

云安全团队已经在应对告警量问题。态势扫描器检测错误配置，漏洞工具枚举软件包，身份系统识别过度权限，数据工具分类敏感存储。

加入 Agent 可能产生另一份资产清单，却无法解决这种碎片化。安全团队或许会得知某个 Agent 存在、使用特定模型并连接多个工具。但这些事实仍不能说明其行为是否形成可被利用的路径。

OX 描述了四阶段工作流：识别、优先排序、调查和治理。这些阶段使用相同的上下文数据，而不是作为彼此割裂的产品模块运行。

识别涵盖工作负载、身份、Agent、数据存储和云资产。OX 表示，这也包括从观察到的活动中发现的资源，而不仅是配置文件中声明的资源。

优先排序会将可达性应用于漏洞、权限、错误配置和供应链暴露。无法连接至活跃工作负载或高价值资产的发现项，其紧迫性会更低。

调查利用云图谱重建事件周边的关系。分析师应能看到哪个身份采取了行动、触及了什么资源，以及还可访问哪些其他系统。

治理则对 Agent 活动和 AI 使用施加限制。正是在这一环节，OX 的 AIDR 和 Agent 攻击面功能才不止是发现功能。

这一机制听起来连贯，但其质量取决于数据保真度。OX 必须可靠地发现资产、解读权限、追踪 Agent 调用，并保留足够的调查上下文。

覆盖缺口可能造成虚假的安全感。未被观测到的工具调用、未受管理的凭证、加密流量路径或不受支持的 Agent 框架，都可能切断连接提示词与结果的链条。

数据关联也可能产生模糊结论。提示词出现在 API 调用前不久，并不能自动证明它导致了该调用。长时间运行的工作流、并行 Agent、重试和委派子任务都会增加归因难度。

因此，OX 必须在其界面中区分相关性与因果关系。分析师需要时间戳、调用链、身份记录、策略决策和应用追踪，以支持所提出的关联关系。

部署架构同样重要。运行时检查可以通过网络拦截、工作负载传感器、应用库、API 网关、云日志或与 Agent 框架的集成来实现。

每种方法提供不同的可见性。网络控制可能观察到目标和载荷，但会错过内部推理过程。框架插桩可能捕获工具选择，但无法完整覆盖自定义应用。

OX 表示，更广泛的 AINAPP 平台连接了提示词、代码、构建、部署和运行时阶段。AINAPP 是该公司对 AI 原生应用保护平台的称谓。

这一理念为 OX 带来了潜在的有利定位。其应用安全产品已经能够审查源代码和软件供应链。OX Cloud 则将这一能力延伸至已部署的基础设施和实时运行的智能体活动。

不过，买家应关注：对于并非通过 OX 产品管理的代码和智能体，这种连接如何运作。如果最丰富的上下文仅出现在受严格控制的工具链中，统一平台的价值就会受到限制。

实际检验应当基于真实事件。安全团队应注入一段可疑的工具描述，触发一次未经授权的访问尝试，并检查 OX 是否能够还原完整路径。

这一演练应展示发起内容、智能体身份、所选工具、参数、目标地址、实际权限、受影响数据以及执行结果。任何缺失都会让分析人员不得不在不同系统之间拼凑证据。

OX Security 面临成熟的 CNAPP 与 AI 安全平台竞争

OX 竞争的对象，是由更大型厂商主导的平台整合趋势，而非那些完全忽视 AI 的静态云扫描工具。

市场已转向覆盖全生命周期。主要厂商如今将 AI 发现、态势分析、红队测试、运行时检查、身份控制和策略执行整合在一起。

Palo Alto Networks 将 Prisma AIRS 定位为覆盖 AI 应用、模型、数据和智能体的平台。其 Prisma AIRS documentation 描述了运行时防火墙、API、红队测试、模型安全、态势管理和智能体保护功能。

Palo Alto 还将 AI 发现与 Cortex Cloud 集成。这种连接可识别 Amazon Web Services、Microsoft Azure 和 Google Cloud 中的模型、端点、数据集、智能体及其依赖关系。

这使得核心竞争不再只是 OX 与传统 CNAPP 之间的对比，而是 OX 以上下文为先的集成能力，对阵在既有产品组合中组装类似控制能力的成熟安全平台。

成熟厂商拥有既有客户基础、云遥测数据、威胁情报、身份集成能力和稳固的采购关系。买家可能更愿意扩展现有合同，而非引入另一套安全平台。

OX 可以凭借专注度加以应对。较小的厂商能够围绕智能体工作流进行设计，无需保留旧产品套件中的每一项架构假设。

其从代码到运行时的叙事也可能吸引应用安全团队。这些团队希望了解：开发阶段引入的发现，在部署后是否仍可被触达，以及智能体是否能够激活存在漏洞的路径。

这种连接有望减少开发人员与安全分析师之间的争议。开发人员经常收到扫描器发现，却没有证据表明受影响代码实际暴露在外。运行时上下文可以明确哪些问题具有即时的运营相关性。

然而，大型厂商也在提出同样的平台整合论点。Palo Alto 报告称，Prisma AIRS 在全面上市一年后实现了约 1.2 亿美元的年度经常性收入。

该公司还在其 2026 财年第四季度演示中表示，Prisma AIRS 客户已超过 800 家。这些数字采用 Palo Alto 自身的收入分配和已签订报价定义，但表明市场存在显著的商业需求。

这种竞争压力迫使 OX 展示具体优势。更长的功能清单并不足够，因为云平台已经覆盖了许多相同类别。

OX 可以通过更快的调查、更清晰的优先级排序、更广泛的框架支持，或更明确的从提示到运行时归因实现差异化。它还可以通过部署灵活性和更低的运营复杂度展开竞争。

客户应比较工作流，而非类别标签。两种产品都可能宣称具备智能体发现、运行时防御和态势管理能力，但它们收集的遥测数据不同，或在不同环节执行策略。

一个平台可能会在模型处理前阻止恶意提示。另一个平台则可能拦截工具调用、限制身份权限，或在检测到可疑活动后隔离工作负载。

这些控制措施彼此互补，但其部署位置会影响延迟、覆盖范围和故障模式。位于执行路径之外的产品可能能够更安全地进行观察，却缺乏即时阻断权限。

内联控制能够阻止操作，但也因此成为应用可用性路径的一部分。买家必须了解：当安全服务变慢、失去连接或无法对请求进行分类时，会发生什么。

OX 尚未公开足够与此次发布相关的证据，以便对这些比较作出定论。其当前挑战是将可信的架构转化为可重复的客户成果。

运行时防御无法替代智能体设计与访问控制

任何 CNAPP 都无法弥补以下问题：智能体共用身份、获得过高权限，或在缺乏独立授权的情况下执行高影响操作。

运行时监控常因能够发现静态审查遗漏的行为而受到关注。这一优势也可能促使团队将观察能力视为更安全架构的替代品。

智能体不应仅因某个监控产品能够记录其行为，就获得广泛访问权限。记录一次未经授权的数据传输，并不能撤销这次传输。

OWASP 的 agentic risk taxonomy 包括工具滥用、身份与权限滥用、记忆投毒、级联故障和失控智能体行为。这些风险跨越模型、应用、身份和基础设施边界。

防御者应从区分智能体身份开始。共享凭据会模糊归属，也会使撤销权限变得困难。每个生产环境智能体都需要明确的负责人、记录在案的用途，以及有限的允许访问资源集合。

工具访问也应明确规定。用于汇总支持工单的智能体，不应继承工单平台的管理权限。它应仅获得完成该任务所需的读取操作权限。

写入权限应作为独立决策处理。如果工作流扩展为修改记录，团队应创建新的权限和审批规则，而非未经审查便扩大既有角色的权限范围。

高影响操作需要确定性的执行机制。删除数据、修改生产基础设施、发起付款或发布外部内容，不应仅依赖模型对自然语言指令的理解。

对于具有重大财务、运营或法律后果的操作，人工审批仍然适用。对于影响较低的任务，当策略条件足够严格且能够独立执行时，自动审批可以发挥作用。

记忆带来了另一种风险。智能体可能跨会话存储对话历史、偏好、检索到的事实或中间计划。恶意内容可能在这类记忆中持续存在，并影响后续决策。

运行时产品应尽可能暴露记忆读取和写入行为。它还应显示智能体在选择工具或构造参数时，是否使用了检索到的内容。

不过，记忆访问可能发生在仅提供有限遥测数据的框架或模型服务内部。买家应测试 OX Cloud 是否能够在其实际部署技术栈中捕获这些交互。

误报是另一项挑战。智能体工作流会自然产生不同寻常的操作序列，因为它们会适应用户请求。简单的异常检测可能将合理变化标记为风险，并使分析人员不堪重负。

OX 表示，可达性有助于降低这类噪声。这一说法具有合理性，但可达性并不能证明恶意意图。可达路径可能支持合法工作流，而不可达的软件缺陷也可能在配置变更后变得相关。

企业应在受控部署期间衡量准确率。有用的指标包括确认事件、误报、调查时间、被阻断的合法任务、不支持的工作流和遥测缺口。

它们还应衡量性能影响。当运行时检查同步评估提示、工具调用、数据流或身份策略时，可能增加延迟。

OX 尚未公布 OX Cloud 的通用延迟或开销数据。结果很可能取决于部署方式、流量规模、策略复杂度以及收集上下文的数量。

另一个不确定性是执行一致性。一个组织可能在多个云环境和 SaaS 平台中运行由多种框架构建的智能体。策略必须能够适应这些架构差异。

一个能够发现所有智能体、却只治理其中一部分的仪表板，会造成保护不均衡。安全团队需要清晰的兼容性矩阵，以及不受支持路径仍然可见的证据。

恰当的结论并非运行时防御没有价值，而是运行时监控在更大控制体系中的一层时，效果最佳。

安全的智能体设计始于有限权限。运行时防御随后验证其行为是否仍处于这些限制之内，并帮助调查人员理解偏离情况。

三个信号将显示 OX Cloud 是否兑现承诺

下一项检验是运营证据，包括客户验证、可衡量的降噪效果，以及在真实智能体技术栈中的广泛执行能力。

第一个信号是独立客户证据。OX 应展示该平台在包含多云、智能体框架、身份提供商和 MCP 服务器的生产环境中的表现。

有价值的案例研究应量化发现了多少智能体和非人类身份。它们还应报告确认了哪些高风险路径、抑制了多少警报，以及调查时间发生了怎样的变化。

第二个信号是对比性能。买家需要覆盖提示注入、被投毒的工具描述、过高权限、异常 API 序列和尝试数据外泄的检测与执行测试。

这些测试应包括良性变化，以衡量误报率。一个会阻止所有不常见操作的系统，对于适应性工作流几乎没有价值。

OX 还应披露执行发生的位置。客户需要了解控制措施是在工作负载内部、通过网络检查、在智能体框架中，还是通过云 API 运行。

第三个信号是竞争响应。Palo Alto Networks、Microsoft 及其他安全厂商正将智能体身份、态势、运行时检查和治理能力整合到更大的平台中。

如果这些厂商以类似精度连接代码、提示、身份、云资源和工具调用，OX 的架构差异将会缩小。届时，OX 将在部署质量、调查速度、覆盖范围和客户服务方面展开竞争。

如果成熟厂商仍将这些控制能力分散开来，OX 则可以主张，单一上下文图谱能够带来更快且更具可辩护性的决策。客户评估将决定哪一种结果更符合生产现实。

评估 OX Security CNAPP 平台的安全负责人，应从一个受限的智能体工作流开始。在启用更广泛覆盖前，他们可以先梳理其身份、获批工具、可触达数据、预期操作和升级规则。

随后，评估应引入受控故障。测试一个暴露的 MCP 服务器、一个权限过高的身份、一份被投毒的文档、一次未经授权的工具调用，以及一个存在漏洞且可被触达的工作负载。

平台不仅应显示发生了异常事件，还应说明它为何重要。它应将源指令与执行身份、所选工具、可触达资产、策略决策和最终结果关联起来。

这一标准不只适用于 OX。智能体安全产品必须将复杂的遥测数据转化为可靠的执行能力和可解释的调查结果。

此次发布反映了云安全领域的一个真实转变：智能体正成为积极参与云环境的主体，而不再只是需要盘点的另一类资产。

OX Cloud 的应对方式，是将运行时行为纳入与代码、工作负载、身份和数据相同的图谱之中。这一设计具有可信度，但其中最强的主张仍需独立验证。

考虑采用 OX Cloud 的团队应要求进行贴近生产环境的试用，而不是观看经过精心打磨的功能演示。该平台能否识别每一个智能体，区分合理的行为差异与滥用，并重建完整的操作链路？它能否在不延误正常工作的情况下实施限制，且不制造另一个告警队列？这些结果将决定 OX Security CNAPP 平台会成为有意义的控制平面，还是又一个需要安全团队协调整合的层级。