Mark - stock.adobe.com
Le tiercé létal de l'IA agentique : ce que les RSSI doivent savoir
Les capacités mêmes qui rendent un agent IA utile le rendent également dangereux. Voici ce que les RSSI doivent savoir sur le tiercé létal de l'IA agentique, et ce qu'ils doivent faire à ce sujet.
À ce jour, chaque RSSI a probablement entendu parler du tiercé létal circuler dans des discussions sur la sécurité de l'IA. Ce terme fait référence à une combinaison de trois propriétés de l'IA agentique qui, ensemble, rendent les agents vulnérables aux attaques et exposent les entreprises qui les utilisent à des risques massifs.
Le programmeur Simon Willison est crédité d'avoir inventé le terme lethal trifecta en relation avec l'IA agentique. Malheureusement, le domaine de la cybersécurité n'a pas encore de définition universelle : différents analystes en cybersécurité et chercheurs en IA choisissent souvent des trios de propriétés différents. Et, bien sûr, il n'est pas nécessaire de s'arrêter à trois.
Ceci étant dit, les discussions sur le tiercé létal de l'IA agentique se concentrent souvent sur les trois propriétés suivantes, telles que décrites initialement par Willison :
- L'accès de l'agent à des informations privées ou sensibles, qu'il s'agisse d'informations personnelles sur le personnel ou les clients ou de propriété intellectuelle confidentielle.
- L'ingestion de contenu non contrôlé par l'agent. C'est-à-dire avoir un agent qui lit des données provenant de sources que l'entreprise ne contrôle pas, telles que des sites web publics, et qui peuvent contenir soit des informations intentionnellement incorrectes - destinées à affecter les décisions de l'entreprise ou de l'agent - soit des invites cachées destinées à rediriger les objectifs ou les actions de l'agent.
- La capacité de l'agent à communiquer à l'extérieur, et donc à exfiltrer des données.
Alternativement, certains experts en cybersécurité incluent les propriétés suivantes dans le tiercé létal de l'IA agentique :
- L'habilitation de l'agent à agir de manière à affecter d'autres systèmes d'entreprise - par exemple, reconfigurer des équipements réseau ou modifier des bases de données.
- La capacité de l'agent à planifier et à poursuivre de manière adaptative des objectifs à long terme sans confirmation de l'objectif par un humain. L'adaptabilité inclut la capacité d'exploiter des chaînes de vulnérabilités de faible impact - par exemple, des CVE avec de faibles scores CVSS - pour atteindre des résultats à fort impact, tels qu'un accès de niveau root à un serveur clé.
- La capacité de l'agent à s'améliorer et à acquérir des capacités - par exemple, modifier son propre code ; modifier ses propres objectifs ; trouver d'autres outils pour combler ses lacunes fonctionnelles ; ou concevoir de meilleurs modèles, puis créer et utiliser des outils basés sur ceux-ci.
- La vélocité agentique, ou la capacité de submerger les mécanismes de gouvernance à échelle humaine.
- La dérive d'invite agentique (agentic prompt drift) - c'est-à-dire le non-déterminisme de l'agent. Les agents et autres IA peuvent produire des résultats radicalement différents en réponse à la même invite - et en effet, de nombreuses attaques de jailbreak reposent là-dessus pour amener une IA à se libérer de son entraînement d'alignement.
- L'indétermination des coûts de l'agent. Les coûts réels d'une IA, en termes de jetons dépensés, peuvent dériver de manière imprévisible en raison de facteurs tels que la dérive d'invite et la « pourriture de contexte » (context rot), qui la pousse dans des boucles récursives de relecture des mêmes données de contexte.
- Les agents dotés d'une persuasion surhumaine peuvent mener des attaques d'ingénierie sociale lentes et sophistiquées à des échelles auparavant impossibles.
Choisissez n'importe quel sous-ensemble de ces problèmes, et l'idée centrale est la même : l'IA ajoutée à l'agentivité ajoutée à la permission d'agir dans l'environnement de l'entreprise se combinent pour former une synergie risquée aux conséquences potentiellement catastrophiques.
Pourquoi les RSSI doivent prêter attention
L'IA agentique introduit une nouvelle catégorie de cybermenaces - une catégorie qui peut exploiter toutes les autres catégories de menaces existantes. Un agent disposant d'un accès aux données, d'une connectivité externe et de la capacité d'agir de manière autonome pourrait reconfigurer des systèmes, exfiltrer des données sensibles et plus encore, ce qui en fait à la fois une menace interne significative et un vecteur d'attaque pour les acteurs malveillants externes.
Les outils de sécurité traditionnels ne peuvent pas résoudre les problèmes potentiels créés par l'IA agentique ; par exemple, les pare-feu d'applications web traditionnels ne peuvent pas prévenir les attaques par injection de prompt. Les organisations doivent mettre à jour leurs architectures pour intégrer correctement les nouvelles catégories d'outils de sécurité de l'IA agentique, ainsi que les politiques qui régissent l'utilisation acceptable de l'IA agentique et la réponse aux incidents. Quelle que soit la manière dont une organisation définit le tiercé létal, le RSSI doit coordonner et piloter la réponse en matière de sécurité et de gouvernance.
Comment évaluer votre exposition au risque
En tant que RSSI évaluant le risque de tiercé létal de votre organisation, posez-vous les questions clés suivantes :
- Quel niveau d'accès les agents IA ont-ils aux logiciels d'entreprise de base tels qu'un CRM ?
- Quel niveau d'accès les agents IA ont-ils aux données de l'entreprise ?
- Quel niveau d'accès les agents IA ont-ils à l'infrastructure de l'entreprise - comme l'infrastructure réseau - et aux services - comme un environnement IaaS ou le service DNS ?
- Quel niveau d'accès les agents ont-ils à Internet ?
- Quel niveau d'accès les entités externes ont-elles aux systèmes de l'environnement, y compris les agents IA - par exemple, via des services Model Context Protocol (MCP) ?
Les réponses révèlent la portée des agents IA dans l'entreprise - y compris ceux qui entrent via MCP de l'extérieur de l'organisation - et établissent la portée de base du risque. L'incapacité à répondre à ces questions avec confiance signale un risque important en soi.
Stratégies d'atténuation
La meilleure stratégie pour atténuer le risque lié à l'IA agentique est, comme c'est souvent le cas, la mise en œuvre d'une architecture zéro confiance. Infusez l'infrastructure IA avec les principes fondamentaux du sans confiance, en limitant strictement l'accès aux systèmes et aux données en fonction de l'identité et des listes d'autorisation. Au minimum, cela impliquera ce qui suit :
- L'ajout de la gestion d'identité pour les agents IA, soit en déployant un nouveau système de gestion d'identité spécifiquement pour les agents, soit en étendant un système existant capable de répondre aux objectifs requis en matière d'échelle et de vitesse. Un logiciel gérant l'identité pour les conteneurs Kubernetes pourrait servir, par exemple.
- Le canalisation des communications des agents IA et vers les agents IA via des passerelles MCP ou similaires, afin de fournir des points de contrôle pour autoriser ou refuser l'accès et pour surveiller le comportement.
- L'adoption d'un niveau d'accès par défaut « refuser tout » (deny all) puis l'autorisation d'entités spécifiques d'effectuer des actions spécifiques, si nécessaire.
- L'extension de la boîte à outils pour inclure des pare-feu sémantiques qui détectent les injections d'invite, les tentatives d'hypnose, etc. ; des systèmes de gestion d'accès « dépendants du chemin » (path-dependent) qui évaluent les invites entrantes et sortantes en fonction du contexte des invites passées, et qui surveillent les schémas d'attaque lents et subtils ; et enfin la surveillance de la dérive des modèles.
Enfin, la surveillance des menaces comportementales pour détecter et interrompre les schémas de comportement agentique risqués - par exemple, peut permettre de révoquer l'accès d'un agent à une base de données clé s'il tente de manière répétée d'effectuer des opérations sur cette base de données pour laquelle il n'a pas la permission.
John Burke est CTO et analyste de recherche chez Nemertes Research. Burke a rejoint Nemertes en 2005 avec près de deux décennies d'expérience technologique. Il a travaillé à tous les niveaux de l'informatique, y compris comme spécialiste du support utilisateur final, programmeur, administrateur système, spécialiste de bases de données, administrateur réseau, architecte réseau et architecte de systèmes.
