Cette leçon commence par une situation que la plupart des équipes de sécurité et d’informatique rencontrent désormais régulièrement. Lors d’une évaluation des risques, quelqu’un mentionne un assistant IA utilisé par le service client depuis des semaines ; celui-ci a été payé via une carte d’entreprise, sans ticket ni évaluation du fournisseur, et sans trace claire des données qui y ont été transmises. Le problème à résoudre est concret : il s’agit de maintenir la continuité opérationnelle tout en reprenant la maîtrise de l’identité, des autorisations et de la visibilité concernant l’utilisation de l’IA dans toute l’organisation.
Dans ce cours, nous traiterons les systèmes d’IA comme le reste de notre environnement de production. Chaque fonctionnalité et chaque outil d’IA génère des identités, des permissions et des flux de données qui doivent être conçus de manière délibérée et contrôlés en permanence. Notre objectif n’est pas d’établir une liste d’interdictions. Nous visons à cartographier une surface d’accès défendable et à transformer les usages « fantômes » (ou shadow AI) en solutions sécurisées et prises en charge officiellement.
Le risque ne réside pas tant dans la première requête (prompt) que dans l’enchaînement de petites décisions qui, discrètement, créent un chemin d’accès actif : copier-coller du texte interne dans une messagerie externe, ajouter une extension de navigateur aux permissions étendues ou connecter un outil d’IA à la messagerie et au système de gestion des tickets. Une fois ces étapes franchies, des données sensibles peuvent sortir du périmètre prévu, et l’organisation risque de ne plus pouvoir répondre à des questions élémentaires lors d’un incident ou d’un audit, comme savoir qui a accédé à quoi et pour quelle raison.
Nous utiliserons un modèle mental simple tout au long de ce cours. Une fonctionnalité d’IA devient un risque d’accès lorsqu’elle crée une nouvelle identité, une nouvelle décision d’autorisation ou un nouveau chemin vers un stockage de données sensibles, sans appliquer les contrôles que nous exigeons par ailleurs. Dans l’étape suivante, nous suivrons chaque point de transfert où une personne, une application, un agent ou un connecteur acquiert un nouveau moyen d’agir sur les données ou les systèmes. Analysons ensemble toute la chaîne, de la découverte initiale jusqu’à l’exposition potentielle.
Pour contrôler l’accès à l’IA, nous avons d’abord besoin d’une cartographie commune de l’existant. Un inventaire de la surface d’accès à l’IA consiste en une liste et une représentation systémique des composants capables d’effectuer des requêtes, de recevoir des données ou d’entreprendre des actions dans notre environnement via des fonctionnalités d’IA. Cet inventaire inclut les systèmes officiels que nous avons développés, les copilotes tiers que nous avons activés et les outils « fantômes » (shadow IT) adoptés par les utilisateurs pour respecter des délais impératifs. Tout élément absent de cet inventaire risque de se voir accorder des privilèges excessifs ; il devient alors impossible à auditer et difficile à examiner ultérieurement en cas d’enquête.
Lorsque nous cartographions un flux de travail intégrant l’IA, nous recherchons certains types de composants récurrents. Nous continuerons à utiliser ces mêmes catégories dans les leçons suivantes, lorsque nous définirons la portée du principe du moindre privilège et mettrons en place la surveillance. Voici le schéma du système que nous utiliserons pour notre prochain exercice. Consultez-le et repérez les points où l’identité est établie et où les autorisations sont appliquées.