Une simple phrase
suffit désormais à contourner les mécanismes de sécurité d'un système
d'information. Avec l'essor des grands modèles de langage (LLM) déployés dans
les applications métier, une nouvelle catégorie de vulnérabilités s'impose aux
entreprises, souvent sans qu'elles s'en sentent concernées.
Décryptage avec Gaëtan
Eleouet, Tech Lead et Directeur de la Practice Data, IA & Digital
Engineering chez Meritis.
Le risque : l’attaque
ne passe plus par le code, mais par le dialogue
Contrairement aux
failles informatiques classiques, l'attaquant n'a plus nécessairement besoin
d'exploiter une brèche technique. Une requête habilement formulée, appelée
"injection de prompt", peut suffire à pousser un LLM à contourner ses
règles de sécurité, divulguer des informations sensibles ou déclencher une
action non prévue par ses concepteurs.
Les solutions : 5
contre-mesures pour sécuriser les LLM en entreprise
• Définir un périmètre d'action strict pour le
LLM :
circonscrire précisément les fonctions, données et systèmes auxquels le modèle
peut accéder ou sur lesquels il peut agir, pour limiter l'impact d'une
éventuelle manipulation.
• Contrôler les entrées : filtrer et valider les
requêtes avant qu'elles n'atteignent le modèle, afin de détecter et bloquer les
tentatives d'injection de prompt.
• Contrôler les sorties : vérifier
systématiquement les réponses générées avant leur exploitation ou leur
diffusion, pour éviter qu'une donnée sensible ou une instruction non désirée ne
soit exécutée en aval.
• Anonymiser les données sensibles : empêcher que des
informations identifiables, qu'il s'agisse de clients, de salariés ou de
données financières, ne puissent être reconstituées ou divulguées via les
réponses du modèle.
• Surveiller l'ensemble de la chaîne
d'intégration :
tracer les interactions avec le LLM et détecter en continu les comportements
anormaux, du point d'entrée jusqu'à l'action déclenchée.
Selon Gaëtan Eleouet, Directeur
de la Practice Data, IA & Digital Engineering de Meritis : « Intégrer
un LLM dans un système d’information, c’est accepter une nouvelle forme de
responsabilité : celle de sécuriser un modèle que l’on ne maîtrise pas
entièrement. Sans ces contre-mesures, le risque n’est plus seulement technique,
il devient organisationnel, avec des conséquences qui peuvent toucher l’ensemble
de la chaîne. »
Une nouvelle grille de
lecture pour les équipes de développement
Cette nouvelle classe de risques impose de compléter la logique de sécurité informatique classique, fondée sur des règles de code étanches, par une véritable logique de gouvernance de l'IA.
Elle interroge directement le rôle des équipes de développement : jusqu'où sont-elles responsables de la sécurité d'un modèle qu'elles intègrent sans nécessairement le concevoir ?


