Comment empêcher la « triple menace mortelle » de l’IA

• Les LLM présentent un problème structurel qui les empêche de séparer le code et les données, ce qui les rend vulnérables aux attaques par prompt injection
• En particulier, lorsque l’on réunit l’accès à des données externes, la consultation de secrets internes et l’autorisation de communiquer avec l’extérieur, on crée ce qu’on appelle la triple menace mortelle (lethal trifecta), susceptible d’entraîner des dommages graves
• Les ingénieurs IA doivent penser comme des ingénieurs mécaniciens : au lieu d’une approche déterministe, ils doivent accepter l’incertitude des systèmes probabilistes et prévoir des marges de sécurité
• De la même façon que les ingénieurs de l’époque victorienne surdimensionnaient leurs ouvrages pour tenir compte de l’incertitude sur les matériaux, les systèmes d’IA doivent eux aussi intégrer des limites de sécurité, une tolérance au risque et des taux d’erreur
• Comme les ponts du monde physique ont des limites de charge, le moment est venu d’imposer aux systèmes d’IA des règles explicites de limites et de marges de sécurité

---

Le problème de sécurité intrinsèque des LLM

• Les grands modèles de langage présentent un défaut structurel : ils sont incapables de séparer le code et les données
• Ils sont donc vulnérables aux attaques par prompt injection
  • Elles consistent à tromper le système pour qu’il suive des instructions qu’il ne devrait pas suivre
  • Dans certains cas, cela produit simplement des résultats embarrassants, comme faire parler un agent de support client comme un pirate
  • Dans d’autres, les dégâts peuvent être bien plus destructeurs

La triple menace mortelle (Lethal Trifecta)

• Les conséquences les plus graves apparaissent lorsque l’on réunit les « trois éléments mortels »
• Ces trois éléments sont :
  • l’accès à des données non fiables
  • la capacité à lire des informations confidentielles importantes
  • la capacité à communiquer avec le monde extérieur
• Lorsqu’une entreprise veut fournir à ses employés un assistant IA puissant et lui accorde simultanément ces trois capacités, de graves problèmes deviennent inévitables
• Non seulement les ingénieurs IA, mais aussi les utilisateurs ordinaires doivent apprendre à utiliser l’IA en toute sécurité
  • Installer une mauvaise combinaison d’applications peut créer accidentellement ces trois éléments

Changer la façon de penser des ingénieurs IA

Penser comme des ingénieurs mécaniciens

• Une meilleure ingénierie de l’IA constitue la première ligne de défense
• Les ingénieurs IA doivent raisonner comme ceux qui conçoivent des structures telles que des ponts
  • en gardant à l’esprit qu’un travail mal fait peut coûter des vies

La leçon de l’ingénierie victorienne

• Les grands ouvrages de l’Angleterre victorienne ont été construits par des ingénieurs qui ne pouvaient pas être sûrs des propriétés des matériaux
  • À l’époque, le fer était souvent de mauvaise qualité à cause de l’incompétence ou de la fraude
  • Les ingénieurs ont donc choisi la prudence et intégré de la redondance par surdimensionnement
  • Le résultat : des chefs-d’œuvre qui ont traversé les siècles

Le problème actuel du secteur de la sécurité IA

• Les fournisseurs de sécurité IA ne raisonnent pas de cette manière
• Le développement logiciel classique suit une logique déterministe
  • Une faille de sécurité est considérée comme un bug à corriger
  • Une fois corrigée, elle disparaît
• Les ingénieurs IA sont formés à cette façon de penser depuis leurs études
  • ils agissent donc comme si davantage de données d’entraînement et des system prompts plus astucieux suffisaient à résoudre le problème

Une approche adaptée aux systèmes probabilistes

Les limites des données d’entraînement et des prompts

• Les données d’entraînement et des prompts plus intelligents réduisent bien le risque
  • les modèles les plus avancés et les plus performants détectent et refusent mieux les requêtes malveillantes que les modèles plus anciens ou plus petits
• Mais ils ne peuvent pas éliminer complètement le risque
  • contrairement à la plupart des logiciels, les LLM sont probabilistes
  • la sortie est déterminée par une sélection aléatoire parmi des réponses possibles
  • une approche de sécurité déterministe est donc inadaptée

S’inspirer de l’ingénierie du monde physique

• Une meilleure méthode consiste à imiter les ingénieurs du monde physique
• Il faut apprendre à travailler avec des systèmes imprévisibles
  • non pas lutter contre des systèmes capricieux dont on ne peut garantir qu’ils fonctionneront comme prévu, mais travailler avec eux
• Il faut mieux gérer cette imprévisibilité en introduisant des marges de sécurité, une tolérance au risque et des taux d’erreur

Une stratégie de surdimensionnement pour l’ère de l’IA

• Utiliser des modèles plus puissants que nécessaire
  • afin de réduire le risque qu’ils soient manipulés pour adopter un comportement inapproprié
• Imposer une limite au nombre de requêtes qu’un LLM peut recevoir de sources externes
  • ajustée au niveau de risque lié aux requêtes malveillantes
• Mettre l’accent sur le fail-safe
  • si un système d’IA doit accéder à des informations confidentielles, il faut éviter de lui remettre les clés du royaume

Pourquoi il faut définir des limites de sécurité

• Dans le monde physique, les ponts ont des limites de charge
  • même si elles ne sont pas toujours clairement affichées aux conducteurs, elles existent
  • point essentiel : ces limites conservent une marge significative à l’intérieur de la capacité réelle que les calculs indiquent que le pont peut supporter
• Il est temps que le monde virtuel des systèmes d’IA adopte des principes similaires
• Concevoir des systèmes avec des limites de sécurité claires et des marges devient indispensable

[GN⁺]

Discussion Hacker News

• Lien vers l’article archivé
• C’est le deuxième article de The Economist cette semaine à mentionner la lethal trifecta. Le premier, Les systèmes d’IA ne seront jamais totalement sûrs — la « triple menace mortelle » à laquelle il faut répondre, expliquait de la façon la plus claire que j’aie vue dans les médias ce qu’est le prompt injection et pourquoi c’est dangereux. Je peux être légèrement biaisé puisque j’y suis cité, mais c’est vraiment un article à recommander aux dirigeants. En revanche, j’aime moins ce nouvel article. Il explique que le caractère non déterministe des LLM rend les failles de sécurité difficiles à corriger, et utilise donc une analogie disant qu’il faudrait les « surdimensionner » comme des ponts et prévoir des tolérances. Cela peut marcher pour un pont, mais à mon avis ce n’est pas une solution fondamentale pour des vulnérabilités de sécurité. Si un système succombe au prompt injection ne serait-ce qu’une fois sur cent, un attaquant continuera à essayer des variantes jusqu’au bout. Il suffit de bloquer un seul des éléments de la lethal trifecta (accès à des données privées, exposition à des instructions non fiables, canal d’exfiltration externe) pour que l’attaque ne puisse pas aboutir
  • Les constructeurs de ponts ne conçoivent généralement pas leurs ouvrages pour résister à des attaques adversariales. Et même lorsqu’ils le font, ils se concentrent davantage sur la facilité de déplacement et de redéploiement rapide que sur une robustesse extrême. Il est souvent plus rapide et moins coûteux de poser un pont temporaire supplémentaire que de bâtir un pont ultra-solide capable de survivre à des bombardements. Voir cet exemple concret
  • Les LLM, comme les humains, sont non déterministes. Il faut donc aborder leur gestion de la sécurité comme on le ferait pour des humains. Il faut leur donner le strict minimum via un contrôle d’accès basé sur les rôles, et faire passer les actions risquées ou coûteuses par un processus d’approbation. Pour toute grande organisation dans la tech, l’infrastructure, la défense, la finance, etc., le threat modeling devrait partir du principe que des agents de gouvernements étrangers — Russie, Chine, Israël, Corée du Nord, etc. — peuvent se trouver au sein de l’équipe
  • En réalité, les deux articles ne font qu’un. Dans The Economist, il y a chaque semaine au début du numéro une série d’articles appelée « Leaders », qui résume et généralise les articles d’analyse plus approfondis du même numéro. C’est en quelque sorte une application de la pyramide inversée à l’échelle de tout le journal. Ici aussi, l’article lié joue le rôle d’un résumé de l’article de fond problématique
  • Je vois le problème de sécurité des LLM comme : « et si mon code pouvait se faire manipuler par des attaques d’ingénierie sociale ? » Les LLM, comme les humains, finiront forcément par se faire tromper, quel que soit leur entraînement. Si on donne les droits root sur un ordinateur puis qu’on autorise n’importe qui dans le monde à dialoguer avec un LLM, le système finira inévitablement par devenir vulnérable. De même qu’on ne délègue pas des pouvoirs illimités à un humain, il est logique de ne pas autoriser un LLM à accéder à des données sans lien avec le demandeur ni à modifier les données utilisateur
  • Le problème, c’est qu’il suffit de couper un seul côté de la lethal trifecta. En pratique, ces trois éléments sont imbriqués. Par exemple, un contenu externe comme un email peut aussi relever des données personnelles, et envoyer un email peut transmettre le contenu de ma boîte de réception à un attaquant. De plus, des outils comme l’email ou GitHub sont surtout utiles lorsqu’ils peuvent à la fois recevoir et envoyer, et dédier un serveur distinct à chaque fonction est inefficace
• Avec une formation en mécanique, cet article me semble insuffisant. On dit souvent « il suffit d’ajouter de la résistance », mais en réalité cela ne s’applique qu’après avoir compris en détail les différents modes de défaillance. La lethal trifecta n’est qu’un mode de défaillance parmi d’autres, et on ajoute de la « résistance » pour l’empêcher. Ce n’est pas « ce pont vibre trop, réfléchissons à comment le traverser sans danger », mais plutôt : il faut modifier le pont pour qu’il ne vibre pas excessivement dès le départ
  • J’ai l’impression que le monde est devenu fou. Si on suivait cette analogie du pont, on dirait qu’on maîtrise la construction de ponts depuis longtemps, mais qu’il arrive parfois que le sol disparaisse soudainement et que des gens tombent dans la rivière, et qu’au lieu de se demander comment éviter cela, on dise : « mettons des filets en dessous et récupérons-les quand ils tombent ». On déverse des milliards sur une technologie fondamentalement imprévisible, puis on se contente d’ajouter quelques garde-fous. C’est absurde
  • Dès que je vois dans un article une formule du type « les développeurs doivent… », je perds immédiatement de l’intérêt. L’analogie elle-même me paraît mauvaise, et elle sonne faux même pour des gens du métier. La condition citée par le journaliste — « dans une entreprise, laisser un LLM avoir en même temps accès à des données non fiables, à des informations sensibles et à des communications externes » — est déjà le vrai problème. Bien souvent, c’est parce que l’entreprise privilégie les fonctionnalités à la sécurité qu’elle crée ce risque. L’idée selon laquelle « les LLM sont non probabilistes donc une approche déterministe n’est pas adaptée » est un saut logique. Même s’ils sont non déterministes, la logique du sandboxing reste valable ; autrement dit, pousser trop loin l’analogie finit par nuire au domaine concerné. Mieux vaudrait employer les termes techniques et la connaissance métier, mais ce serait sans doute moins vendeur comme article
• L’article disait-il vraiment que les seules solutions étaient des limitations de vitesse et de meilleurs modèles ? Les ingénieurs logiciel étudient ce genre de problèmes depuis des décennies. Le secteur connaît les réponses en matière de sécurité ; le problème, c’est qu’elles ne cadrent pas avec l’attitude actuelle qui consiste à sortir à toute vitesse des produits IA
  • L’IA fait désormais partie du même domaine que l’IT ; dans ce cas, la conclusion serait plutôt : « nous n’avons pas compris la sécurité ». Dire que l’IA est négligente sur ce point n’est pas exact. Le fait qu’il n’existe aucun moyen de séparer parfaitement les données et les tokens d’instruction est une limite fondamentale, pas simplement de la négligence. Dire « on a tout compris il y a des décennies » relève de l’arrogance
  • Les déclarations du type « on a résolu la sécurité il y a des décennies » apparaissent quand une nouvelle industrie recrée les mauvais standards de l’ancienne en se précipitant pour livrer des « produits IA ». Il suffit de voir des cas comme le standard MCP, percé dès le départ : des approches du genre « écrire de meilleurs prompts » en deviennent presque risibles. Le plus gros problème, c’est que presque tout le monde dans l’industrie de l’IA a conçu sans grand recul des serveurs MCP avec accès direct à la base de données. C’est un bon exemple du fait que ce n’est pas parce qu’on peut faire quelque chose qu’il faut forcément le faire ; et cette sécurité bâclée conduit déjà à de nombreuses compromissions de produits IA réels
  • L’affirmation « nous connaissons déjà la sécurité » n’est en réalité pas vraie. Et c’est encore moins vrai dès qu’on touche au facteur humain, où même des formations répétées coûtant des milliards voient leur efficacité décroître. Récemment encore, on a vu même d’excellents experts en sécurité se faire piéger par de simples attaques de phishing sur YouTube
• Billet original de @simonw : The lethal trifecta for AI agents, avec aussi un billet complémentaire. Je laisse également le lien vers la discussion connexe sur HN
• La lethal trifecta, c’est le problème qui survient lorsqu’un LLM a en même temps accès à des données non fiables, à des informations sensibles et à des communications externes. La solution consiste à réduire le risque par la gestion des frontières (permissions), ce qui relève d’une sécurité très basique, niveau 101
  • Oui, mais dans la pratique cela crée une forte tension entre sécurité et fonctionnalités. Si l’on veut faire des choses utiles avec des données personnelles, on ouvre des vulnérabilités au prompt injection. De plus, regrouper autant que possible des contextes liés améliore l’efficacité des agents, mais si l’on sépare ou isole complètement les agents qui lisent des entrées non fiables, on réduit aussi leur utilité. Voir ce billet de blog
  • À strictement parler, cela reste simplement du contrôle d’accès élémentaire (Access Control). Dès qu’il y a une connexion à Internet, le risque explose. Un excellent chercheur en sécurité pourrait, avec un seul prompt injection, prendre le contrôle de tout le système, ce qui satisferait immédiatement au moins une des conditions
• Les LLM ne distinguent pas les prompts des données. Il n’existe pas d’équivalent au bit NX (No-eXecute), ni même quelque chose de vraiment comparable. Bien sûr, même l’introduction du bit NX n’a pas empêché totalement l’exécution de code à distance, donc cela ne suffirait pas à lui seul. Aujourd’hui, l’approche la plus réaliste consiste à gérer le processus d’agent LLM avec des mécanismes de sécurité classiques. Par exemple, l’exécuter sous un compte utilisateur distinct pour limiter l’accès aux fichiers, et ajouter des restrictions réseau, matériel ou via les cgroups. Malgré cela, si des commandes sont mêlées à des données non fiables, le risque demeure que le LLM exfiltre aussi des données secrètes. Et si l’utilisateur copie ensuite vers l’extérieur la sortie du LLM sans s’en rendre compte, le canal d’exfiltration s’ouvre de nouveau
  • Quand on dit que personne n’a créé quelque chose de similaire, je me demande si quelqu’un a vraiment essayé, ou s’il existe seulement des données d’entraînement pertinentes. Les animaux sociaux pratiquent naturellement la compartmentalization. Même un chien peut dissimuler l’existence de nourriture en observant la réaction des humains. En élevant un enfant, je gère moi aussi les informations de façon distincte selon qu’il s’agit de vie sociale, de connaissances confidentielles, de données personnelles de l’enfant, d’informations qu’il est encore trop tôt pour lui transmettre, de mes pensées intimes, ou de choses apprises depuis des sources non fiables. L’intelligence compte, mais la sagesse (wisdom) n’est toujours pas une considération de premier ordre dans le monde des LLM. À ce stade, même les chiots et les jeunes enfants font mieux en matière de compartimentation
• J’ai relevé une citation marquante dans l’article de fond associé : le système CaMeL proposé par Google utilise deux LLM pour éviter une partie des risques de la lethal trifecta. L’un n’accède qu’aux données non fiables, l’autre traite tout le reste. Un modèle plus fiable traduit les instructions en langage naturel de l’utilisateur en code à portée limitée, et le modèle non fiable remplit les blancs de ce code. Cette architecture apporte des garanties de sécurité, mais restreint fortement le champ des tâches que le LLM peut accomplir. Je n’en avais jamais entendu parler et je me demande à quel point cela fonctionne en pratique. Est-ce que cela garantit vraiment une sécurité « absolue », quelles contraintes cela impose, et si cela pourrait devenir une alternative concrète ? Source de l’article
  • J’ai longuement réfléchi au papier sur CaMeL. C’est une approche assez bonne, mais sa mise en œuvre réelle est très difficile et le système ne peut accomplir qu’un ensemble de fonctions assez limité. J’ai résumé cela dans mon analyse
• L’article recourt à l’analogie selon laquelle « les ingénieurs IA doivent penser comme de vrais ingénieurs dans des domaines comme la construction de ponts, où des vies humaines sont en jeu ». L’idée étant que « les ingénieurs IA sont formés dès l’école à croire qu’avec davantage de données d’entraînement et des prompts plus intelligents, on peut résoudre le problème »
  • Ici, dire que « les ingénieurs IA doivent penser comme de vrais ingénieurs » signifie qu’ils doivent penser non pas comme de simples ingénieurs logiciel, mais comme des ingénieurs au sens plein, puisque les logiciels sont désormais embarqués aussi dans des ponts ou des voitures ; il faut donc au minimum adopter la manière de raisonner des ingénieurs du monde physique
  • Cela laisse entendre une proposition du type certification professionnelle en ingénierie logicielle, voire certification éthique. Mais comme les logiciels non éthiques mais légaux peuvent rapporter énormément, j’ai du mal à croire que ce genre d’idée puisse réellement s’appliquer
  • La conclusion de l’idée selon laquelle « il suffit d’avoir de meilleures données d’entraînement » est qu’au final, ce sont ces dommages tragiques eux-mêmes qui deviennent les données d’entraînement
  • Il ne faut pas oublier non plus le rôle des « architectes », pas seulement celui des « ingénieurs » logiciel
• Je me dis qu’il y aurait peut-être une opportunité commerciale à lancer, sous forme d’abonnement payant, un produit logiciel qui surveille automatiquement les comptes LLM et filtre/pipeline les entrées