Cohesity Agent Resilience 瞄准 AI Agent 带来的恢复缺口

Cohesity 于 9 月 16 日推出 Cohesity Agent Resilience，将恢复保护扩展至 AI Agent 及其能够改变的系统。这项新能力带来了一个更具挑战性的承诺：在不取消人工审批的前提下，实现更多网络响应流程的自动化。

这一差异至关重要，因为企业 Agent 正从被动助手转变为主动操作者。它们保留记忆、调用应用、更新数据库并执行工作流。检测机制可以发现有害操作，但仅靠检测无法恢复 Agent，也无法撤销其对所有受影响资源造成的改动。

Cohesity 将 Agent、其状态以及关联基础设施视为一个可恢复的整体系统。Commvault、Druva 和 Rubrik 也在探索相关路径，使 AI Agent 恢复成为数据保护市场的新竞争焦点。

Cohesity Agent Resilience 保护的不只是 Agent

Cohesity Agent Resilience 将 AI Agent 的记忆和配置视为可恢复的运行状态。

Cohesity 在其于 9 月 16 日和 17 日跨多个地区举行的 Catalyst 2026 虚拟活动期间宣布了这一能力。该公司此前曾表示，Catalyst 将推出面向多 Agent 环境和自主恢复工作流的新控制机制。

Agent 的状态包括影响其行为的已存储上下文和配置。如果恶意指令、配置漂移或损坏的记忆改变了这些状态，恢复数据库未必能恢复 Agent 的判断能力。

Cohesity 表示，这项新能力可为该状态提供时间点恢复选项。管理员可将受影响的 Agent 恢复至已知可信的版本，而不必重建 Agent 并丢失其积累的上下文。

保护范围还延伸至 Agent 周围的基础设施。根据该公司的 Agent 恢复概览，其范围可包括 Agent 使用或管理的应用、数据库、文件系统、内存存储及其他服务。

这一更广泛的范围回应了 Agent 软件的一个基本问题：即使 Agent 的记忆已被损坏，它仍可能继续运行；即使 Agent 已恢复，也可能在关联系统中留下有害改动。

因此，Cohesity 将恢复工作分为两项。一项用于恢复 Agent 的可信状态，另一项用于识别并恢复受其操作影响的资源。

该公司为这两项工作采用了成熟的数据保护机制，包括快照、不可变备份和隔离恢复环境，后者通常称为 clean room。

clean room 是一种隔离环境，用于在不立即重新连接生产环境的情况下检查和恢复系统。它为响应团队提供空间，以确认恢复后的组件是否仍然受到损害。

该公司还描述了一种 Agent 拓扑结构，用于将每个 Agent 映射至其记忆、应用、数据库和支持性基础设施。这张关系图旨在发现保护缺口，并识别实现可信恢复所需的全部要素。

Cohesity Agent Resilience 初期支持 Amazon Bedrock AgentCore 和 Bedrock Agents。部分客户现已可使用，计划于 2026 年底全面推出。Microsoft Azure 和 Google 平台仍在路线图中。

这些限制意味着，这是一项重点明确的首发版本，而非通用的 Agent 恢复层。Cohesity 必须证明其模式能够覆盖不同云环境、Agent 框架、记忆系统和权限结构。

但这一发布仍改变了恢复边界。备份平台传统上保护数据和应用，而 Cohesity 现在认为，Agent 的运行记忆也应纳入这一边界，因为它能够直接影响生产活动。

相关发布细节和路线图也记录在原始的 Agent 韧性报道 中。其核心理念很直接：企业不仅需要恢复被触及的资产，也需要恢复执行操作的主体。

AI Agent 正在给传统恢复计划施加压力

AI Agent 扩大了事件影响面，因为一次遭到破坏的决策可能会传播至多个关联系统。

传统恢复规划通常假定，团队能够识别受损工作负载、恢复干净副本，并验证由此形成的环境。AI Agent 让这一流程变得复杂，因为它们持有上下文，并跨越应用边界采取行动。

以一个可访问工单、客户记录和知识库的内部支持 Agent 为例。一条被篡改的指令可能使其泄露信息、变更分类，或将错误内容写入多个系统。

恢复工单数据库或许可以找回被删除的记录，但无法从 Agent 的记忆中删除受损指令，也无法显示哪些下游操作需要撤销。

软件运维中也存在同样的问题。能够修改配置、创建部署请求或管理云资源的 Agent，可能会产生一连串身份验证合法、却具有破坏性的变更。

这些操作未必像传统入侵。Agent 可能使用合法凭证和获批接口，但其行为依据的是被污染的上下文或有缺陷的配置。

这也是 Cohesity 将 AI Agent 恢复界定为韧性问题，而不仅是监控问题的原因。监控记录行为；恢复则建立可信时间点，并修复该时间点之后受损的系统。

Cohesity 首席产品官 Vasu Murthy 直接概括了这一缺口：检测能够显示 Agent 已偏离轨道，但无法撤销其造成的改动。这一说法解释了为何该公司同时保护状态和依赖项。

压力首先落在安全和基础设施团队身上。他们必须决定哪些 Agent 记忆至关重要、应以多高频率进行捕获，以及如何协调关联资源的恢复。

AI 工程团队也面临相关负担。他们需要提供足够的信息，使保护系统能够识别 Agent 版本、配置、记忆存储、权限和外部依赖项。

应用所有者也进入了恢复链条。若数据库、身份控制或业务应用仍处于不一致状态，单纯恢复干净的 Agent 价值有限。

组织层面的问题可能比存储问题更棘手。不同团队可能分别负责 Agent、模型访问、底层数据和各个关联应用。

Cohesity 的拓扑概念试图在事件发生前使这些关系可见。最新的依赖关系图可帮助响应人员判断哪些系统需要调查，以及采用何种恢复顺序才能维持一致性。

这种映射也支持恢复时间目标和恢复点目标。RTO 定义服务应在多快时间内恢复，RPO 则定义组织可以承受丢失多少近期状态。

对于 Agent 而言，这些指标变得不那么明确。恢复昨天的记忆可能会抹去有用的上下文，而恢复今天的记忆则可能保留引发事件的损坏状态。

因此，团队需要制定能够区分持久知识和临时状态的政策。他们还必须决定哪些 Agent 操作可以自动撤销，哪些需要业务审查。

Cohesity 的主张会给其他备份供应商带来压力，因为客户将期待恢复计划遵循这一更广泛的系统边界。一旦自主软件能够同时修改文件和工作负载，仅保护其中之一就显得不够完整。

这一问题同样影响尚未采用高度自主 Agent 的企业。即使能力有限的 Agent，也可以撰写摘要、分类记录、调用工具，或触发影响后续决策的工作流。

因此，Agent 韧性并非完全自主系统的专属需求。关键门槛在于，该软件是否能够保留状态，或在不由人工逐一审查每项操作的情况下作出具有实质影响的变更。

新一轮竞争：Cohesity AI Agent 恢复对阵碎片化控制

市场竞争并不只是 Cohesity 与另一家供应商之间的较量；而是统一的 AI Agent 恢复与彼此割裂的监控、备份和应用控制之间的竞争。

企业已有工具可以应对 Agent 风险的部分环节。可观测性系统捕获追踪信息，身份平台管理访问权限，应用日志记录变更，备份产品则保存数据。

恢复问题恰恰出现在这些层之间。事件团队可能识别出可疑的 Agent 会话，却仍缺乏一种协调机制来恢复其记忆及所有受影响的依赖项。

Cohesity 希望让其数据平台成为这一协调层。该平台可以利用现有的快照和不可变副本，同时补充对 Agent 拓扑和状态的理解。

这一方法为成熟的备份供应商提供了天然切入点。该公司已为许多客户管理恢复副本和隔离环境。

然而，既有基础设施并不会自动解决 Agent 语义问题。平台必须了解哪些记忆项目、配置文件、提示词、工具、凭证和应用变更属于某个特定恢复点。

竞争对手正从不同方向着手解决同一问题。Rubrik 的 AgentCloud 强调 Agent 运营、治理、可观测性，以及用于撤回非预期操作的回退能力。

Rubrik 还正通过 Model Context Protocol（MCP）向客户 Agent 开放其网络韧性数据。MCP 是一项标准接口，AI 系统可通过它在既定控制条件下访问外部工具和数据。

这一策略使 Agent 能够基于恢复信息进行推理，并发起受治理的工作流。近期的 MCP 集成细节 显示，恢复平台正迅速成为更广泛 AI 系统中可被调用的组件。

Commvault 已宣布 AI Protect，旨在发现 Agent，并盘点其在关联环境中的依赖项。其计划记录的内容包括模型、配置、数据源、应用和基础设施。

Druva 则描述了对 Agent 的保护、通过 Agent 访问备份信息，以及针对疑似 AI 攻击的自动化响应。这将 Agent 恢复与 Agent 辅助调查结合在一起。

这些方法有所重叠，但各自强调不同的控制点。Cohesity 聚焦可恢复状态和关联资源；Commvault 强调持续发现；Druva 将保护与安全调查相结合，而 Rubrik 则将治理与可逆操作联系起来。

客户应审查各平台对 Agent 依赖关系的理解深度。仅捕获配置却不映射下游资源的产品，只解决了一半问题。

他们还应审查框架覆盖范围。Cohesity 对 AWS Bedrock 的初步支持提供了明确的集成边界，但许多企业使用自定义框架和混合云服务构建 Agent。

恢复平台必须能够处理这些环境，而不能强迫所有 Agent 都采用某一供应商的编排模式。开放接口可能有所帮助，但也会扩大管理员需要管理的权限和安全决策范围。

竞争压力很可能会倾向于那些能够连接三项能力的供应商：发现代理关系、保留可信版本，以及跨依赖系统协调一致的恢复流程。

目前还没有供应商证明这套方法能够普遍适用于企业级代理技术栈。产品公告表明了方向，而生产环境中的证据将决定统一恢复是否优于碎片化控制措施。

Cohesity 的优势在于其现有的恢复基础。其挑战在于证明这一基础能够以足够精确的方式表征不断变化的代理状态，从而支持安全恢复。

自主网络韧性仍依赖人类判断

Cohesity 的自动化计划能够减少重复性工作，但无法消除对“安全恢复应保留什么”作出决策的需求。

除 Cohesity Agent Resilience 外，该公司还提出了名为 Autonomous Cyber Resilience 的更广泛愿景。它利用代理式工作流，将五步韧性框架中的部分环节自动化。

这些步骤涵盖保护、可恢复性、威胁处置、恢复演练，以及持续改进数据与 AI 风险态势。该拟议系统将持续发现资产、评估保护状况、验证恢复就绪度并更新计划。

Cohesity 描述了一种工作流：管理员通过 Cohesity Copilot 设定业务目标，平台随后评估相关工作负载，并建议保护策略、威胁扫描和恢复演练。

在执行前，人类将审批这些建议。事件发生期间，管理员可以启动自动化工作流，以评估影响、寻找攻击者活动迹象，并准备隔离的恢复环境。

这一模式比完全自主的处置更为谨慎。它让软件负责发现、分析、准备和编排，同时将审批权保留给人工操作人员。

这一边界至关重要，因为恢复决策涉及相互冲突的目标。最新可用的恢复点可能保留了受损状态；较早的恢复点或许能够消除威胁，却会丢失近期交易数据。

代理式工作流可以汇总证据并测试不同方案，但组织仍需要承担责任的人来在这些结果之间作出选择。正确的选择取决于业务优先级和事件背景。

Cohesity 表示，该模式建立在 RecoveryAgent 的基础上，后者已可协调事件响应和恢复的部分环节。该公司还计划扩展 Cohesity Maestro——一个将韧性能力连接至外部 AI 工具的接口层。

该公司预计 Maestro 将与 Claude、ChatGPT、Gemini 以及其 Helios 管理控制台等系统协同工作。Cohesity 已介绍过 Claude workflows 如何通过 MCP 和代理技能访问其韧性智能。

这些集成带来了有用的灵活性。安全团队可以从其已用于调查事件的 AI 环境中获取恢复信息。

但它们也带来了新的控制面。任何能够查询恢复数据或准备操作的代理，都需要严格限定的权限、可靠的身份机制、全面的日志记录和可审查的输出。

遭入侵的自动化系统不应同时获得对生产资产及其恢复副本的无限制访问权。即便由代理协调流程，职责分离依然重要。

“自主网络韧性”这一表述也可能掩盖不同层级的自动化。自动资产发现所带来的运营风险低于自动恢复生产应用。

策略建议则介于两者之间。它们可以节省管理工作，但如果团队在不了解其假设的情况下批准建议，不佳的建议就会带来实质性后果。

Cohesity 目前的自动化教程显示，基础能力已经将数据发现与持续的保护决策连接起来。更广泛的商业化自动化将逐步推出。

这种分阶段的方法是合理的，因为系统需要在每个层级获得证据。发现准确率、策略质量、洁净室准备情况和恢复一致性都应分别衡量。

最大的不确定性不在于代理能否执行恢复步骤。自动化软件多年来一直在协调基础设施任务。

不确定的是，随着应用和代理不断变化，平台能否持续维持足够准确的业务依赖关系模型。过时的拓扑可能导致技术上成功、但运营上并不完整的恢复。

人工审批并不能消除这一风险。审查者需要清晰了解工作流发现了什么、排除了什么、选择了哪些恢复点，以及其置信度如何。

当自主网络韧性能够让这些判断接受检查时，它才具有可信度。事件期间速度固然重要，但无法解释的速度可能会放大损失。

Cohesity Agent Resilience 尚未证明的事项

该公告勾勒出可信的恢复模型，但其生产环境覆盖范围和可衡量的恢复结果仍有待验证。

第一项限制是可用性。部分客户现在可以使用 Cohesity Agent Resilience，而广泛可用性目标定在 2026 年年底。

受控推出可以帮助 Cohesity 改进代理发现和恢复能力。但这也意味着，大多数潜在客户尚无法在完整生产环境中将该产品与替代方案进行比较。

第二项限制是平台范围。初始支持聚焦于 Amazon Bedrock AgentCore 和 Bedrock Agents，Azure 和 Google 环境仍在规划中。

企业代理通常跨越多项服务。一个代理可能在一个云中运行，从另一个平台检索文档、调用 SaaS 应用，并将记忆存储在外部数据库中。

仅恢复受支持的部分，可能造成状态不一致。Cohesity 需要展示：当这条链路的一部分处于其直接控制范围之外时，拓扑发现和恢复如何运作。

第三项限制涉及恢复粒度。代理的状态可能包括提示词、短期记忆、长期记忆、工具定义、模型设置、访问策略和外部记录。

并非每个组件都应恢复到相同的时间点。一些记录在事件开始后可能仍然有效，而某一条被投毒的记忆项可能才是真正的原因。

恢复整个状态包可能会删除合法工作；恢复范围过窄又可能让入侵状态得以保留。

Cohesity 尚未公开提供这些场景的详细性能结果。买方应寻求有关发现准确率、恢复时间、应用一致性以及后续所需人工协调工作量的证据。

他们还应询问系统如何处理共享依赖。两个代理可能写入同一个数据库或使用同一个记忆存储，因此单独恢复会很困难。

身份是另一个尚未解决的问题。将代理恢复到干净配置，并不一定会撤销已泄露的令牌，或纠正权限过宽的问题。

完整的恢复流程必须与身份和访问系统协同。否则，恢复后的代理可能继承造成问题的同一路径。

第四项限制涉及自动化建议。Cohesity 表示，其平台可以评估态势，并提出策略、扫描方案和恢复演练计划。

在客户通过真实事件和复杂应用环境验证这些输出之前，它们仍只是公司主张。买方应评估建议质量，而不应将自动化本身视为结果。

Cohesity 自身的研究增加了紧迫性，但并不能验证该产品。其第五份年度网络韧性报告发现，78% 的受访组织将恢复工作重点放在恢复系统，而非维持业务运营。

这一数字支持了该公司的观点，即技术恢复可能仍显不足。但它并不能证明 Agent Resilience 或自主工作流填补了这一缺口。

系统恢复与业务恢复之间的区别仍然有意义。恢复后的应用可能仍依赖身份服务、最新数据、员工访问权限及其他应用，业务才能恢复运营。

Cohesity 在其 Catalyst event 中强调了这一问题：该公司将恢复定义为恢复最小可行业务，而非孤立的基础设施。

这一框架提高了正确的标准。客户应根据可信业务流程能否恢复运行来评判代理恢复，而不是看快照是否成功挂载。

第五项限制是责任归属。如果自动化工作流建议了错误的恢复顺序，组织需要留存记录，说明它为何作出该选择，以及由谁批准。

治理不能止步于一个人工审批按钮。审查者需要拥有足够背景信息，才能让审批具有实际意义，尤其是在事件压力促使快速行动时。

这些问题都不会否定 Cohesity 的方向。它们界定了该公司从合理架构走向可靠运营系统所需的证据。

三个信号将显示该战略是否奏效

应通过平台覆盖范围、经验证的恢复结果，以及围绕自动化设置的边界来评判 Cohesity 的战略。

第一个信号是在 2026 年年底前实现广泛可用性。该版本应为受保护状态、依赖关系发现、恢复排序和不受支持的配置提供清晰文档。

更广泛的云支持与发布日期同样重要。Microsoft 和 Google 集成方面的进展将表明，Cohesity 能够超越受到严格控制的 AWS 实现。

延期发布或有限的框架覆盖范围，会削弱该平台能够成为企业代理通用恢复层的主张。

第二个信号是客户证据。Cohesity 需要提供示例，证明代理能够恢复至可信状态，同时所连接的应用和数据保持一致。

有价值的证据应报告恢复时间、发现的依赖关系数量、失败或未完成的恢复，以及后续所需的人工工作。

最有力的证明应来自真实事件，而非预先准备的演示。配置损坏、记忆投毒、过度权限和意外的下游写入，应带来不同的恢复挑战。

客户也应关注重复演练。一次成功恢复的意义，不如定期测试更能说明问题；后者能够证明系统会随着代理和应用变化而保持最新状态。

第三个信号是 Cohesity 如何扩展自主网络韧性。该公司表示，随着该模式接近商业可用性，将增加更多自动化能力。

关键问题在于，哪些决策仍将停留在建议层面，哪些会成为可执行操作。自动发现和洁净室准备不同于自动选择生产环境恢复点。

透明的审批控制将强化 Cohesity 的论点。这些控制应展示拟议操作、支撑证据、预期影响、排除的资产以及回滚路径。

如果自主能力的发展快于可审计性，该战略将被削弱。恢复自动化应缩短响应时间，而不应模糊责任归属。

竞争对手的行动将为所有这三个信号提供更多背景。Commvault、Druva 和 Rubrik 不太可能让代理保护一直停留在狭窄的功能类别中。

它们的回应可能会确立拓扑映射、代理回退、不可变状态和开放集成方面的共同预期，也可能暴露 Cohesity 覆盖范围中的缺口。

对于企业采购方而言，务实的第一步是盘点其智能体目前能够更改哪些内容。团队应识别每个重要智能体所关联的记忆存储、凭证、应用程序、数据库和基础设施。

这一工作将揭示现有备份方案是否覆盖了完整的运营链路，也会显示 AI 智能体恢复产品必须在哪些环节与身份、应用和安全控制措施集成。

正在构建内部知识工作流的组织，也应以同样严谨的方式处理信息依赖关系。持续维护的 AI knowledge base 可以帮助团队了解哪些源材料正在引导人工与自动化决策。

Cohesity Agent Resilience 指向了一项必要的转变：恢复规划必须纳入那些能够记忆并采取行动的软件主体。该产品如今能否成功，取决于它是否能够在不失去一致性、上下文或控制权的前提下恢复这些主体。

在将恢复工作交给自动化系统之前，应先提出一个具体问题：系统能否准确说明它将恢复什么、保留什么不动，以及原因何在？如果答案并不完整，就应坚定保留人工审批这一关卡。