Points clés à retenir
- Les systèmes d’IA agentique sont des systèmes à état qui fonctionnent en continu, ce qui rend les modèles de récupération traditionnels insuffisants.
- La couche mémoire (bases de données vectorielles et stockage de contexte) constitue une surface d’attaque critique mais insuffisamment surveillée.
- Les flux de travail de prise de décision en temps réel peuvent être modifiés sans déclencher les alertes de sécurité habituelles.
- Les lacunes en matière d’observabilité dans les interactions entre agents empêchent la plupart des organisations d’avoir une vision complète des risques.
- Une véritable reprise nécessite un enregistrement unifié et synchronisé dans le temps de toutes les couches du système afin de rétablir un état fiable.
La plupart des entreprises qui entrent dans l’ère de l’IA agentique gèrent la résilience en se basant sur un modèle mental erroné – et les données le confirment : seule une entreprise sur cinq dispose d’un modèle abouti pour régir les agents IA autonomes. Elles envisagent l’IA comme elles envisagent les applications : comme des entités distinctes, sans état, pouvant être remises en état en réintégrant des données saines dans un environnement sain.
L’IA agentique ne fonctionne pas ainsi. Ces systèmes sont à état, fonctionnent en continu et sont organisés en couches d’une manière qui engendre des modes de défaillance que la plupart des cadres de sécurité et de résilience n’ont pas été conçus pour gérer. Le problème ne réside pas dans les outils. Il réside dans la compréhension de ce qui s’exécute réellement – et de ce que le terme « Recovery » doit signifier pour des systèmes construits de cette manière.
Quatre couches architecturales définissent le problème. Chacune est distincte. Chacune est insuffisamment protégée. Et ensemble, elles expliquent pourquoi un système d’IA agentique peut sembler récupérable tout en restant fondamentalement compromis.
Couche 1 : Mémoire des agents – La surface d’attaque que vous ne surveillez pas
Les applications d’entreprise traditionnelles ne conservent aucune information d’une session à l’autre. Ce n’est pas le cas de l’IA agentique. La couche de mémoire – composée principalement de bases de données vectorielles stockant des représentations vectorielles, mais aussi l’état de la session et le contexte récupéré – est ce qui assure la continuité des agents d’une interaction à l’autre. C’est ce qui permet à un agent de reprendre là où il s’était arrêté, de s’appuyer sur le contexte antérieur et de se forger une vision cohérente d’un flux de travail complexe au fil du temps.
Il s’agit également de l’une des surfaces d’attaque les plus critiques de l’infrastructure moderne des entreprises – et l’une des moins surveillées. Le vecteur d’attaque est suffisamment subtil pour échapper à la plupart des outils de sécurité conventionnels. Un attaquant capable d’influencer le contenu d’une base de données vectorielle peut façonner ce que l’agent considère comme vrai. Les représentations injectées ou manipulées n’ont pas besoin de paraître malveillantes : il leur suffit de sembler fiables.
Une mémoire compromise peut modifier le comportement d’un agent, permettre l’exfiltration de données par le biais des actions de l’agent ou amener ce dernier à prendre des décisions qui semblent légitimes mais qui servent les objectifs d’un attaquant. Aucune de ces actions ne nécessite d’intervenir directement sur le modèle lui-même. Le problème de détection est aggravé par le volume et la vitesse des écritures dans les bases de données vectorielles au sein des déploiements d’agents actifs. Les outils de détection d’anomalies conçus pour les données structurées ne s’adaptent pas bien à l’espace des représentations vectorielles. Le signal est bien là, mais la plupart des organisations ne sont pas équipées pour l’interpréter.
Ce qu’exige la résilience dans ce contexte : une surveillance continue de l’intégrité des bases de données vectorielles, et pas seulement des sauvegardes. Des représentations vectorielles soumises à un contrôle de version avec une chaîne de traçabilité vérifiable. La capacité d’identifier, à tout moment, le contenu exact de la couche mémoire – et de restaurer un état vérifié et propre, et pas seulement un état récent.
Couche 2 : Contrôle à l’exécution – Lorsque le flux de travail constitue une menace
L’IA agentique n’exécute pas de scripts prédéfinis. Elle planifie. Au moment de l’exécution, un agent reçoit un objectif, détermine les étapes nécessaires pour l’atteindre, sélectionne les outils dont il a besoin, puis passe à l’action – en créant souvent des sous-agents pour gérer des flux de travail parallèles. Le flux de travail est dynamique, construit à la volée et s’étend souvent sur une longue durée.
C’est ce qui rend l’IA agentique véritablement utile. C’est aussi ce qui rend sa protection véritablement difficile. Dans un environnement d’automatisation classique, un flux de travail « compromis » est limité. Il exécute les tâches pour lesquelles il a été configuré, puis s’arrête. Un flux de travail « agentique » compromis est différent : il s’adapte.
Si un attaquant parvient à influencer la couche de planification – par le biais d’une invite piégée, d’une réponse manipulée d’un outil ou d’un modèle de planification corrompu –, l’agent poursuivra l’objectif de l’attaquant en utilisant tous les outils et accès légitimes dont il dispose. Cela ressemblera à un fonctionnement normal. Les journaux, dans la mesure où ils existent, feront état d’appels d’outils autorisés. Prenons l’exemple d’un agent des achats chargé de valider les factures des fournisseurs au regard des clauses contractuelles. En fonctionnement normal, il vérifie les montants des factures, recoupe les seuils d’approbation et signale les exceptions pour qu’elles soient examinées par un humain. Un attaquant capable d’influencer la couche de planification – en manipulant la réponse d’un outil issue de la base de données des contrats – n’a pas besoin d’intervenir directement sur la logique d’approbation. Il lui suffit de fournir à l’agent un enregistrement de contrat dont les seuils ont été modifiés. L’agent planifie correctement à partir de données d’entrée corrompues. Chaque appel d’outil qu’il effectue est légitime. Chaque décision qu’il prend est erronée. Au moment où l’anomalie apparaît lors d’un rapprochement comptable, le workflow a déjà traité plusieurs semaines de factures et la piste d’audit ne fait état que d’actions autorisées.
Dans ces scénarios, le délai entre la compromission et la détection ne se mesure pas en secondes. Les workflows basés sur des agents fonctionnent en continu. Au moment où des résultats anormaux apparaissent, le workflow a peut-être déjà interagi avec des dizaines de systèmes, pris des centaines de décisions et laissé des modifications dans les environnements de production qui sont difficiles à recenser et encore plus difficiles à annuler.
Ce qu’exige la résilience dans ce cas : une surveillance en temps réel qui observe ce que les agents décident, et pas seulement ce qu’ils font. Des mécanismes d’intervention capables d’arrêter proprement un workflow en cours d’exécution sans provoquer de défaillances en cascade. Des guides de Recovery conçus pour les processus basés sur des agents de longue durée – et pas seulement pour des transactions ponctuelles.
Couche 3 : Observabilité agentique – Le déficit de journalisation à la vitesse des machines
L’infrastructure de journalisation d’entreprise a été conçue pour des opérations à l’échelle humaine. Elle enregistre les activités des systèmes avec un niveau de détail et une latence adaptés à une analyse humaine. L’IA agentique fonctionne à une vitesse tout à fait différente.
Dans un déploiement multi-agents actif, les agents créent des sous-agents, se transmettent le contexte entre eux, invoquent des outils et synthétisent des résultats – de manière continue, en parallèle, à un rythme plus rapide que celui pour lequel les pipelines de journalisation classiques ont été conçus. Les interactions qui revêtent la plus grande importance pour la sécurité – les communications entre agents, les transferts de contexte, les appels d’outils qui franchissent les frontières de confiance – sont précisément celles que les cadres de surveillance existants négligent le plus.
Aujourd’hui, seules 17 % des entreprises surveillent en permanence les interactions entre agents. Les 83 % restants gèrent l’IA agentique en se basant sur une vision partielle : celle-ci rend compte des actions menées par chaque agent pris isolément, mais passe à côté de la couche d’interaction où se produisent les événements de sécurité les plus graves.
Il ne s’agit pas d’une lacune que l’on peut combler en augmentant le volume des données d’audit. Le problème ne réside pas dans la quantité de données collectées, mais dans le fait que les structures de données et les exigences en matière de latence des interactions entre agents ne s’intègrent pas bien dans les frameworks d’observabilité conçus pour des systèmes plus lents et plus structurés. Pour combler cette lacune, il faut soit disposer d’outils d’observabilité au niveau des agents spécialement conçus à cet effet, soit procéder à une adaptation en profondeur de l’infrastructure existante.
Ce qu’exige la résilience dans ce contexte : une visibilité de bout en bout sur les interactions entre agents, et pas seulement sur les résultats individuels de chaque agent. Des architectures de journalisation capables de fonctionner à la vitesse des agents sans perdre d’événements. La capacité de reconstituer a posteriori la séquence complète des décisions et des interactions des agents pour un flux de travail donné.
Couche 4 : Coordination multi-agents – Où se cachent les défaillances émergentes
Le risque le plus novateur sur le plan architectural dans le domaine de l’IA agentique ne provient pas d’un agent compromis en particulier. Il tient à la manière dont les agents dépendent les uns des autres – et à la façon dont les défaillances se propagent à travers ces dépendances avant que quiconque ne se rende compte qu’il y a un problème. Dans une architecture multi-agents, les agents partagent un contexte commun. Un agent orchestrateur transmet un cahier des charges à un sous-agent ; ce dernier renvoie un résultat que l’agent orchestrateur intègre dans sa décision suivante.
Si la sortie du sous-agent est corrompue – que ce soit en raison d’une couche mémoire compromise, d’une réponse d’outil manipulée ou d’un modèle de planification corrompu –, l’orchestrateur ne dispose d’aucun moyen natif pour la détecter. Il considère cette sortie comme faisant autorité. Il l’intègre. Il agit en conséquence. Et il transmet en aval sa propre sortie, désormais compromise.
Il s’agit là d’un mode de défaillance émergent : une corruption qui prend naissance dans une couche, se propage à travers les interactions entre agents et se manifeste sous la forme d’un résultat anormal dans un système situé à plusieurs étapes de la compromission initiale. Au moment où elle devient visible, la chaîne causale est longue et la portée considérable.
Imaginons un pipeline de renseignements sur les menaces dans lequel un agent de collecte de données ingère des flux provenant de sources externes, un agent de classification les catégorise et leur attribue une note, et un orchestrateur intègre ces renseignements notés dans des recommandations relatives à la posture de sécurité transmises aux équipes en aval. Si la couche mémoire de l’agent de collecte de données est compromise – de manière subtile, par l’injection d’embeddings qui l’amènent à considérer certains acteurs malveillants comme présentant un faible risque –, l’agent de classification reçoit des données qu’il n’a aucune raison de remettre en question. Il effectue une classification précise sur la base des informations qui lui sont fournies.
L’orchestrateur intègre les résultats en toute confiance. Les équipes de sécurité en aval relèguent au second plan la catégorie de menace concernée, en se fondant sur ce qui semble être un consensus cohérent issu de plusieurs sources. La défaillance a pris naissance au niveau de la couche 1. Elle s’est manifestée au niveau de la couche 4. Aucun élément intermédiaire n’a signalé d’anomalie, car aucun élément intermédiaire ne disposait d’une visibilité sur l’ensemble de la chaîne.
Les cadres de gouvernance que la plupart des entreprises appliquent à l’IA ont été conçus pour les résultats des modèles – c’est-à-dire ce que dit l’IA. Les défaillances de coordination entre plusieurs agents ne sont pas des défaillances des résultats des modèles. Il s’agit de défaillances systémiques, découlant de la couche d’interaction entre les modèles, qui nécessitent un autre type de gouvernance : une gouvernance qui surveille et contrôle non seulement le comportement de chaque agent, mais aussi les relations de confiance entre les agents, l’intégrité du contexte lors de son transfert entre eux, ainsi que les droits d’accès qui régissent ce qu’un agent peut demander à un autre.
Ce qu’exige ici la résilience : une gestion de l’identité des agents qui considère la confiance entre les agents comme une préoccupation de sécurité de premier ordre. Une vérification de l’intégrité du contexte à mesure qu’il traverse les frontières entre les agents. Des politiques de gouvernance qui couvrent le comportement des agents autonomes – et pas seulement les résultats des modèles individuels.
Le problème relationnel qui relie ces quatre éléments entre eux
Ces quatre couches présentent des modes de défaillance distincts, mais elles partagent une vulnérabilité commune : aucune d’entre elles ne dispose d’un registre commun indiquant comment elles s’articulent les unes par rapport aux autres à un moment donné.
Le registre des modèles sait quelle version est en cours d’exécution. La base de données vectorielle sait ce qui se trouve en mémoire. La couche d’orchestration sait quel flux de travail est actif. Le système d’identité sait quels agents disposent de quels accès. Chacun peut confirmer sa propre partie du tableau. Aucun ne peut confirmer si ces parties s’articulent entre elles – si elles reflètent le même état opérationnel, le même instant, la même configuration fiable.
C’est là que réside le fossé contextuel. Et c’est pourquoi la reprise après une compromission par une IA agentique n’est pas un problème de restauration des données. Il s’agit d’un problème de cohérence – un problème qui nécessite un enregistrement unifié des relations entre les couches, et pas seulement des composants eux-mêmes. Comblez cette lacune avant qu’un incident ne se produise, ou passez le temps nécessaire à essayer de la combler une fois l’incident survenu.
Les défis architecturaux abordés ici ne constituent qu’une partie de ce que les responsables de la sécurité et de la résilience doivent comprendre au sujet des risques liés à l’IA agentique. « L’angle mort de l’IA agentique : pourquoi la résilience de l’IA exige un système d’enregistrement
» va plus loin en examinant où en sont réellement la plupart des entreprises en matière de préparation à la résilience de l’IA, à quoi ressemblent concrètement les lacunes de gouvernance, et ce qu’il faut pour que l’affirmation « notre IA est fiable » devienne une réalité démontrable, et non une simple déclaration.
FAQ
Q : Pourquoi la reprise après sinistre traditionnelle ne fonctionne-t-elle pas pour l’IA agentique ?
R : Les procédures de restauration traditionnelles partent du principe que les systèmes sont sans état et peuvent être restaurés à partir de sauvegardes « propres ». Les systèmes d’IA agentique conservent leur mémoire, évoluent au fil du temps et reposent sur des interactions à plusieurs niveaux, ce qui rend une simple restauration insuffisante pour rétablir la confiance.
Q : Qu’est-ce qui rend la couche mémoire de l’IA agentique vulnérable ?
R : La couche mémoire stocke les représentations et les données contextuelles qui influencent les décisions de l’agent. Si elle est compromise, les attaquants peuvent subtilement manipuler ce que « croit » l’agent, ce qui conduit à des actions erronées mais apparemment légitimes.
Q : Comment les pirates peuvent-ils exploiter les flux de travail d’exécution dans l’IA agentique ?
R : Les attaquants peuvent influencer les données d’entrée de planification, les invites ou les réponses des outils, ce qui conduit les agents à exécuter des actions malveillantes en utilisant des processus légitimes. Ces actions apparaissent souvent comme normales dans les journaux, ce qui rend leur détection difficile.
Q : Pourquoi l’observabilité constitue-t-elle un défi dans les systèmes multi-agents ?
R : Les systèmes basés sur des agents fonctionnent à la vitesse de la machine et impliquent des interactions continues entre les agents. Les systèmes de journalisation traditionnels ne sont pas conçus pour capturer ni traiter ce niveau d’activité dynamique et à haute fréquence.
Q : Qu’entend-on par « défaillances émergentes » dans les environnements multi-agents ?
R : Les défaillances émergentes surviennent lorsqu’une petite défaillance au niveau d’un agent ou d’une couche se propage à l’ensemble des agents interconnectés, entraînant des problèmes à grande échelle dont il est difficile de remonter à la source d’origine.
Q : À quoi ressemble une restauration efficace pour une IA agentique ?
R : Une restauration efficace ne se limite pas à la récupération des données : elle nécessite un instantané cohérent de toutes les couches du système, y compris la mémoire, les flux de travail, les identités et les interactions, aligné sur un état vérifié et fiable.
Tim Zonca est vice-président chargé de la gestion de portefeuille chez Commvault.
