Sécurisation des LLM en production : anatomie des menaces et remparts techniques

Connaître les typologies d’attaques avant de s’en défendre

Le spécialiste cyber identifie plusieurs typologies d’attaques majeures qui redéfinissent la surface de vulnérabilité. Les attaques directes visent à forcer le modèle à enfreindre ses règles. Le détournement par jeu de rôle exploite sa propension à l’anthropomorphisme pour contourner les interdits et paramétrages.

On observe également des inversions de protocoles où l’utilisateur et l’assistant intervertissent leurs rôles, ou encore l’exploitation de la multimodalité pour dissimuler des instructions malveillantes via des images ou du son.

Plus complexes, les attaques par intégration consistent à assembler des instructions apparemment inoffensives qui, une fois réunies, « reconstituent la chaîne d’attaque ». Enfin, le simple changement de langue ou l’usage du format Base64 peut suffire à tromper les filtres de sécurité.

« Le développeur du LLM n’a pas imaginé que vous pouviez utiliser cette technique ». Ces failles deviennent critiques dès lors que l’IA gagne en autonomie et devient agentique, tout en se déployant dans des processus sensibles.

Cadrer la responsabilité et verrouiller les droits d’accès des agents

L’émergence de l’IA agentique, capable d’exécuter des commandes système, interroge également les enjeux de responsabilité. Dans l’agentique, le modèle n’est plus un simple interlocuteur. L’agent est un acteur doté d’une capacité d’action sur l’environnement de l’entreprise.

Se pose alors la question cruciale de l’imputabilité des actes. Pour la MGEN, la réponse est structurelle : « un agent ne sera jamais responsable de ses actions ». La responsabilité revient à son concepteur. Ainsi, chaque agent doit obligatoirement être rattaché à un superviseur.

Il peut s’agir d’un Product Owner (PO), assisté d’autres compétences dans l’entreprise, par exemple la DSI. Le PO est chargé de surveiller les interactions de l’agent « comme le lait sur le feu ». Il est pour cela aidé d’autres interlocuteurs en interne.

Mais la sécurité technique doit elle aussi s’adapter à l’autonomie des agents, par exemple pour éviter que l’IA n’utilise « directement internet » sans contrôle ou tout autre système non prévu. Un cadre IT de la finance préconise l’insertion d’un « code agentique » spécifique, une sorte de filtre technique qui vérifie l’innocuité des commandes avant leur exécution, notamment pour valider la qualité du code.

Sans ce verrou, un agent pourrait outrepasser ses droits via l’identité d’un utilisateur. La mise en place de « proxys intermédiaires » pourrait s’avérer nécessaire pour limiter les accès à des listes blanches rigoureuses et éviter que l’IA ne se connecte à des domaines malveillants ou d’autres applications.

L’expert SSI appelle tout particulièrement à la vigilance sur les droits d’accès et l’authentification en matière d’IA. La sécurité informatique doit à ce titre s’inscrire dans une démarche de collaboration avec les métiers et spécialistes IA pour protéger sans décourager les initiatives.

Concilier rapidité d’innovation et exigences cyber

Concilier la rapidité de l’innovation et les exigences de cybersécurité reste un défi dans les grandes organisations. Au sein d’une banque, cette synergie repose sur une double approche : AI for Cyber et Cyber for AI.

En utilisant l’IA pour renforcer leurs propres outils de défense, les équipes de sécurité acquièrent une connaissance intime des modèles. Cette compréhension leur permet de « mieux aider les métiers à développer leurs solutions ».

En plus d’étudier la manière dont l’IA transforme le paysage des cyberattaques, les équipes SSI développent leurs propres agents. Elles s’entraînent avec différents modèles et cherchent activement à les tester, voire à les « casser ». La finalité : acquérir une connaissance pratique et approfondie de leurs failles.

Tester les capacités avant tout déploiement, MCP compris

Le déploiement d’un modèle de langage sans une évaluation exhaustive de ses capacités constituerait une erreur. Le cadre IT de la finance a recours à une analogie pour souligner l’absurdité d’un déploiement précipité : « vous ne recruteriez jamais un jongleur sans l’avoir vu jongler ».

La vigilance doit porter sur le LLM, mais pas seulement. Ainsi, MCP – au-delà des éventuels problèmes liés au protocole lui-même – peut représenter une « superbe porte d’entrée » pour manipuler l’IA. L’expert SSI met en garde sur le fait que des attaquants peuvent utiliser les données transmises par ce biais pour envoyer des messages malveillants au modèle.

Dans ce cas de figure, l’attaquant mène une attaque indirecte en se servant de l’utilisateur ou de la donnée comme d’un « cheval de Troie » : l’IA va lire l’instruction cachée, la recopier bêtement, et ainsi propager l’attaque au sein du système.

Les nouvelles technologies d’IA se multiplient. Il importe que chaque nouveau modèle passe par un banc d’essai évaluant son raisonnement, la qualité du code produit et sa résistance aux hallucinations. Et l’IA peut être exploitée pour affiner les contrôles.

Ainsi, l’usage de techniques comme le LLM as a Judge permet d’automatiser l’évaluation de la pertinence des réponses et de vérifier que les garde-fous sont « adaptés à votre modèle ». Il est impératif de « tester pour chacun des nouveaux modèles toutes les nouvelles capacités » pour en définir les limites.

Le spécialiste cyber prévient que l’IA a été capable de « générer des exploits, voire pour certains d’enchaîner différentes failles ». Cette performance souligne l’urgence d’instrumenter la puissance des modèles pour qu’ils servent la cyber.

En comprenant la finesse du raisonnement d’un agent, l’entreprise peut mieux anticiper ses dérives potentielles avant toute intégration dans des socles industriels et dans des environnements sensibles comme la banque.

Miser sur le processus et des socles solides, avant l’outil

L’efficacité d’un projet d’IA repose sur la solidité de ses fondations. L’absence de socles MLOps ou LLMOps robustes peut transformer une innovation en un échec opérationnel en allongeant de manière conséquente les délais de mise en production.

Aurélien Barthe de MGEN insiste sur la nécessité de disposer de « socles très robustes et dont on maîtrise l’observabilité ». Il y voit une condition indispensable pour livrer de la valeur de manière répétable.

La qualité des données (en entrée et en sortie) constitue également un verrou de sécurité. Aucun algorithme ne peut compenser des données corrompues ou biaisées. Pour sécuriser les LLM, en termes de maîtrise opérationnelle et de SSI, le CDO appelle à un retour aux fondamentaux.

Avant de chercher une solution technologique, il est impératif de « demander au métier d’avoir un processus écrit » afin de pouvoir le challenger. L’IA ne doit pas être une solution cherchant désespérément un problème, mais un outil au service d’un besoin clairement défini.