Les quatre vecteurs d’attaque contre lesquels votre infrastructure de sécurité IA n’est pas préparée

Points clés à retenir

• L’IA agentique engendre de nouveaux risques de sécurité, car elle planifie, mémorise et agit sur l’ensemble des systèmes, au lieu de s’arrêter après un seul cycle « invitation-réponse ».
• Des données d’entraînement « empoisonnées » peuvent influencer discrètement le comportement d’un modèle à grande échelle, même lorsque celui-ci semble encore fonctionner normalement lors des tests standard.
• Des bases de données de vecteurs compromises peuvent influencer les décisions des agents en faussant le contexte sur lequel repose le modèle, ce qui donne l’impression que des comportements inappropriés sont légitimes.
• L’identité des agents non gérés pose un problème de contrôle d’accès à la vitesse des machines que les systèmes d’identité traditionnels, centrés sur l’humain, ne sont pas conçus pour gérer.
• Des décisions en cascade fondées sur un état erroné peuvent propager la corruption à plusieurs agents et flux de travail, ce qui complique considérablement la restauration et la reprise.

Les outils, contrôles et politiques de gouvernance mis en place par la plupart des entreprises ont été conçus pour des systèmes qui répondent à des questions : outils de recherche, copilotes, assistants génératifs. Des systèmes qui réagissent à une requête, puis s’arrêtent. Lorsqu’un problème survenait, la défaillance était isolée. Il suffisait de corriger la requête, d’ajuster la configuration, puis de passer à autre chose.

L’IA agentique ne fonctionne pas ainsi. Ces systèmes planifient, mémorisent et exécutent des actions à l’échelle de l’entreprise sans instruction humaine étape par étape. Ils conservent un état. Ils se coordonnent avec d’autres agents. Ils agissent sur les systèmes de production : ils écrivent dans des bases de données, déclenchent des workflows, prennent des décisions à la vitesse d’une machine. Cette évolution architecturale introduit quatre vecteurs de menace auxquels les dispositifs de sécurité existants n’ont jamais été conçus pour faire face. Si votre stratégie de gouvernance de l’IA n’en tient pas compte, vous êtes probablement exposé à des risques que vous ne pouvez sans doute pas détecter.

1. Données d’entraînement « empoisonnées »

La fiabilité d’un système d’IA dépend entièrement de la qualité des données sur lesquelles il a été entraîné. Cette affirmation a toujours été vraie. Ce qui a changé, c’est la surface d’attaque.

Dans les déploiements d’IA agentique, les pipelines d’entraînement sont plus volumineux, plus complexes et souvent constitués à partir de multiples sources : données internes, flux tiers, ensembles de données fournis par des prestataires. Chaque maillon de cette chaîne constitue un point d’injection potentiel. Un acteur malveillant capable d’influencer les données d’entraînement – par le biais d’une compromission de la chaîne d’approvisionnement, d’un accès privilégié ou de la contamination d’une source de données partagée – peut modeler le comportement du modèle à grande échelle. Ce qui rend cette situation particulièrement dangereuse, c’est que les modèles empoisonnés affichent souvent des performances normales lors des tests de performance standard. La manipulation peut être d’une précision chirurgicale : conçue pour produire des résultats spécifiques dans des contextes précis, tout en se comportant correctement dans toutes les autres situations.

Au moment où le problème se manifeste en production, le modèle est déjà utilisé depuis des semaines, voire des mois, et remonter à la source de la contamination nécessite précisément le type de traçabilité relationnelle des données dont la plupart des organisations ne disposent pas. La question à se poser est la suivante : êtes-vous en mesure de fournir un historique complet et vérifiable des données sur lesquelles vos modèles ont été entraînés, à un moment précis ?

2. Bases de données vectorielles compromises

Les bases de données vectorielles constituent la couche mémoire des systèmes agentiels. Avant d’agir, un agent interroge un magasin de vecteurs afin d’extraire le contexte pertinent (interactions passées, connaissances du domaine, données de référence) qui détermine la suite de ses actions. La plupart des équipes de sécurité ne considèrent pas les bases de données vectorielles de la même manière qu’elles considèrent les autres bases de données contenant des informations sensibles. Elles devraient pourtant le faire. Une base de données vectorielle compromise ne se contente pas de renvoyer des réponses erronées. Elle influence les décisions qui s’ensuivent. Des embeddings injectés – du contenu malveillant inséré dans le magasin de vecteurs – peuvent rediriger le comportement de l’agent d’une manière qui semble tout à fait légitime vue de l’extérieur.

Un agent chargé d’approuver une transaction récupère un contexte qui redéfinit subtilement les critères d’approbation. Un agent gérant les communications avec les clients extrait un contexte qui oriente les réponses dans la direction souhaitée par l’attaquant. L’action semble correcte. Le raisonnement semble solide. Mais le contexte sous-jacent a été manipulé.

Ce vecteur d’attaque est particulièrement difficile à détecter car il opère en dessous de la couche du modèle. Une surveillance standard du modèle ne le détectera pas. Le modèle se comporte exactement comme il a été entraîné – c’est le contexte à partir duquel il raisonne qui a été corrompu. La question à se poser est la suivante : votre base de données vectorielle est-elle considérée comme un actif de données sensible et soumise à des règles de gouvernance, avec des contrôles d’accès, une surveillance de l’intégrité et une journalisation des audits comparables à ceux de vos bases de données de production les plus critiques ?

3. Identité d’un agent non régi

Dans une architecture multi-agents, les agents n’interagissent pas seulement avec des données : ils interagissent entre eux. Ils créent des sous-agents, délèguent des tâches, demandent des résultats et synthétisent les résultats provenant d’agents auxquels ils n’ont jamais été explicitement connectés. Pour ce faire, ils s’authentifient, présentent leurs identifiants et établissent une relation de confiance.

L’identité des agents constitue la couche de contrôle d’accès de l’entreprise autonome – et il s’agit là d’une lacune que ni les fournisseurs de solutions de sécurité des identités ni les fournisseurs d’identité (IDP) ne comblent. Leurs cadres de gouvernance sont conçus pour l’identité humaine.

Les identités d’agents créées selon ces mêmes règles semblent tout à fait légitimes : elles ont été correctement provisionnées et respectent la politique en vigueur. L’IDP ne présente pas de défaillance ; il ne dispose tout simplement pas d’un cadre permettant de déterminer si un agent agit en dehors du contexte pour lequel il a été créé, s’il a bénéficié d’une élévation de privilèges à l’insu de tous, ou s’il coordonne des actions là où il ne devrait pas.

Cette faille présente une nature qualitativement différente de celle des compromissions classiques d’identifiants. Lorsqu’un utilisateur humain se fait voler ses identifiants, le pirate agit dans les limites des autorisations de cet utilisateur, à la vitesse d’un être humain. Lorsque l’identité d’un agent est compromise, l’attaquant accède à la couche de prise de décision autonome : il peut ainsi déclencher des flux de travail, approuver des actions, se coordonner avec d’autres agents et exfiltrer des données à la vitesse de l’ordinateur, à grande échelle, par le biais de canaux qui semblent tout à fait normaux.

Les failles au niveau de la couche d’identité comptent également parmi les plus difficiles à détecter a posteriori. Les actions d’un agent effectuées sous une identité compromise ne semblent pas anormales : elles ressemblent à un comportement légitime de l’agent. Et comme elles sont générées par un système plutôt que par un humain, leur volume peut atteindre des proportions énormes avant que quiconque ne s’en aperçoive.

La récupération (Recovery) aggrave le problème. La plupart des guides de récupération en matière d’IA se concentrent sur la restauration des données : ensembles d’entraînement, poids des modèles, configurations des pipelines. L’identité figure rarement sur la liste. Un système restauré avec des données saines mais dont les configurations d’identité sont mal alignées n’est en réalité pas restauré. Il s’agit d’un système sain doté d’une couche d’accès corrompue. La question à se poser est la suivante : l’identité des agents est-elle gérée avec la même rigueur que celle des personnes, c’est-à-dire avec une gestion du cycle de vie, un accès selon le principe du moindre privilège et une intégration dans les plans de reprise ?

4. Une succession de décisions fondées sur une analyse erronée de la situation

Les trois premiers vecteurs d’attaque sont ponctuels. Celui-ci, en revanche, est systémique – et, à bien des égards, il peut s’avérer le plus difficile à maîtriser. Les architectures multi-agents sont conçues pour la coordination. Les agents partagent le contexte, se transmettent mutuellement leurs résultats et s’appuient sur le travail les uns des autres. C’est cette coordination qui fait leur puissance. C’est aussi ce qui provoque la propagation des défaillances.

Un agent fonctionnant sur une mémoire corrompue ne tombe pas en panne de manière isolée. Il produit des résultats – décisions, actions, données – que d’autres agents exploitent. Ces agents produisent à leur tour leurs propres résultats. Au moment où la corruption initiale devient observable, l’état défectueux peut avoir affecté des dizaines de processus en aval, impliquant plusieurs agents, sans qu’il soit possible de remonter clairement la chaîne.

C’est ce qui rend le décalage contextuel si important. À tout moment, votre système d’IA se compose d’une version de modèle, d’un ensemble de données d’apprentissage, d’un référentiel d’artefacts, d’une configuration de pipeline et d’un ensemble d’interactions d’agents actifs – qui doivent tous refléter le même état opérationnel pour constituer un système fiable et récupérable. Lorsque ce n’est pas le cas, il ne s’agit pas simplement d’une erreur. Vous disposez d’un système cohérent par fragments, mais incohérent dans son ensemble. Chaque outil ponctuel peut valider sa propre tranche d’informations. Aucun ne peut confirmer que ces éléments s’articulent entre eux. Il ne s’agit pas d’un problème de surveillance que l’on peut résoudre en ajoutant un outil supplémentaire. Il s’agit d’une lacune structurelle – et la seule façon de la combler est de mettre en place un système qui capture l’état de l’IA de manière relationnelle : ce qui était en cours d’exécution, sur quelles données, avec quelle configuration, à quel moment.

La question à se poser est la suivante : si votre infrastructure d’IA venait à être compromise aujourd’hui, seriez-vous en mesure d’identifier avec précision l’état de chaque composant avant l’incident – et de le prouver ?

Ce que cela implique pour votre stratégie de sécurité

Chacun de ces quatre vecteurs nécessite une réponse défensive différente. Mais ils ont tous une conséquence commune : les cadres de gouvernance et de résilience conçus pour l’ère précédente de l’IA ne couvrent pas les modes de défaillance propres à l’ère des agents. Pour garantir la sécurité d’une IA agentique, il faut étendre votre cadre de travail dans trois directions :

• Plus en profondeur, au cœur des couches de données et d’identité qui se trouvent sous le modèle.
• Plus largement, afin de couvrir les interactions entre agents qui échappent aux systèmes de surveillance existants.
• D’un point de vue relationnel, il s’agit de saisir non seulement l’état de chaque composant, mais aussi la manière dont ils s’articulent entre eux à un moment donné.

C’est cette dernière exigence que la plupart des organisations n’ont pas encore prise en compte. Et c’est elle qui déterminera si, en cas de problème, vous disposez d’un système capable de se rétablir ou d’un ensemble de rapports en apparence fiables décrivant quelque chose qui n’existe plus. Lisez l’article « The Agentic Blind Spot : Why AI Resilience Demands a System of Record » pour découvrir pourquoi vous avez besoin d’un système d’enregistrement (SOR) afin de garantir la cohérence et l’exactitude de vos données d’IA.

FAQ

Q : Pourquoi les systèmes d’IA agentique présentent-ils plus de risques que les outils d’IA générative traditionnels ?

R : Les systèmes basés sur des agents ne se contentent pas de répondre à des invites. Ils gèrent l’état du système, coordonnent leurs actions avec d’autres agents et effectuent des opérations dans des environnements de production, ce qui élargit considérablement la surface d’attaque bien au-delà de la simple manipulation d’invites.

Q : Pourquoi les données d’entraînement « empoisonnées » sont-elles si difficiles à détecter ?

R : La manipulation peut être très ciblée, n’affectant que des situations spécifiques tout en laissant intacts les repères normaux. Cela signifie qu’un modèle peut sembler fonctionner correctement jusqu’à ce que le comportement malveillant se manifeste dans des conditions réelles d’utilisation.

Q : En quoi une base de données vectorielle peut-elle constituer un problème de sécurité ?

R : Une base de données vectorielle définit le contexte sur lequel s’appuie un agent avant d’agir. Si ce contexte est modifié, l’agent peut prendre des décisions qui semblent raisonnables à première vue, mais qui sont en réalité influencées par des données malveillantes.

Q : En quoi l’identité d’un agent diffère-t-elle de celle d’un être humain ?

R : L’identité d’un agent est liée aux actions autonomes, à la délégation et à l’exécution à la vitesse d’une machine. La gouvernance traditionnelle de l’identité étant conçue pour les personnes, elle ne permet souvent pas de détecter si un agent agit en dehors du contexte prévu.

Q : Pourquoi la propagation en cascade d’états indésirables constitue-t-elle un problème aussi grave dans les systèmes multi-agents ?

R : Dès qu’un agent utilise des données de sortie corrompues, cette erreur peut se propager aux agents et aux flux de travail en aval. Il en résulte non seulement une mauvaise décision, mais toute une chaîne d’échecs en cascade.

Q : Comment les organisations peuvent-elles renforcer la sécurité de l’IA ?

R : En étendant la gouvernance aux couches de données et d’identité, en surveillant les interactions entre les agents et en suivant l’état de l’IA de manière relationnelle afin de leur permettre de reconstituer le déroulement d’un incident.

Michael Thelander est directeur principal du marketing produit chez Commvault.

Articles de blog connexes

• • Sécuriser l’IA grâce à une gouvernance unifiée de l’accès aux données
  • Des données plus intelligentes, une IA plus écologique
  • Data Activate : exploiter le potentiel des données fiables au service de l’innovation en matière d’IA
  • Les agents IA sont partout. Savez-vous ce qu’ils font ?
  • De l’expérimentation à la mise en service : créer des agents IA auxquels on peut vraiment faire confiance