Cohesity says rolling back an AI agent leaves its sent emails and outside changes in place

Agent Resilience stores immutable, point-in-time recovery points for supported agent components ^[5]. Immutable means a recovery point cannot be changed once captured ^[5]. The components are memory, the stored information an agent uses across tasks, and configuration, the settings for how it operates ^[16]. According to LDS, a rollback of that state does not reach what the agent already did outside it. An email may already have left the organization, information may already be disclosed, and an outside system may still hold a change that needs its own correction ^[1].

Enrollment also limits what a rollback covers. Swami Ramany, Cohesity's GVP of Product Management, separates discovering an agent's dependencies from protecting them ^[3][4]. The product's topology map draws the agent's links to memory stores, applications, databases and infrastructure ^[4]. Ramany says a resource showing up on that map does not mean it has been backed up or can be restored ^[4]. I would check that distinction first in any deployment, since a dependency map can be a very complete list of things the backup does not cover. Where an S3 bucket or RDS database is protected, the team can take it back to an earlier trusted point ^[18].

The harder case is a backup that faithfully preserves the wrong information ^[17]. If an agent's memory was poisoned before the recovery point was taken, locking that point against later edits does nothing about the earlier contamination ^[17]. "Immutability prevents a recovery point from being altered after capture. It does not prove that the captured state was clean," Ramany wrote ^[13]. Picking the compromise window is the customer's job ^[14]. In the example from Anu Paul Parayil, Cohesity's Senior Product Marketing Manager, the response team links an alert to a recent memory change and works back to the likely period of compromise ^[3][9]. If that estimate starts too late, the restore loads a recovery point that already holds the bad memory ^[17].

Cohesity leaves detection to other tools. "Security and observability tools identify the issue; Agent Resilience provides the recovery path," Parayil wrote ^[11]. The return-to-service half of her example is careful work. Before restart, the team runs known validation prompts, checks expected behavior and permissions, and looks for unintended changes ^[12]. The application owner and the security lead both approve the move back to production. The finished restore is one input to that decision ^[12].

According to LDS, the Cohesity answers separate an intended recovery-time advantage from a measured benchmark ^[15]. Until a measurement is published, I treat the advantage as a design target. For a recovery-time number to transfer to a given team, it would have to cover that team's whole path: dating the compromise, restoring memory, configuration and any enrolled S3 or RDS resources, validation, and two human approvals ^[9][12][18]. In my view only the restore steps are something the product can speed up. The procurement agent on Amazon Bedrock behind the whole walkthrough is an example Parayil supplied to explain the workflow, not a documented customer incident or a recovery test LDS observed ^[8].