Cohesity Agent Resilience cible la faille de reprise créée par les agents IA
Cohesity a présenté Cohesity Agent Resilience le 16 septembre, étendant la protection de reprise aux agents IA et aux systèmes qu’ils peuvent modifier. Cette nouvelle capacité s’accompagne d’une promesse plus ambitieuse : automatiser davantage la réponse aux cyberincidents sans supprimer l’approbation humaine.
Cette distinction est importante, car les agents d’entreprise deviennent des opérateurs actifs, et non plus de simples assistants passifs. Ils conservent de la mémoire, appellent des applications, mettent à jour des bases de données et exécutent des workflows. La détection peut révéler une action nuisible, mais elle ne peut à elle seule restaurer l’agent ni annuler toutes les ressources affectées.
Cohesity considère l’agent, son état et son infrastructure connectée comme un système unique pouvant être restauré. Commvault, Druva et Rubrik poursuivent des approches similaires, faisant de la reprise des agents IA un nouveau terrain de concurrence sur le marché de la protection des données.
Cohesity Agent Resilience protège plus que l’agent
Cohesity Agent Resilience considère la mémoire et la configuration d’un agent IA comme un état opérationnel récupérable.
Cohesity a annoncé cette capacité lors de son événement virtuel Catalyst 2026, organisé dans plusieurs régions les 16 et 17 septembre. L’entreprise avait auparavant indiqué que Catalyst présenterait de nouveaux contrôles pour les environnements multi-agents et les workflows de reprise autonome.
L’état d’un agent comprend le contexte stocké et la configuration qui influencent son comportement. Si des instructions malveillantes, une dérive de configuration ou une mémoire corrompue altèrent cet état, restaurer une base de données ne restaurera pas nécessairement le jugement de l’agent.
Cohesity indique que sa nouvelle capacité crée des options de reprise à un instant donné pour cet état. Les administrateurs peuvent ramener un agent affecté à une version fiable connue, plutôt que de le reconstruire et de perdre le contexte qu’il a accumulé.
La protection s’étend également à l’infrastructure qui entoure l’agent. Selon la présentation de la reprise des agents, ce périmètre peut inclure des applications, des bases de données, des systèmes de fichiers, des magasins de mémoire et d’autres services que l’agent utilise ou administre.
Ce périmètre élargi répond à un problème fondamental des logiciels agentiques. Un agent peut continuer à fonctionner alors que sa mémoire est corrompue, ou être restauré tout en laissant des modifications nuisibles dans les systèmes connectés.
Cohesity distingue donc deux tâches de reprise. L’une restaure l’état fiable de l’agent. L’autre identifie et restaure les ressources affectées par ses actions.
L’entreprise utilise pour ces deux tâches des mécanismes établis de protection des données. Ceux-ci incluent les snapshots, les sauvegardes immuables et les environnements de reprise isolés, souvent appelés clean rooms.
Une clean room est un environnement séparé utilisé pour inspecter et restaurer des systèmes sans les reconnecter immédiatement à la production. Elle offre aux équipes de réponse un espace pour vérifier si les composants restaurés restent compromis.
L’entreprise décrit également une topologie d’agents qui associe chaque agent à sa mémoire, ses applications, ses bases de données et son infrastructure de support. Cette cartographie des relations vise à révéler les lacunes de protection et à identifier tout ce qui est nécessaire à une reprise fiable.
Cohesity Agent Resilience prend initialement en charge Amazon Bedrock AgentCore et Bedrock Agents. Certains clients peuvent déjà y accéder, tandis que la disponibilité générale est prévue pour la fin de 2026. Les plateformes Microsoft Azure et Google restent inscrites à la feuille de route.
Ces limites en font une première version ciblée plutôt qu’une couche universelle de reprise des agents. Cohesity devra démontrer que le modèle fonctionne dans différents clouds, frameworks d’agents, systèmes de mémoire et structures d’autorisations.
L’annonce modifie néanmoins la frontière de la reprise. Les plateformes de sauvegarde protègent traditionnellement les données et les applications. Cohesity soutient désormais que la mémoire opérationnelle d’un agent doit faire partie de cette frontière, car elle peut directement orienter l’activité de production.
Les détails du lancement et de la feuille de route sont également documentés dans la couverture originale d’Agent Resilience. L’idée centrale est simple : les entreprises ont besoin d’un moyen de restaurer l’acteur autant que les actifs qu’il a touchés.
Les agents IA mettent les plans de reprise traditionnels sous pression
Un agent IA élargit la surface d’incident, car une seule décision compromise peut se propager à travers plusieurs systèmes connectés.
La planification traditionnelle de la reprise suppose généralement que les équipes peuvent identifier les charges de travail endommagées, restaurer des copies propres et valider l’environnement ainsi obtenu. Les agents IA compliquent cette séquence, car ils conservent du contexte et exécutent des actions au-delà des frontières entre applications.
Prenons le cas d’un agent interne de support ayant accès aux tickets, aux dossiers clients et aux référentiels de connaissances. Une instruction corrompue pourrait l’amener à divulguer des informations, modifier des classifications ou écrire des contenus erronés dans plusieurs systèmes.
Restaurer la base de données de tickets pourrait permettre de récupérer des enregistrements supprimés. Cela ne supprimerait pas l’instruction compromise de la mémoire de l’agent ni n’indiquerait quelles actions en aval doivent être annulées.
Le même problème apparaît dans les opérations logicielles. Un agent capable de modifier une configuration, de créer des demandes de déploiement ou de gérer des ressources cloud peut produire une chaîne de changements authentifiés de manière valide, mais nuisibles.
Ces actions ne ressemblent pas nécessairement à une intrusion classique. L’agent peut utiliser des identifiants légitimes et des interfaces approuvées tout en opérant à partir d’un contexte empoisonné ou d’une configuration défaillante.
C’est pourquoi Cohesity présente la reprise des agents IA comme un problème de résilience, et non uniquement de surveillance. La surveillance enregistre les comportements. La reprise établit un point de confiance et restaure les systèmes endommagés après ce point.
Vasu Murthy, directeur produit de Cohesity, a résumé directement cette lacune : la détection peut montrer qu’un agent a dévié de sa trajectoire, mais elle ne peut pas annuler les modifications. Cette affirmation explique pourquoi l’entreprise protège à la fois l’état et les dépendances.
La pression s’exerce d’abord sur les équipes de sécurité et d’infrastructure. Elles doivent décider quelles mémoires d’agents sont importantes, à quelle fréquence les capturer et comment coordonner la reprise entre les ressources connectées.
Les équipes d’ingénierie IA font face à une contrainte connexe. Elles doivent exposer suffisamment d’informations pour que les systèmes de protection puissent identifier les versions des agents, les configurations, les magasins de mémoire, les autorisations et les dépendances externes.
Les responsables d’applications entrent eux aussi dans la chaîne de reprise. Une restauration propre d’un agent a une valeur limitée si ses bases de données, ses contrôles d’identité ou ses applications métier restent dans un état incohérent.
Le problème organisationnel peut devenir plus difficile que le problème de stockage. Des équipes différentes peuvent détenir la responsabilité de l’agent, de son accès au modèle, des données sous-jacentes et de chaque application connectée.
Le concept de topologie de Cohesity tente de rendre ces relations visibles avant un incident. Une cartographie actuelle des dépendances peut indiquer aux équipes de réponse quels systèmes doivent être examinés et quel ordre de reprise préserve la cohérence.
Cette cartographie prend aussi en charge les objectifs de délai de reprise et les objectifs de point de reprise. Un RTO définit la rapidité avec laquelle un service doit revenir, tandis qu’un RPO définit la quantité d’état récent qu’une organisation peut se permettre de perdre.
Ces mesures deviennent moins claires pour un agent. Restaurer la mémoire d’hier peut effacer un contexte utile, tandis que restaurer celle d’aujourd’hui peut préserver la corruption à l’origine de l’incident.
Les équipes devront donc adopter des politiques qui distinguent les connaissances durables de l’état transitoire. Elles devront également décider quelles actions d’agents peuvent être annulées automatiquement et lesquelles nécessitent un examen métier.
La proposition de Cohesity exerce une pression sur les autres fournisseurs de sauvegarde, car les clients s’attendront à ce que les plans de reprise suivent cette frontière de système élargie. Protéger uniquement les fichiers ou les charges de travail paraît incomplet dès lors qu’un logiciel autonome peut modifier les deux.
La question concerne également les entreprises qui n’ont pas adopté d’agents très autonomes. Même des agents limités peuvent rédiger des résumés, classer des enregistrements, appeler des outils ou déclencher des workflows qui influencent des décisions ultérieures.
La résilience des agents n’est donc pas réservée aux systèmes entièrement autonomes. Le seuil pertinent est de savoir si le logiciel peut conserver un état ou effectuer des changements conséquents sans qu’un humain examine chaque action.
La nouvelle concurrence oppose la reprise des agents IA de Cohesity à des contrôles fragmentés
La concurrence sur ce marché ne se résume pas à Cohesity face à un autre fournisseur ; elle oppose une reprise unifiée des agents IA à des contrôles dissociés de surveillance, de sauvegarde et d’applications.
Les entreprises disposent déjà d’outils qui couvrent certains éléments du risque lié aux agents. Les systèmes d’observabilité capturent les traces, les plateformes d’identité gèrent les accès, les journaux d’applications enregistrent les modifications et les produits de sauvegarde préservent les données.
Le problème de reprise apparaît entre ces couches. Une équipe de réponse à incident peut identifier une session d’agent suspecte sans pour autant disposer d’un moyen coordonné de restaurer sa mémoire et chacune des dépendances affectées.
Cohesity souhaite faire de sa plateforme de données cette couche de coordination. Elle peut utiliser ses snapshots et copies immuables existants tout en ajoutant une connaissance de la topologie et de l’état des agents.
Cette approche offre à un fournisseur de sauvegarde établi un point d’entrée naturel. L’entreprise gère déjà des copies de reprise et des environnements isolés pour de nombreux clients.
Toutefois, l’infrastructure existante ne résout pas automatiquement la sémantique des agents. Une plateforme doit savoir quels éléments de mémoire, fichiers de configuration, prompts, outils, identifiants et modifications d’applications appartiennent à un point de reprise précis.
Les concurrents abordent le même problème depuis des directions différentes. AgentCloud de Rubrik met l’accent sur les opérations des agents, la gouvernance, l’observabilité et une capacité de retour en arrière pour les actions non intentionnelles.
Rubrik ouvre également ses données de cyberrésilience aux agents de ses clients via Model Context Protocol, ou MCP. MCP est une interface standard par laquelle les systèmes IA peuvent accéder à des outils et à des données externes sous des contrôles définis.
Cette stratégie permet aux agents de raisonner à partir d’informations de reprise et de lancer des workflows gouvernés. De récents détails sur l’intégration MCP montrent à quelle vitesse les plateformes de reprise deviennent des composants appelables au sein de systèmes IA plus vastes.
Commvault a annoncé AI Protect, conçu pour découvrir les agents et inventorier leurs dépendances dans des environnements connectés. Les enregistrements prévus incluent les modèles, les configurations, les sources de données, les applications et l’infrastructure.
Druva a décrit une protection des agents, un accès aux informations de sauvegarde par l’intermédiaire d’agents et des réponses automatisées aux attaques IA présumées. Cette approche combine la reprise des agents avec une investigation assistée par agents.
Ces approches se recoupent, mais chacune met l’accent sur un point de contrôle différent. Cohesity se concentre sur l’état récupérable et les ressources connectées. Commvault insiste sur la découverte récurrente. Druva combine protection et investigation de sécurité, tandis que Rubrik associe gouvernance et opérations réversibles.
Les clients devraient examiner à quel point chaque plateforme comprend les dépendances des agents. Un produit qui capture la configuration sans cartographier les ressources en aval ne résout que la moitié du problème.
Ils devraient également examiner la couverture des frameworks. La prise en charge initiale d’AWS Bedrock par Cohesity fournit une surface d’intégration définie, mais de nombreuses entreprises construisent des agents avec des frameworks personnalisés et des services cloud mixtes.
Une plateforme de reprise doit gérer ces environnements sans imposer à chaque agent le modèle d’orchestration d’un seul fournisseur. Les interfaces ouvertes peuvent aider, mais elles étendent aussi les autorisations et les décisions de sécurité que les administrateurs doivent gérer.
La pression concurrentielle devrait favoriser les fournisseurs qui relient trois capacités. Ils doivent découvrir les relations entre agents, préserver des versions fiables et orchestrer une reprise cohérente entre les systèmes dépendants.
Aucun fournisseur n’a encore démontré que cela peut fonctionner universellement à travers les piles d’agents d’entreprise. Les annonces de produits indiquent une direction, tandis que les preuves en production détermineront si une reprise unifiée surpasse des contrôles fragmentés.
L’avantage de Cohesity réside dans son socle existant de reprise. Son défi consiste à prouver que ce socle peut représenter avec suffisamment de précision l’état en évolution constante des agents pour permettre une restauration sûre.
La cyberrésilience autonome dépend toujours du jugement humain
Le plan d’automatisation de Cohesity peut réduire le travail répétitif, mais il ne peut supprimer la nécessité de décider ce qu’une reprise sûre doit préserver.
Parallèlement à Cohesity Agent Resilience, l’entreprise a présenté une vision plus large appelée Autonomous Cyber Resilience. Elle utilise des flux de travail agentiques pour automatiser certaines parties d’un cadre de résilience en cinq étapes.
Ces étapes couvrent la protection, la récupérabilité, la remédiation des menaces, les exercices de reprise et l’amélioration continue de la posture de risque liée aux données et à l’IA. Le système proposé découvrirait continuellement les actifs, évaluerait leur protection, validerait l’état de préparation à la reprise et mettrait à jour les plans.
Cohesity décrit un flux de travail dans lequel les administrateurs définissent des objectifs métier via Cohesity Copilot. La plateforme évalue ensuite les charges de travail pertinentes et recommande des politiques de protection, des analyses de menaces et des répétitions de reprise.
Des humains approuveraient ces recommandations avant leur exécution. Lors d’un incident, les administrateurs pourraient lancer des flux de travail automatisés qui évaluent l’impact, repèrent les indicateurs d’activité d’un attaquant et préparent un environnement de reprise isolé.
Ce modèle est plus prudent qu’une remédiation entièrement autonome. Il confie au logiciel la découverte, l’analyse, la préparation et l’orchestration, tout en conservant l’approbation aux opérateurs humains.
Cette limite est importante, car les décisions de reprise impliquent des objectifs contradictoires. Le point de restauration disponible le plus récent peut préserver un état corrompu. Un point de restauration plus ancien peut éliminer la menace, mais faire perdre des transactions récentes.
Les flux de travail agentiques peuvent rassembler des preuves et tester des options, mais les organisations ont toujours besoin de personnes responsables pour choisir entre ces résultats. Le bon choix dépend des priorités métier et du contexte de l’incident.
Cohesity affirme que ce modèle s’appuie sur RecoveryAgent, qui coordonne déjà certaines parties de la réponse aux incidents et de la reprise. L’entreprise prévoit également d’étendre Cohesity Maestro, une couche d’interface reliant les capacités de résilience à des outils d’IA externes.
L’entreprise prévoit que Maestro fonctionne avec des systèmes incluant Claude, ChatGPT, Gemini et sa console de gestion Helios. Cohesity a déjà décrit comment les flux de travail Claude peuvent accéder à ses informations de résilience via MCP et des compétences d’agent.
Ces intégrations apportent une flexibilité utile. Les équipes de sécurité peuvent accéder aux informations de reprise depuis l’environnement d’IA dans lequel elles enquêtent déjà sur les incidents.
Elles créent également une surface de contrôle supplémentaire. Tout agent pouvant interroger des données de reprise ou préparer des actions a besoin d’autorisations strictement limitées, d’une identité fiable, d’une journalisation exhaustive et de résultats vérifiables.
Un système d’automatisation compromis ne doit pas obtenir un accès illimité à la fois aux actifs de production et à leurs copies de reprise. La séparation des tâches reste importante, même lorsqu’un agent coordonne le processus.
L’expression cyberrésilience autonome peut également masquer différents niveaux d’automatisation. La découverte automatique des actifs présente moins de risques opérationnels que la restauration automatique d’applications de production.
Les recommandations de politiques se situent entre ces deux extrêmes. Elles peuvent réduire le travail administratif, mais une mauvaise recommandation devient lourde de conséquences lorsque les équipes l’approuvent sans en comprendre les hypothèses.
Le tutoriel d’automatisation actuel de Cohesity montre que des capacités fondamentales relient déjà la découverte de données aux décisions continues de protection. Une automatisation commerciale plus étendue arrivera progressivement.
Cette approche par étapes est judicieuse, car le système doit fournir des preuves à chaque niveau. La précision de la découverte, la qualité des politiques, la préparation de l’environnement isolé et la cohérence de la reprise doivent être mesurées séparément.
La plus grande incertitude ne concerne pas la capacité des agents à exécuter des étapes de reprise. Les logiciels d’automatisation coordonnent des tâches d’infrastructure depuis des années.
L’incertitude porte sur la capacité de la plateforme à maintenir un modèle suffisamment précis des dépendances métier alors que les applications et les agents évoluent. Une topologie obsolète pourrait produire une reprise techniquement réussie, mais opérationnellement incomplète.
L’approbation humaine n’élimine pas ce risque. Les examinateurs ont besoin d’explications claires sur ce que le flux de travail a identifié, ce qu’il a exclu, les points de reprise qu’il a sélectionnés et son niveau de confiance.
La cyberrésilience autonome sera crédible lorsqu’elle rendra ces jugements inspectables. La vitesse compte lors d’un incident, mais une vitesse inexpliquée peut multiplier les dommages.
Ce que Cohesity Agent Resilience n’a pas encore démontré
L’annonce définit un modèle de reprise crédible, mais la couverture en production et les résultats de reprise mesurables restent non vérifiés.
La première limite concerne la disponibilité. Certains clients sélectionnés peuvent utiliser Cohesity Agent Resilience dès maintenant, tandis qu’une disponibilité générale est visée pour la fin 2026.
Un déploiement contrôlé peut aider Cohesity à affiner la découverte et la reprise des agents. Il signifie également que la plupart des clients potentiels ne peuvent pas encore comparer le produit à leurs environnements de production complets.
La deuxième limite concerne le périmètre de la plateforme. La prise en charge initiale se concentre sur Amazon Bedrock AgentCore et Bedrock Agents, tandis que les environnements Azure et Google restent prévus.
Les agents d’entreprise s’étendent souvent sur plusieurs services. Un agent peut s’exécuter dans un cloud, récupérer des documents depuis une autre plateforme, appeler une application SaaS et stocker sa mémoire dans une base de données externe.
Ne récupérer que la partie prise en charge pourrait créer un état incohérent. Cohesity devra montrer comment la topologie et la restauration fonctionnent lorsqu’une partie de cette chaîne se situe hors de son contrôle direct.
La troisième limite concerne la granularité de la reprise. L’état d’un agent peut inclure des prompts, une mémoire à court terme, une mémoire à long terme, des définitions d’outils, des paramètres de modèle, des politiques d’accès et des enregistrements externes.
Tous les composants ne devraient pas revenir au même horodatage. Certains enregistrements peuvent rester valides après le début d’un incident, tandis qu’un élément de mémoire empoisonné peut être la cause réelle.
Restaurer l’ensemble d’un paquet d’état pourrait supprimer un travail légitime. Restaurer de manière trop limitée pourrait laisser le compromis intact.
Cohesity n’a pas publiquement fourni de résultats détaillés de performance pour ces scénarios. Les acheteurs devraient rechercher des preuves concernant la précision de la découverte, le temps de restauration, la cohérence des applications et le volume de rapprochement manuel requis.
Ils devraient également demander comment le système gère les dépendances partagées. Deux agents peuvent écrire dans la même base de données ou utiliser le même magasin de mémoire, ce qui complique une reprise individuelle.
L’identité introduit une autre question non résolue. Ramener un agent à une configuration saine ne révoque pas nécessairement un jeton compromis ni ne corrige des privilèges excessivement étendus.
Un processus de reprise complet doit se coordonner avec les systèmes d’identité et d’accès. Dans le cas contraire, l’agent restauré peut hériter du même chemin qui a permis le problème.
La quatrième limite concerne les recommandations automatisées. Cohesity affirme que sa plateforme peut évaluer la posture et proposer des politiques, des stratégies d’analyse et des plans d’exercices de reprise.
Ces résultats restent des affirmations de l’entreprise jusqu’à ce que les clients les valident lors d’incidents réels et dans des parcs applicatifs complexes. Les acheteurs devraient évaluer la qualité des recommandations plutôt que de considérer l’automatisation comme un résultat en soi.
Les propres recherches de Cohesity ajoutent une dimension d’urgence, mais ne valident pas le produit. Son cinquième rapport annuel sur la cyberrésilience a révélé que 78 % des organisations interrogées concentrent leurs efforts de reprise sur la restauration des systèmes plutôt que sur le maintien des opérations métier.
Ce chiffre étaye l’argument de l’entreprise selon lequel la restauration technique peut être insuffisante. Il ne montre pas que Agent Resilience ou les flux de travail autonomes comblent cet écart.
La distinction entre reprise des systèmes et reprise métier reste utile. Une application restaurée peut dépendre de services d’identité, de données à jour, de l’accès des employés et d’autres applications avant que les opérations puissent reprendre.
Cohesity a souligné ce problème lors de son événement Catalyst, où l’entreprise a présenté la reprise comme le rétablissement d’une activité minimale viable plutôt que d’une infrastructure isolée.
Ce cadrage fixe le bon niveau d’exigence. Les clients devraient juger la reprise des agents selon la reprise de processus métier fiables, et non selon le simple montage réussi d’un instantané.
La cinquième limite est la responsabilité. Si un flux de travail automatisé recommande une mauvaise séquence de restauration, les organisations ont besoin d’un registre expliquant pourquoi ce choix a été fait et qui l’a approuvé.
La gouvernance ne peut pas s’arrêter à un bouton d’approbation humaine. Les examinateurs ont besoin de suffisamment de contexte pour que l’approbation ait un sens, surtout lorsque la pression d’un incident encourage une action rapide.
Aucune de ces questions n’invalide l’orientation de Cohesity. Elles définissent les preuves nécessaires pour passer d’une architecture plausible à un système opérationnel fiable.
Trois signaux montreront si la stratégie fonctionne
La stratégie de Cohesity devrait être jugée à travers la couverture de la plateforme, des résultats de reprise vérifiés et les limites imposées à l’automatisation.
Le premier signal est la mise à disposition générale d’ici la fin 2026. Cette version devrait inclure une documentation claire sur l’état protégé, la découverte des dépendances, le séquencement des restaurations et les configurations non prises en charge.
L’élargissement de la prise en charge cloud importera autant que la date. Les avancées dans les intégrations Microsoft et Google montreraient que Cohesity peut aller au-delà d’une implémentation AWS étroitement contrôlée.
Une sortie retardée ou une couverture limitée des frameworks affaiblirait l’affirmation selon laquelle la plateforme peut devenir une couche générale de reprise pour les agents d’entreprise.
Le deuxième signal est la preuve apportée par les clients. Cohesity doit fournir des exemples montrant qu’un agent revient à un état fiable tout en maintenant la cohérence des applications et données connectées.
Des preuves utiles indiqueraient le temps de reprise, le nombre de dépendances découvertes, les restaurations échouées ou incomplètes et le travail manuel requis par la suite.
La preuve la plus solide porterait sur des incidents réalistes plutôt que sur des démonstrations préparées. La corruption de configuration, la mémoire empoisonnée, les autorisations excessives et les écritures involontaires en aval devraient poser des défis de reprise différents.
Les clients devraient également rechercher des exercices répétés. Une reprise réussie une seule fois en dit moins que des tests réguliers montrant que le système reste à jour à mesure que les agents et les applications évoluent.
Le troisième signal est la manière dont Cohesity étend la cyberrésilience autonome. L’entreprise affirme qu’elle ajoutera de l’automatisation à mesure que le modèle approchera de la disponibilité commerciale.
La question cruciale est de savoir quelles décisions restent des recommandations et lesquelles deviennent des actions exécutables. La découverte automatique et la préparation d’un environnement isolé diffèrent de la sélection automatique de points de restauration de production.
Des contrôles d’approbation transparents renforceraient la position de Cohesity. Ces contrôles devraient afficher l’action proposée, les preuves à l’appui, l’impact attendu, les actifs exclus et un chemin de retour en arrière.
La stratégie s’affaiblirait si l’autonomie progressait plus vite que l’auditabilité. L’automatisation de la reprise devrait réduire le temps de réponse sans masquer les responsabilités.
Le comportement des concurrents apportera un contexte supplémentaire autour de ces trois signaux. Commvault, Druva et Rubrik ne devraient pas laisser la protection des agents devenir une catégorie de fonctionnalité étroite.
Leurs réponses peuvent établir des attentes communes en matière de cartographie de topologie, de retour en arrière des agents, d’état immuable et d’intégrations ouvertes. Elles peuvent également révéler des lacunes dans la couverture de Cohesity.
Pour les acheteurs d’entreprise, l’étape concrète consiste à recenser ce que leurs agents peuvent modifier dès aujourd’hui. Les équipes doivent identifier les magasins de mémoire, identifiants, applications, bases de données et infrastructures associés à chaque agent important.
Cet exercice permettra de déterminer si les plans de sauvegarde existants couvrent l’ensemble de la chaîne opérationnelle. Il montrera également où un produit de reprise pour agents IA doit s’intégrer aux contrôles d’identité, d’application et de sécurité.
Les organisations qui construisent des flux de travail fondés sur la connaissance interne devraient appliquer la même rigueur aux dépendances informationnelles. Une base de connaissances IA maintenue peut aider les équipes à comprendre quels contenus sources guident les décisions humaines et automatisées.
Cohesity Agent Resilience souligne une évolution nécessaire : la planification de la reprise doit prendre en compte des acteurs logiciels qui mémorisent et agissent. Le succès du produit dépend désormais de sa capacité à restaurer ces acteurs sans perdre la cohérence, le contexte ou le contrôle.
Avant de confier la reprise à l’automatisation, posez une question concrète : le système peut-il expliquer précisément ce qu’il restaurera, ce qu’il laissera intact et pourquoi ? Si la réponse est incomplète, maintenez fermement le point de validation humaine.
