Cohesity Agent Resilience zielt auf die Wiederherstellungslücke, die KI-Agenten schaffen
Cohesity stellte am 16. September Cohesity Agent Resilience vor und erweitert damit den Wiederherstellungsschutz auf KI-Agenten und die Systeme, die sie verändern können. Die neue Funktion ist mit einem anspruchsvolleren Versprechen verbunden: mehr Cyberreaktionen automatisieren, ohne menschliche Freigaben abzuschaffen.
Diese Unterscheidung ist wichtig, weil Unternehmensagenten zu aktiven Akteuren werden und nicht bloß passive Assistenten bleiben. Sie speichern Erinnerungen, rufen Anwendungen auf, aktualisieren Datenbanken und führen Workflows aus. Die Erkennung kann eine schädliche Handlung offenlegen, doch sie allein kann weder den Agenten wiederherstellen noch jede betroffene Ressource zurücksetzen.
Cohesity behandelt den Agenten, seinen Zustand und die angebundene Infrastruktur als ein wiederherstellbares Gesamtsystem. Commvault, Druva und Rubrik verfolgen verwandte Ansätze und machen die Wiederherstellung von KI-Agenten zu einem neuen Wettbewerb im Markt für Datenschutzlösungen.
Cohesity Agent Resilience schützt mehr als den Agenten
Cohesity Agent Resilience behandelt das Gedächtnis und die Konfiguration eines KI-Agenten als wiederherstellbaren Betriebszustand.
Cohesity kündigte die Funktion während seines virtuellen Catalyst-2026-Events an, das am 16. und 17. September in mehreren Regionen stattfand. Das Unternehmen hatte zuvor erklärt, Catalyst werde neue Kontrollen für Multi-Agent-Umgebungen und autonome Wiederherstellungs-Workflows vorstellen.
Zum Zustand eines Agenten gehören der gespeicherte Kontext und die Konfiguration, die sein Verhalten beeinflussen. Wenn böswillige Anweisungen, Konfigurationsdrift oder beschädigte Erinnerungen diesen Zustand verändern, stellt die Wiederherstellung einer Datenbank nicht zwangsläufig auch das Urteilsvermögen des Agenten wieder her.
Cohesity erklärt, die neue Funktion schaffe zeitpunktbasierte Wiederherstellungsoptionen für diesen Zustand. Administratoren können einen betroffenen Agenten auf eine bekannte, vertrauenswürdige Version zurücksetzen, statt ihn neu aufzubauen und den angesammelten Kontext zu verlieren.
Der Schutz erstreckt sich auch auf die Infrastruktur rund um den Agenten. Laut der Übersicht zur Agentenwiederherstellung kann dieser Umfang Anwendungen, Datenbanken, Dateisysteme, Speicherlösungen und andere Dienste umfassen, die der Agent nutzt oder verwaltet.
Dieser größere Umfang adressiert ein grundlegendes Problem agentischer Software. Ein Agent kann weiter funktionieren, obwohl sein Gedächtnis beschädigt ist, oder er kann wiederhergestellt werden, während in verbundenen Systemen schädliche Änderungen zurückbleiben.
Cohesity trennt daher zwei Wiederherstellungsaufgaben. Die eine stellt den vertrauenswürdigen Zustand des Agenten wieder her. Die andere identifiziert und stellt Ressourcen wieder her, die von seinen Aktionen betroffen sind.
Das Unternehmen setzt für beide Aufgaben etablierte Datenschutzmechanismen ein. Dazu zählen Snapshots, unveränderliche Backups und isolierte Wiederherstellungsumgebungen, die oft als Clean Rooms bezeichnet werden.
Ein Clean Room ist eine getrennte Umgebung, in der Systeme geprüft und wiederhergestellt werden können, ohne sie unmittelbar wieder mit der Produktion zu verbinden. Er gibt Einsatzteams Raum zu prüfen, ob wiederhergestellte Komponenten weiterhin kompromittiert sind.
Das Unternehmen beschreibt außerdem eine Agententopologie, die jeden Agenten seinem Gedächtnis, seinen Anwendungen, Datenbanken und der unterstützenden Infrastruktur zuordnet. Diese Beziehungsübersicht soll Schutzlücken aufzeigen und alles identifizieren, was für eine vertrauenswürdige Wiederherstellung erforderlich ist.
Cohesity Agent Resilience unterstützt zunächst Amazon Bedrock AgentCore und Bedrock Agents. Ausgewählte Kunden können die Funktion bereits nutzen; die allgemeine Verfügbarkeit ist für Ende 2026 vorgesehen. Microsoft Azure und Google-Plattformen bleiben auf der Roadmap.
Diese Grenzen machen daraus eine fokussierte erste Version und keine universelle Wiederherstellungsebene für Agenten. Cohesity muss nachweisen, dass das Modell über verschiedene Clouds, Agenten-Frameworks, Speichersysteme und Berechtigungsstrukturen hinweg funktioniert.
Die Ankündigung verschiebt dennoch die Grenze der Wiederherstellung. Backup-Plattformen schützen traditionell Daten und Anwendungen. Cohesity argumentiert nun, dass der operative Speicher eines Agenten innerhalb dieser Grenze liegen muss, weil er Produktionsaktivitäten unmittelbar beeinflussen kann.
Die berichteten Details zur Einführung und zur Roadmap sind auch in der ursprünglichen Berichterstattung zu Agent Resilience dokumentiert. Die zentrale Idee ist einfach: Unternehmen brauchen eine Möglichkeit, sowohl den Akteur als auch die von ihm berührten Ressourcen wiederherzustellen.
KI-Agenten setzen traditionelle Wiederherstellungspläne unter Druck
Ein KI-Agent erweitert die Angriffsfläche eines Vorfalls, weil eine kompromittierte Entscheidung sich über mehrere verbundene Systeme hinweg ausbreiten kann.
Traditionelle Wiederherstellungsplanung geht im Allgemeinen davon aus, dass Teams beschädigte Workloads identifizieren, saubere Kopien wiederherstellen und die resultierende Umgebung validieren können. KI-Agenten verkomplizieren diese Abfolge, weil sie Kontext speichern und über Anwendungsgrenzen hinweg handeln.
Betrachten wir einen internen Support-Agenten mit Zugriff auf Tickets, Kundendaten und Wissensdatenbanken. Eine beschädigte Anweisung könnte dazu führen, dass er Informationen offenlegt, Klassifizierungen ändert oder falsche Inhalte in mehrere Systeme schreibt.
Die Wiederherstellung der Ticketing-Datenbank könnte gelöschte Einträge zurückbringen. Sie würde jedoch weder die kompromittierte Anweisung aus dem Gedächtnis des Agenten entfernen noch zeigen, welche nachgelagerten Aktionen rückgängig gemacht werden müssen.
Dasselbe Problem tritt im Softwarebetrieb auf. Ein Agent, der Konfigurationen ändern, Bereitstellungsanfragen erstellen oder Cloud-Ressourcen verwalten kann, kann eine Kette gültig authentifizierter, aber schädlicher Änderungen erzeugen.
Diese Aktionen ähneln möglicherweise keinem klassischen Eindringen. Der Agent kann legitime Zugangsdaten und genehmigte Schnittstellen verwenden, während er auf Grundlage eines manipulierten Kontexts oder einer fehlerhaften Konfiguration agiert.
Deshalb beschreibt Cohesity die Wiederherstellung von KI-Agenten als Resilienzproblem und nicht nur als Monitoring-Problem. Monitoring zeichnet Verhalten auf. Wiederherstellung etabliert einen vertrauenswürdigen Zeitpunkt und stellt die danach beschädigten Systeme wieder her.
Vasu Murthy, Chief Product Officer von Cohesity, fasste die Lücke direkt zusammen: Die Erkennung kann zeigen, dass ein Agent vom Kurs abgekommen ist, aber sie kann die Änderungen nicht rückgängig machen. Diese Aussage erklärt, warum das Unternehmen sowohl Zustand als auch Abhängigkeiten schützt.
Der Druck liegt zunächst bei Sicherheits- und Infrastrukturteams. Sie müssen entscheiden, welche Agentenerinnerungen relevant sind, wie häufig sie erfasst werden und wie sich die Wiederherstellung über verbundene Ressourcen hinweg koordinieren lässt.
KI-Engineering-Teams stehen vor einer verwandten Aufgabe. Sie müssen genügend Informationen bereitstellen, damit Schutzsysteme Agentenversionen, Konfigurationen, Speichersysteme, Berechtigungen und externe Abhängigkeiten identifizieren können.
Auch Anwendungsbesitzer werden Teil der Wiederherstellungskette. Eine saubere Wiederherstellung eines Agenten hat nur begrenzten Wert, wenn seine Datenbanken, Identitätskontrollen oder Geschäftsanwendungen weiterhin in einem inkonsistenten Zustand verbleiben.
Das organisatorische Problem kann schwieriger werden als das Speicherproblem. Unterschiedliche Teams können für den Agenten, seinen Modellzugriff, die zugrunde liegenden Daten und jede verbundene Anwendung verantwortlich sein.
Cohesitys Topologiekonzept versucht, diese Beziehungen vor einem Vorfall sichtbar zu machen. Eine aktuelle Abhängigkeitskarte kann Einsatzteams mitteilen, welche Systeme untersucht werden müssen und welche Wiederherstellungsreihenfolge Konsistenz bewahrt.
Diese Zuordnung unterstützt auch Recovery Time Objectives und Recovery Point Objectives. Ein RTO definiert, wie schnell ein Dienst zurückkehren soll, während ein RPO festlegt, wie viel jüngsten Zustand eine Organisation verlieren kann.
Für einen Agenten werden diese Messgrößen weniger eindeutig. Die Wiederherstellung des Gedächtnisses von gestern kann nützlichen Kontext löschen, während die Wiederherstellung des heutigen Gedächtnisses die Korruption bewahren kann, die den Vorfall verursacht hat.
Teams benötigen daher Richtlinien, die dauerhaftes Wissen von temporärem Zustand unterscheiden. Sie müssen außerdem entscheiden, welche Agentenaktionen automatisch rückgängig gemacht werden können und welche eine geschäftliche Prüfung erfordern.
Cohesitys Angebot setzt andere Backup-Anbieter unter Druck, weil Kunden erwarten werden, dass Wiederherstellungspläne dieser breiteren Systemgrenze folgen. Der Schutz nur von Dateien oder Workloads wirkt unvollständig, sobald autonome Software beides verändern kann.
Das Thema betrifft auch Unternehmen, die noch keine hochautonomen Agenten eingeführt haben. Selbst eingeschränkte Agenten können Zusammenfassungen schreiben, Datensätze klassifizieren, Tools aufrufen oder Workflows auslösen, die spätere Entscheidungen beeinflussen.
Agentenresilienz ist daher nicht vollständig autonomen Systemen vorbehalten. Die relevante Schwelle liegt darin, ob die Software Zustand bewahren oder folgenschwere Änderungen vornehmen kann, ohne jede Aktion von einem Menschen prüfen zu lassen.
Der neue Wettbewerb lautet Cohesity-KI-Agentenwiederherstellung gegen fragmentierte Kontrollen
Beim Marktwettbewerb geht es nicht einfach um Cohesity gegen einen anderen Anbieter, sondern um einheitliche KI-Agentenwiederherstellung gegen getrennte Monitoring-, Backup- und Anwendungskontrollen.
Unternehmen verfügen bereits über Tools, die Teile des Agentenrisikos adressieren. Observability-Systeme erfassen Traces, Identitätsplattformen verwalten Zugriffe, Anwendungsprotokolle zeichnen Änderungen auf und Backup-Produkte sichern Daten.
Das Wiederherstellungsproblem entsteht zwischen diesen Ebenen. Ein Incident-Response-Team kann eine verdächtige Agentensitzung identifizieren, verfügt aber möglicherweise weiterhin nicht über eine koordinierte Möglichkeit, dessen Gedächtnis und jede betroffene Abhängigkeit wiederherzustellen.
Cohesity möchte, dass seine Datenplattform diese Koordinationsebene wird. Sie kann vorhandene Snapshots und unveränderliche Kopien nutzen und gleichzeitig Wissen über Agententopologie und -zustand ergänzen.
Dieser Ansatz verschafft einem etablierten Backup-Anbieter einen natürlichen Einstiegspunkt. Das Unternehmen verwaltet bereits für viele Kunden Wiederherstellungskopien und isolierte Umgebungen.
Bestehende Infrastruktur löst jedoch nicht automatisch die Semantik von Agenten. Eine Plattform muss wissen, welche Speicherelemente, Konfigurationsdateien, Prompts, Tools, Zugangsdaten und Anwendungsänderungen zu einem bestimmten Wiederherstellungspunkt gehören.
Wettbewerber nähern sich demselben Problem aus unterschiedlichen Richtungen. Rubriks AgentCloud betont Agentenbetrieb, Governance, Observability und eine Rückspulfunktion für unbeabsichtigte Aktionen.
Rubrik öffnet außerdem seine Cyber-Resilienz-Daten über das Model Context Protocol, kurz MCP, für Kundenagenten. MCP ist eine Standardschnittstelle, über die KI-Systeme unter definierten Kontrollen auf externe Tools und Daten zugreifen können.
Diese Strategie erlaubt Agenten, über Wiederherstellungsinformationen zu schlussfolgern und kontrollierte Workflows zu initiieren. Aktuelle Details zur MCP-Integration zeigen, wie schnell Wiederherstellungsplattformen zu aufrufbaren Komponenten innerhalb umfassenderer KI-Systeme werden.
Commvault hat AI Protect angekündigt, das Agenten erkennen und ihre Abhängigkeiten in verbundenen Umgebungen inventarisieren soll. Die geplanten Datensätze umfassen Modelle, Konfigurationen, Datenquellen, Anwendungen und Infrastruktur.
Druva hat Schutz für Agenten, Zugriff auf Backup-Informationen über Agenten und automatisierte Reaktionen auf vermutete KI-Angriffe beschrieben. Das verbindet Agentenwiederherstellung mit agentengestützter Untersuchung.
Diese Ansätze überschneiden sich, doch jeder betont einen anderen Kontrollpunkt. Cohesity stellt wiederherstellbaren Zustand und verbundene Ressourcen in den Mittelpunkt. Commvault betont die wiederkehrende Erkennung. Druva verbindet Schutz mit Sicherheitsuntersuchungen, während Rubrik Governance und reversible Abläufe verknüpft.
Kunden sollten prüfen, wie tief jede Plattform Agentenabhängigkeiten versteht. Ein Produkt, das Konfigurationen erfasst, ohne nachgelagerte Ressourcen abzubilden, löst nur die Hälfte des Problems.
Sie sollten auch die Framework-Abdeckung prüfen. Cohesitys anfängliche Unterstützung für AWS Bedrock bietet eine klar definierte Integrationsfläche, doch viele Unternehmen entwickeln Agenten mit eigenen Frameworks und gemischten Cloud-Diensten.
Eine Wiederherstellungsplattform muss solche Umgebungen bewältigen, ohne jeden Agenten in das Orchestrierungsmodell eines einzelnen Anbieters zu zwingen. Offene Schnittstellen können helfen, erweitern jedoch zugleich die Berechtigungs- und Sicherheitsentscheidungen, die Administratoren verwalten müssen.
Der Wettbewerbsdruck dürfte Anbieter begünstigen, die drei Fähigkeiten verbinden. Sie müssen Beziehungen zwischen Agents erkennen, vertrauenswürdige Versionen bewahren und eine konsistente Wiederherstellung über abhängige Systeme hinweg orchestrieren.
Noch kein Anbieter hat gezeigt, dass dies universell über Enterprise-Agent-Stacks hinweg funktioniert. Produktankündigungen geben die Richtung vor, doch belastbare Produktionsnachweise werden entscheiden, ob eine einheitliche Wiederherstellung fragmentierte Kontrollen übertrifft.
Der Vorteil von Cohesity liegt in seiner bestehenden Wiederherstellungsgrundlage. Die Herausforderung besteht darin, nachzuweisen, dass diese Grundlage den sich ständig wandelnden Zustand von Agents präzise genug abbilden kann, um eine sichere Wiederherstellung zu unterstützen.
Autonome Cyberresilienz bleibt auf menschliches Urteilsvermögen angewiesen
Der Automatisierungsplan von Cohesity kann repetitive Arbeit reduzieren, aber nicht die Notwendigkeit beseitigen zu entscheiden, was eine sichere Wiederherstellung bewahren sollte.
Neben Cohesity Agent Resilience skizzierte das Unternehmen eine umfassendere Vision namens Autonomous Cyber Resilience. Sie nutzt agentische Workflows, um Teile eines fünfstufigen Resilienzrahmens zu automatisieren.
Diese Schritte umfassen Schutz, Wiederherstellbarkeit, Bedrohungsbeseitigung, Wiederherstellungsübungen und die kontinuierliche Verbesserung der Risikoabsicherung für Daten und KI. Das vorgeschlagene System würde Assets fortlaufend erkennen, den Schutz bewerten, die Wiederherstellungsbereitschaft prüfen und Pläne aktualisieren.
Cohesity beschreibt einen Workflow, in dem Administratoren Geschäftsziele über Cohesity Copilot festlegen. Die Plattform bewertet anschließend relevante Workloads und empfiehlt Schutzrichtlinien, Bedrohungsscans und Wiederherstellungsübungen.
Menschen würden diese Empfehlungen vor der Ausführung genehmigen. Während eines Vorfalls könnten Administratoren automatisierte Workflows starten, die Auswirkungen bewerten, Indikatoren für Angreiferaktivitäten finden und eine isolierte Wiederherstellungsumgebung vorbereiten.
Dieses Modell ist vorsichtiger als eine vollständig autonome Behebung. Es überträgt Software die Verantwortung für Erkennung, Analyse, Vorbereitung und Orchestrierung, während die Genehmigung bei menschlichen Bedienern bleibt.
Diese Grenze ist wichtig, weil Wiederherstellungsentscheidungen widersprüchliche Ziele beinhalten. Der schnellste verfügbare Wiederherstellungspunkt könnte einen beschädigten Zustand bewahren. Ein älterer Wiederherstellungspunkt könnte die Bedrohung beseitigen, aber jüngere Transaktionen verlieren lassen.
Agentische Workflows können Belege zusammenführen und Optionen testen, doch Organisationen benötigen weiterhin verantwortliche Personen, die zwischen diesen Ergebnissen wählen. Die richtige Wahl hängt von geschäftlichen Prioritäten und dem Kontext des Vorfalls ab.
Cohesity erklärt, das Modell baue auf RecoveryAgent auf, das bereits Teile der Incident Response und Wiederherstellung koordiniert. Zudem plant das Unternehmen, Cohesity Maestro auszubauen, eine Schnittstellenebene, die Resilienzfunktionen mit externen KI-Tools verbindet.
Das Unternehmen erwartet, dass Maestro mit Systemen wie Claude, ChatGPT, Gemini und seiner Helios-Managementkonsole arbeitet. Cohesity hat bereits beschrieben, wie Claude workflows über MCP und Agent Skills auf seine Resilienzintelligenz zugreifen können.
Diese Integrationen schaffen nützliche Flexibilität. Sicherheitsteams können auf Wiederherstellungsinformationen aus der KI-Umgebung zugreifen, in der sie Vorfälle bereits untersuchen.
Sie schaffen jedoch auch eine weitere Kontrollfläche. Jeder Agent, der Wiederherstellungsdaten abfragen oder Aktionen vorbereiten kann, benötigt eng begrenzte Berechtigungen, eine verlässliche Identität, umfassende Protokollierung und überprüfbare Ergebnisse.
Ein kompromittiertes Automatisierungssystem darf keinen uneingeschränkten Zugriff sowohl auf Produktions-Assets als auch auf deren Wiederherstellungskopien erhalten. Die Trennung von Zuständigkeiten bleibt wichtig, selbst wenn ein Agent den Prozess koordiniert.
Der Begriff autonome Cyberresilienz kann zudem unterschiedliche Automatisierungsgrade verschleiern. Die automatische Asset-Erkennung birgt ein geringeres operatives Risiko als die automatische Wiederherstellung von Produktionsanwendungen.
Richtlinienempfehlungen liegen zwischen diesen Punkten. Sie können Verwaltungsarbeit einsparen, doch eine schlechte Empfehlung wird folgenschwer, wenn Teams sie genehmigen, ohne ihre Annahmen zu verstehen.
Das aktuelle automation tutorial von Cohesity zeigt, dass grundlegende Fähigkeiten die Datenerkennung bereits mit fortlaufenden Schutzentscheidungen verknüpfen. Umfassendere kommerzielle Automatisierung wird schrittweise eingeführt.
Dieser stufenweise Ansatz ist sinnvoll, weil das System auf jeder Ebene Nachweise benötigt. Erkennungsgenauigkeit, Richtlinienqualität, Vorbereitung eines Clean Rooms und Wiederherstellungskonsistenz sollten getrennt gemessen werden.
Die größte Unsicherheit besteht nicht darin, ob Agents Wiederherstellungsschritte ausführen können. Automatisierungssoftware koordiniert seit Jahren Infrastrukturaufgaben.
Unklar ist, ob die Plattform ein ausreichend präzises Modell geschäftlicher Abhängigkeiten aufrechterhalten kann, während sich Anwendungen und Agents verändern. Eine veraltete Topologie könnte zu einer technisch erfolgreichen, aber operativ unvollständigen Wiederherstellung führen.
Menschliche Genehmigung beseitigt dieses Risiko nicht. Prüfer benötigen klare Erklärungen dazu, was der Workflow gefunden hat, was er ausgeschlossen hat, welche Wiederherstellungspunkte er ausgewählt hat und wie hoch seine Sicherheit ist.
Autonome Cyberresilienz wird glaubwürdig sein, wenn sie diese Bewertungen überprüfbar macht. Geschwindigkeit ist während eines Vorfalls wichtig, doch nicht erklärte Geschwindigkeit kann den Schaden vervielfachen.
Was Cohesity Agent Resilience noch nicht bewiesen hat
Die Ankündigung definiert ein glaubwürdiges Wiederherstellungsmodell, doch Produktionsabdeckung und messbare Wiederherstellungsergebnisse bleiben unbestätigt.
Die erste Einschränkung betrifft die Verfügbarkeit. Ausgewählte Kunden können Cohesity Agent Resilience bereits nutzen, während die breite Verfügbarkeit für Ende 2026 angestrebt wird.
Eine kontrollierte Einführung kann Cohesity helfen, Agent-Erkennung und Wiederherstellung zu verfeinern. Sie bedeutet jedoch auch, dass die meisten potenziellen Kunden das Produkt noch nicht mit ihren vollständigen Produktionsumgebungen vergleichen können.
Die zweite Einschränkung betrifft den Plattformumfang. Die anfängliche Unterstützung konzentriert sich auf Amazon Bedrock AgentCore und Bedrock Agents, während Azure- und Google-Umgebungen weiterhin geplant sind.
Enterprise-Agents erstrecken sich häufig über mehrere Dienste. Ein Agent kann in einer Cloud laufen, Dokumente von einer anderen Plattform abrufen, eine SaaS-Anwendung aufrufen und Speicher in einer externen Datenbank ablegen.
Die Wiederherstellung nur des unterstützten Teils könnte einen inkonsistenten Zustand erzeugen. Cohesity wird zeigen müssen, wie Topologie und Wiederherstellung funktionieren, wenn ein Teil dieser Kette außerhalb seiner direkten Kontrolle liegt.
Die dritte Einschränkung betrifft die Granularität der Wiederherstellung. Der Zustand eines Agents kann Prompts, Kurzzeitgedächtnis, Langzeitgedächtnis, Tool-Definitionen, Modelleinstellungen, Zugriffsrichtlinien und externe Datensätze umfassen.
Nicht jede Komponente sollte auf denselben Zeitstempel zurückgesetzt werden. Einige Datensätze können nach Beginn eines Vorfalls gültig sein, während ein einzelner vergifteter Speichereintrag die eigentliche Ursache sein kann.
Die Wiederherstellung eines gesamten Zustandsbündels könnte legitime Arbeit entfernen. Eine zu eng gefasste Wiederherstellung könnte den Kompromiss dagegen bestehen lassen.
Cohesity hat für diese Szenarien öffentlich keine detaillierten Leistungsergebnisse vorgelegt. Käufer sollten Nachweise zur Erkennungsgenauigkeit, Wiederherstellungszeit, Anwendungskonsistenz und zum erforderlichen Umfang manueller Abstimmung einholen.
Sie sollten auch fragen, wie das System mit gemeinsam genutzten Abhängigkeiten umgeht. Zwei Agents können in dieselbe Datenbank schreiben oder denselben Memory Store verwenden, was eine individuelle Wiederherstellung erschwert.
Die Identität bringt ein weiteres ungelöstes Problem mit sich. Einen Agent auf eine saubere Konfiguration zurückzuführen, widerruft nicht zwangsläufig ein kompromittiertes Token und korrigiert auch keine zu weitreichenden Berechtigungen.
Ein vollständiger Wiederherstellungsprozess muss sich mit Identitäts- und Zugriffssystemen abstimmen. Andernfalls kann der wiederhergestellte Agent denselben Pfad übernehmen, der das Problem ermöglicht hat.
Die vierte Einschränkung betrifft automatisierte Empfehlungen. Cohesity erklärt, seine Plattform könne die Sicherheitslage bewerten und Richtlinien, Scanstrategien sowie Pläne für Wiederherstellungsübungen vorschlagen.
Diese Ergebnisse bleiben Unternehmensbehauptungen, bis Kunden sie über reale Vorfälle und komplexe Anwendungslandschaften hinweg validieren. Käufer sollten die Qualität der Empfehlungen bewerten, statt Automatisierung als Ergebnis an sich zu betrachten.
Die eigene Forschung von Cohesity erhöht die Dringlichkeit, validiert aber nicht das Produkt. Der fünfte jährliche Cyber-Resilience-Bericht des Unternehmens ergab, dass 78 Prozent der befragten Organisationen ihre Wiederherstellungsbemühungen auf die Wiederherstellung von Systemen konzentrieren, statt den Geschäftsbetrieb aufrechtzuerhalten.
Diese Zahl stützt das Argument des Unternehmens, dass technische Wiederherstellung unzureichend sein kann. Sie zeigt nicht, dass Agent Resilience oder autonome Workflows diese Lücke schließen.
Die Unterscheidung zwischen Systemwiederherstellung und Geschäftswiederherstellung bleibt dennoch nützlich. Eine wiederhergestellte Anwendung kann Identitätsdienste, aktuelle Daten, Mitarbeiterzugriff und andere Anwendungen benötigen, bevor der Betrieb wieder aufgenommen werden kann.
Cohesity hob dieses Thema während seines Catalyst event hervor, bei dem das Unternehmen Wiederherstellung als Wiederherstellung eines minimal lebensfähigen Geschäftsbetriebs statt isolierter Infrastruktur darstellte.
Diese Einordnung setzt den richtigen Maßstab. Kunden sollten die Wiederherstellung von Agents daran messen, ob vertrauenswürdige Geschäftsprozesse wieder aufgenommen werden, und nicht daran, ob ein Snapshot erfolgreich eingebunden wurde.
Die fünfte Einschränkung ist die Verantwortlichkeit. Wenn ein automatisierter Workflow die falsche Wiederherstellungsreihenfolge empfiehlt, benötigen Organisationen eine Aufzeichnung darüber, warum er diese Wahl getroffen hat und wer sie genehmigt hat.
Governance darf nicht bei einer Schaltfläche zur menschlichen Genehmigung enden. Prüfer benötigen ausreichend Kontext, damit die Genehmigung sinnvoll ist, insbesondere wenn der Druck eines Vorfalls zu schnellem Handeln verleitet.
Keine dieser Fragen stellt die Richtung von Cohesity infrage. Sie definieren die Nachweise, die erforderlich sind, um von einer plausiblen Architektur zu einem verlässlichen Betriebssystem zu gelangen.
Drei Signale werden zeigen, ob die Strategie funktioniert
Die Strategie von Cohesity sollte anhand der Plattformabdeckung, verifizierter Wiederherstellungsergebnisse und der Grenzen bewertet werden, die der Automatisierung gesetzt werden.
Das erste Signal ist die Bereitstellung der allgemeinen Verfügbarkeit bis Ende 2026. Diese Veröffentlichung sollte klare Dokumentation zum geschützten Zustand, zur Abhängigkeitserkennung, zur Wiederherstellungsreihenfolge und zu nicht unterstützten Konfigurationen enthalten.
Eine breitere Cloud-Unterstützung wird ebenso wichtig sein wie das Datum. Fortschritte bei Microsoft- und Google-Integrationen würden zeigen, dass Cohesity über eine eng kontrollierte AWS-Implementierung hinausgehen kann.
Eine verzögerte Veröffentlichung oder eine begrenzte Abdeckung von Frameworks würde die Behauptung schwächen, dass die Plattform zu einer allgemeinen Wiederherstellungsebene für Enterprise-Agents werden kann.
Das zweite Signal sind Kundennachweise. Cohesity benötigt Beispiele, die zeigen, dass ein Agent in einen vertrauenswürdigen Zustand zurückkehrt, während verbundene Anwendungen und Daten konsistent bleiben.
Nützliche Nachweise würden Wiederherstellungszeit, die Anzahl erkannter Abhängigkeiten, fehlgeschlagene oder unvollständige Wiederherstellungen und die danach erforderliche manuelle Arbeit ausweisen.
Der stärkste Beleg würde reale Vorfälle statt vorbereiteter Demonstrationen einbeziehen. Konfigurationsbeschädigung, vergifteter Speicher, übermäßige Berechtigungen und unbeabsichtigte nachgelagerte Schreibvorgänge sollten unterschiedliche Wiederherstellungsherausforderungen hervorrufen.
Kunden sollten zudem nach wiederholten Übungen suchen. Eine erfolgreiche einmalige Wiederherstellung sagt weniger aus als regelmäßige Tests, die zeigen, dass das System aktuell bleibt, während sich Agents und Anwendungen verändern.
Das dritte Signal ist, wie Cohesity autonome Cyberresilienz ausbaut. Das Unternehmen erklärt, es werde Automatisierung ergänzen, sobald sich das Modell der kommerziellen Verfügbarkeit nähert.
Die entscheidende Frage lautet, welche Entscheidungen Empfehlungen bleiben und welche zu ausführbaren Aktionen werden. Automatische Erkennung und Vorbereitung eines Clean Rooms unterscheiden sich von der automatischen Auswahl von Wiederherstellungspunkten für die Produktion.
Transparente Genehmigungskontrollen würden die Argumentation von Cohesity stärken. Diese Kontrollen sollten die vorgeschlagene Aktion, unterstützende Nachweise, die erwarteten Auswirkungen, ausgeschlossene Assets und einen Rücksetzpfad zeigen.
Die Strategie würde geschwächt, wenn die Autonomie schneller voranschreitet als die Auditierbarkeit. Wiederherstellungsautomatisierung sollte die Reaktionszeit verkürzen, ohne Verantwortlichkeit zu verschleiern.
Das Verhalten von Wettbewerbern wird zusätzlichen Kontext für alle drei Signale liefern. Commvault, Druva und Rubrik werden den Schutz von Agents voraussichtlich nicht als enge Funktionskategorie bestehen lassen.
Ihre Reaktionen können gemeinsame Erwartungen an Topologie-Mapping, Agent-Rewind, unveränderlichen Zustand und offene Integrationen etablieren. Sie können auch Lücken in der Abdeckung von Cohesity aufdecken.
Für Unternehmenskäufer besteht der praktische nächste Schritt darin, zu erfassen, was ihre Agenten derzeit verändern können. Teams sollten die mit jedem wichtigen Agenten verbundenen Speicher, Zugangsdaten, Anwendungen, Datenbanken und Infrastrukturen identifizieren.
Diese Bestandsaufnahme zeigt, ob bestehende Backup-Pläne die gesamte operative Kette abdecken. Außerdem wird deutlich, wo sich ein Produkt zur Wiederherstellung von AI-Agenten in Identitäts-, Anwendungs- und Sicherheitskontrollen integrieren muss.
Organisationen, die interne Wissens-Workflows aufbauen, sollten bei Informationsabhängigkeiten dieselbe Sorgfalt anwenden. Eine gepflegte AI knowledge base kann Teams dabei helfen zu verstehen, welches Quellenmaterial menschliche und automatisierte Entscheidungen leitet.
Cohesity Agent Resilience weist auf eine notwendige Veränderung hin: Die Wiederherstellungsplanung muss Software-Akteure berücksichtigen, die sich erinnern und handeln. Der Erfolg des Produkts hängt nun davon ab, ob es diese Akteure wiederherstellen kann, ohne Konsistenz, Kontext oder Kontrolle zu verlieren.
Bevor Sie der Automatisierung die Wiederherstellung anvertrauen, stellen Sie eine konkrete Frage: Kann das System genau erklären, was es wiederherstellen wird, was es unberührt lässt und warum? Wenn die Antwort unvollständig ist, sollte die menschliche Freigabeschleuse unbedingt bestehen bleiben.
