La sécurité de l’IA générative à base de LLM

SoC, ,
Dans un précédent article, il avait été question d'attaques sur un agent à base de LLM, typiquement un chat. En effet, un tel agent interprète le prompt non seulement comme un texte à compléter, mais aussi comme une liste d'instructions à suivre, ce qui fait de ce texte un vecteur d'attaque d'autant plus intéressant à exploiter que personne aujourd'hui ne peut dire comment fonctionne un LLM, si bien qu'il est impossible d'en sécuriser l'usage.
La sécurité des systèmes d'IA générative à base de LLM
Dans ces conditions, la prolifération des agents constitue un enjeu considérable du point de vue de la sécurité informatique, et c'est sans surprise que les agences telles que l'ANSSI ont entrepris de sensibiliser les organisations à ce sujet.
Toutefois, il n'y a pas que les risques techniques dont il est nécessaire de tenir compte. En effet, les risques juridiques ne sont pas moindres, tout particulièrement ceux qui ressortissent au traitement des données à caractère personnel.
NB : Ce billet a été rédigé mi-août par un humain et non une boîte de conserve, et publié dans une version réduite dans le HS n° 16 de Programmez! d'octobre 2024 consacré à la sécurité informatique, et en version intégrale dans le n° 266 de Programmez! de novembre 2024.

Y-A-T'IL UN COPILOT DANS L'AVION ?

Début août, l'édition 2024 de Black Hat – le plus prestigieux rendez-vous des hackers du monde entier – s'est tenue aux US. Actualité oblige, l'IA générative a fait partie des sujets mis à l'ordre du jour. En particulier, deux sessions ont été consacrées à Copilot, animées par Zenity.
Pour rappel Copilot, c'est l'agent intelligent de Microsoft qui s'appuie sur un LLM, ou plusieurs, a priori d'Open AI – l'on manque de détail sur ce point, et ces LLMs sont certainement fine-tuned, à la manière de Copilot pour Github, où la technologie a fait ses premiers pas. Copilot réagit à la présence de mots-clés, ou triggers, dans le prompt qui constitue donc la demande de l'utilisateur, interroge Microsoft Graph pour récupérer du contenu correspondant, enrichit le prompt avec ce contenu – une technique désignée par RAG, pour Retrieval-Augmented Generation –, et refile le tout au LLM, qui génère une réponse sur cette base, éventuellement des commandes pour faire fonctionner des applications :
Fonctionnement général de Copilot, d'après Microsoft
Pour ceux qui n'en auraient jamais entendu parler, Microsoft Graph, c'est un point d'accès unique via une API REST aux données d'une multitude de services – Office 365, Entreprise Mobility + Security, etc. – de la plateforme Microsoft 365 dans le cloud.
Si les vidéos des sessions de Zenity ne sont malheureusement pas encore disponibles, les supports sous forme de PDF peuvent être téléchargés sur le site de Black Hat et celui de Zenity. Par ailleurs, Zenity a posté des vidéos de démonstrations de certaines attaques sur son channel YouTube.
Dans 15 Ways to Break Your Copilot, Zenity passe en revue les fonctionnalités de Copilot Studio, une application qui permet de créer des Copilots, sur le modèle des GPTs introduits plus tôt par OpenAI, c'est-à-dire des chats spécialisés, en ceci qu'ils s'appuient sur des données et des instructions spécifiques. Zenity montre qu'il est bien trop facile de donner accès à Copilot à des données internes comme externes, passant au travers des cloisons laborieusement érigées pour limiter cet accès. Si encore Copilot ne se contentait que de récupérer les données, mais il est de plus possible de lui faire exécuter des actions, ce qui expose au risque d'être mal compris – ou trop bien compris par un acteur malveillant –, débouchant sur la destruction de données.
15 vulnérabilités de Copilot, d'après Zenity
Dans Living off Microsoft Copilot, Zenity fournit des exemples de mise en œuvre de certaines techniques inscrites au référentiel ATT&CK de MITRE : reconnaissance, collecte, exécution, exfiltration, mouvement latéral, etc. Ainsi, dans une des attaques détaillées dans une vidéo, le hacker envoie un courriel à Bob dans lequel il loge des instructions destinées au LLM sous forme de texte invisible à l'œil nu – taille de police minuscule, 0.1px. Il s'agit simplement d'un texte qui lui commande d'ignorer ce qui vient de lui être demandé, et d'afficher un lien malveillant résultant d'une recherche sur le Web. Lorsque Bob démarre Copilot, ce dernier, qui est paramétré pour lire automatiquement les courriels de Bob et en produire une synthèse au prétexte que "I'm here to assist you", affiche le lien malveillant.
Instructions à l’attention du LLM injectées dans un courriel, d'après Zenity
Il semble qu'en voulant mettre à disposition un outil qu'une secrétaire pourrait utiliser, Microsoft a comme donné un revolver à un gamin. Les réglages par défaut des options de sécurité, dont Zenity dénonce le caractère aberrant, viennent en rajouter – même s'ils ont évolué depuis, ils n'en restent pas moins "one click away...", formule dont nul ne peut ignorer la portée sachant que l'humain est le maillon faible. A cette aune, du point de vue de la sécurité informatique, introduire Copilot dans votre organisation reviendrait à installer un aspirateur à données qu'il serait trop facile d'inverser pour en faire un ventilateur de ces dernières. Les hackers de Kim Jong Un ne manqueraient pas d'être intéressés par votre choix d'un tel Transformer. Nécessairement, cela invite à réfléchir...
S'il est possible de prendre des dispositions pour limiter, sinon prévenir, les risques que Zenity présente, rajoutons que Copilot n'en pose pas moins un problème nouveau en sécurité informatique, spécifique aux outils à base d'IA générative avec lesquels il est possible d'interagir en langage naturel via un LLM.
En effet, avec un LLM, le ticket d'entrée pour hacker une entreprise devient presque gratuit. Dépassés les skids – les script kiddies, pour désigner ceux qui savent à peine programmer, sinon dans un langage des plus simples. Il n'est même plus nécessaire d'avoir de compétences techniques, sinon en prompt engineering – un art très surfait –, pour contourner d'éventuels filtres de contenu – par exemple demander au LLM de générer une réponse chiffrée en code César pour qu'elle ne soit pas interceptée à la sortie, comme le montre Zenity.
Dans un précédent article consacré aux attaques sur les LLMs, l'on a rappelé l'histoire de l'attaque de ce type d'IA. A partir du moment où un petit malin a trouvé le moyen d'amener Bing à révéler qu'il s'appelait Sydney, les hackers y vont vu un terrain de jeu ; les chercheurs, une discipline ; les entreprises, un marché ; et enfin les agences, une mission. Ces dernières ont donc entrepris de sensibiliser les organisations aux risques auxquels introduire l'IA générative dans leurs systèmes d'information les expose.

UNE BOITE NOIRE DÉLICATE À SÉCURISER TECHNIQUEMENT

Fin avril, l'Agence Nationale de la Sécurité des Systèmes d'Information (ANSSI) a produit un guide. Intitulé Recommandations de sécurité pour un système d'AI générative, il ne traite à dessein que des LLMs qui, il est vrai, constituent de loin le principal objet de préoccupations à ce jour.
Les guides de l'ANSSI sont généralement très bien réalisés, et force est de constater qu'encore une fois, l'Agence ne déçoit pas. A grand renfort de schémas pour que ce soit bien clair, le guide donne d'abord à voir comment se déroule la conception d'un système d'IA générative à base de LLM, et comment il s'intègre dans un SI.
Considéré dans son ensemble, le schéma du cycle de vie permet de constater qu'avec ses trois phases d'entraînement, de déploiement et de production, la conception d'un tel système s'apparente à celle d'une application classique. L'on en déduit qu'il faut prendre toutes les précautions qui s'imposent pour n'importe quelle application. De fait, après avoir simplement souligné la nécessité d'utiliser des environnements compartimentés à chaque phase, l'ANSSI renvoie à la littérature existante pour se doter d'un socle de sécurité générique.
A l'inverse, considéré dans le détail, le schéma permet de constater que la conception d'un système d'IA générative tranche singulièrement avec celle d'une application classique. La raison en est l'importance apparente des données. En effet, elles déterminent le comportement du système non seulement après l'entraînement du LLM, mais aussi au fil régulier de son réentraînement, pour améliorer le système sur la base des données qu'il a permis de collecter. Cette fois, l'on en déduit que de plus, il faut prendre des précautions spécifiques.
Un autre schéma détaille l'architecture d'un système d'IA générative à base de LLM. Il est très intéressant, au point que si lecteur qui veut s'acculturer aux enjeux de sécurité d'un tel système ne devait en retenir qu'un, ce devrait être celui-là :
Architecture générique d’un système d’IA générative, d'après l'ANSSI
Disons que ce schéma donne à voir deux choses essentielles :
  • Tout d'abord, un système d'IA générative est potentiellement très ouvert, les possibilités d'échanger des données avec des sources internes et externes étant nombreuses. Sachant ce qui vient d'être dit sur la manière dont les données déterminent le comportement du système, cela doit préoccuper au plus haut point.
    Pour revenir sur Copilot, comme Satya Nadella le disait en présentant la gamme de PC Copilot+ lors de la Build 2024, un tel système "turn the world itself into a prompt" parce qu'il est facile, et donc tentant, de lui donner accès à des données. C'est sans doute bien pratique, mais cela peut donner le sentiment que les frontières semblent abolies, alors qu'elles existent et doivent plus que jamais exister. Or l'on a vu plus tôt à quels dangers sous-estimer cette existence peut exposer, en rapportant les trouvailles de Zenity : dans Copilot Studio, si l'utilisateur peut importer et exporter librement des données depuis et vers le système, le RSSI a effectivement de quoi s'arracher les cheveux.
  • Par ailleurs, le schéma donne à voir des composants spécifiques d'un tel système, sur lesquels l'ANSSI attire l'attention, à savoir les filtres – pour contrôler plus efficacement ce qui entre et ce qui sort du LLM –, la base de données vectorielle – pour permettre au LLM d'utiliser des données –, les plugins – pour permettre au LLM de commander des actions via des appels à une API – et les utilisateurs. Cela aussi doit préoccuper au plus haut point.
    Ici, même si elles sont concernées en dernière instance, c'est moins des données dont il doit être question, que du comportement du LLM. L'existence de filtres laisse bien entendre qu'il serait illusoire de s'en remettre au seul modèle pour se contrôler, notamment prévenir sa tendance à halluciner – faire référence à des faits qui n'ont rien de réel –, et sa tendance à ne pas respecter les règles qui lui ont été "enseignées", toutes choses qui ont fait le délice des médias depuis la sortie de ChatGPT. En conséquence, la possibilité pour le LLM de commander des applications via des plugins doit préoccuper au plus haut point.
L'ANSSI donne quelques exemples d'attaques, ce qui lui fournit l'occasion de préciser que ces dernières se répartissent plus généralement en trois catégories :
  • les attaques par manipulation, qui visent "à détourner le comportement du système d'IA en production au moyen de requêtes malveillantes" ;
  • les attaques par infection, qui visent "à contaminer un système d'IA lors de sa phase d'entraînement, en altérant les données d'entraînement ou en insérant une porte dérobée" ;
  • les attaques par exfiltration, qui visent "à dérober des informations sur le système d'IA en production, comme les données ayant servi à entraîner le modèle, les données des utilisateurs ou bien des données internes du modèle (paramètres)".
Ce n'est pas pour critiquer cette catégorisation, mais pour en pointer une autre qui s'articule bien avec elle, qu'il est intéressant de franchir l'Atlantique pour citer le travail du National Institute of Standards and Technology (NIST) [NB : si vous vous demandez à quoi sert le NIST, regardez notamment l'étonnant épisode du channel Verisatium sur YouYube consacré à sa collection d'objets standards, ou celui non moins étonnant consacré à la mesure de forces les plus faibles de l'univers].
En janvier dernier, le NIST a publié une taxinomie des attaques sur les systèmes d'IA génératives. Elle donne à voir ces attaques non par catégories, comme l'ANSSI l'a fait, mais par catégories de risques auxquels elles exposent :
Taxinomie des attaques sur les systèmes d'IA générative, d'après le NIST
Comme dit à l'instant, ces deux catégorisations s'articulent bien, et il est utile de les contempler toutes deux pour se faire une idée des attaques possibles sur un système d'IA générative.

QUELQUES EXEMPLES D'ATTAQUE RÉCENTS

Dans un précédent article déjà mentionné, l'on a déjà produit de nombreux exemples de certaines de ces attaques en se référant à des travaux académiques, poussant la complaisance jusqu'à donner les prompts. Comme indiqué alors, il ne se passait guère de jour sans qu'une nouvelle attaque soit révélée.
Pour ancrer le propos qui vient d'être tenu sur la catégorisation des attaques dans la réalité, citons-en donc quelques-unes qui ont fait parler d'elles tout récemment. L'on s'en tiendra à des attaques qui relèvent de la catégorie des attaques par manipulation pour l'ANSSI, plus communément désignées par jailbreaking, le risque étant l'abus du LLM si l'on se réfère à la catégorisation du NIST, pour qui ces attaques relèveraient de la catégorie des prompt injections. Le but est donc de faire dire à un LLM ce que, du fait de sa configuration – entraînement spécifique, dit safety training, et/ou instructions dans la partie du prompt que l'utilisateur ne voit pas, dit system prompt –, il ne devrait pas.
Fin juin, Microsoft annonce avoir trouvé la parade à une attaque baptisée Skeleton Key, qui fonctionne sur toute une série de LLMs. Plus concrètement, il s'agit de convaincre le LLM d'outrepasser ses restrictions en lui demandant paradoxalement de les respecter :
Une démonstration de l'attaque Skeleton Key, d'après Microsoft
Microsoft qualifie l'attaque de multiturn, en tant qu'elle comprend plusieurs étapes puisqu'elle vise d'abord à convaincre le LLM d'ignorer ses restrictions avant de lui demander de produire un texte qui les ignore. A croire que la firme de Redmond s'en est fait une spécialité, car début avril, elle avait déjà dévoilé une attaque baptisée Crescendo, qui fonctionnait elle aussi sur toute une série de LLMs. Plus étonnante que Skeleton Key, elle visait, en plusieurs étapes, à encourager le LLM à dire ce qu'il ne devrait pas :
Une démonstration de l'attaque Crescendo sur ChatGPT
Cela donne l'opportunité d'évoquer une attaque de ce genre encore plus récente, qui présente l'intérêt non seulement d'avoir ciblé un LLM dont son éditeur affirmait que le point fort était la sécurité, mais aussi celui de se présenter d'une manière un peu différente.
D'après Gray Swan AI, dont la devise est "Safety and Security for the AI Era", Cygnet est un LLM "designed to give developers substantially improved degrees of safety and control over the models they deploy". Mi-juillet, au lendemain de sa mise à disposition, un certain Pliny the Prompter (@elder_plinius) publie sur X une attaque qui lui a permis d'atteindre le même résultat que Skeleton Key :
Une démonstration de l'attaque sur Cygnet., d'après elder_plinius
Comme il est possible de le constater, contrairement à Skeleton Key, l'attaque ne mobilise pas que du langage naturel. Y figurent des mots en 1337 – le langage des hackers, car "31173 2UL32!" –, dont l'on peut penser que l'objet est de tromper un ces filtres mentionnés par l'ANSSI, et des séquences de caractères, dont l'on se demande bien d'où elles sortent. C'est que ces dernières sont parfois du type de celles que l'on retrouve dans les prompt injections élaborées par recherche adverse – "perturbations [...] found by optimizing the input to maximize the prediction error", dixit Intriguing Properties of Neural Networks, un papier de... 2013 –, ainsi qu'illustré dans un papier publié début mars, Automatic and Universal Prompt Injection Attacks against Large Language Models – pour ne citer que celui-là, car il est bien connu et comporte un sympathique schéma :
Prompt injection comprenant des tokens identifiés par recherche adverse
Toutefois, cela suppose que le LLM soit une white box et non une black box – toute la différence entre avoir accès à sa mécanique ou non –, même s'il est dit que l'attaque peut être transférable.
Comment Pliny the Prompter est-il parvenu à ce prompt ? Fin mai, il a accordé un bref entretien à VentureBeat. Le journaliste n'a pas été bien curieux, aussi ne l'a-t-il pas interrogé sur la manière dont le prompter s'y est pris. Toutefois, les propos échangés éclairent un peu sur ses motivations, dont l'exposé en dit long sur le mérite qu'il reconnaît aux efforts des éditeurs de LLMs pour sécuriser leurs produits : "I hope it spreads awareness about the true capabilities of current AI and makes them realize that guardrails and content filters are relatively fruitless endeavors". Rassurant... Au-delà, ceux que cela intéresse peuvent passer en revue la collection de prompts que Pliny the Prompter expose dans le répertoire L1B3RT45 de son dépôt sur Github, voire rejoindre la communauté BASI qu'il a créée sur Discord, sans oublier alors d'avoir préalablement fait une petite revue de littérature, notamment les surveys consacrés aux attaques sur les LLMs publiés sur arxiv, histoire de ne pas trop passer pour un n00b.
Pour clore cet interlude pratique, disons que ces attaques par prompt injection qui permettent le jailbreaking – dont l'on rappelle qu'elles ne forment qu'une catégorie d'attaques parmi bien d'autres, comme montré plus tôt – sont tout à fait amusantes, mais de maigres découvertes en comparaison de celle effectuée mi-février par un groupe de chercheurs qui se sont demandés si toutes ces attaques ne reposaient pas sur une faiblesse générale.
Dans Coercing LLMs to do and reveal (almost) anything, ces chercheurs ont montré qu'il est possible de faire dire à un LLM absolument n'importe quoi, poussant d'ailleurs le fun jusqu'à générer l'abstract du papier de cette manière. Leur technique consiste à constituer un texte en concaténant tout ce qui figure avant la question de l'utilisateur – le system prompt, puis les tokens de formatage de la question –, la question, puis une séquence t de tokens à deviner, et enfin tout ce qui doit figurer après la question – les tokens de mise en forme de la réponse, puis cette dernière. Autrement dit, tout ce que doit finalement contenir la context window. Ils recherchent alors t dans la limite de n tokens en mettant en œuvre une technique de recherche adverse, en l'espèce une analyse de gradient [NB : qui prétend s'intéresser au deep learning ne peut faire l'économie de comprendre en quoi consiste la descente de gradient]. Une fois que t a été trouvée, cela signifie qu'il est possible de fournir au LLM un texte composé de la question suivie de t, et d'obtenir la réponse attendue.
Coercing LLMs to do and reveal (almost) anything
Pour parvenir à ce beau résultat, le LLM doit être une white box – ils ont torturé Llama 2 7B –, ce qui limite donc la portée des attaques en tout genre qui exploitent la faiblesse dont les chercheurs font la démonstration, et dont par ailleurs le taux de réussite est variable, même s'il est globalement excellent – en fait, très souvent 100%.
Au passage, en cherchant à comprendre ce que les séquences de tokens t pouvaient avoir de remarquable, les chercheurs ont notamment analysé la fréquence d'occurrence des tokens en particulier dans ces séquences. Un résultat des plus intéressants, qui a pu d'ailleurs inspirer Pliny the Prompter, c'est que parmi les tokens les plus fréquents, l'on trouve des caractères tels que "]" , "[", ou encore "_" qui ne s'utilisent jamais aussi souvent que dans... le code :
Tokens les plus fréquents dans les séquences t
Les chercheurs n'y voient pas le fait du hasard. Plus tôt, ils pointent un type d'attaque qu'ils désignent par "(re)programming", où il s'agit d'exploiter "the model's understanding of the code as a domain separate from natural text and as a domain where other rules apply". Bref, court-circuiter les restrictions en tirant parti du fait que le LLM, qui a notamment été entraîné sur du code, n'a été durci que pour prévenir les abus en langage naturel.
Toutefois, c'est moins ces attaques qu'il faut retenir que le fait que les chercheurs sont toujours parvenus à en élaborer. Ils rapportent que leur technique, que l'on vient de présenter, est fondée sur une découverte rapportée dans un autre papier qui remonte à mi-avril 2023, Fundamental Limitations of Alignment in Large Language Model, où des chercheurs ont mis en évidence que "for any behavior that has a finite probability of being exhibited by the model, there exist prompts that can trigger the model into outputting this behavior, with probability that increases with the length of the prompt". Autrement dit, quitte à accroître n, il est toujours possible de trouver t pour élaborer une attaque.
Partant, la conclusion des chercheurs permet de prendre toute la mesure de l'enjeu que soulève le recours à un système d'IA à base de LLM en termes de sécurité informatique :
We ultimately conclude by confirming the initial hypothesis that arbitrary free text input to these models allows almost any outcome, and that for now, from a security perspective, any output of a language model, generated from user input, has to be assumed to be insecure. Fundamentally, there might be no fix for this.
De quoi mieux comprendre pourquoi Pliny the Prompter regarde de haut les éditeurs de LLMs, et de quoi donner froid dans le dos à tout RSSI consulté sur le projet d'introduire un système d'IA générative à base de LLM dans son organisation...

ЧТО ДЕЛАТЬ?

Bonne question, dirait Lénine. Dans son guide, l'ANSSI formule 35 recommandations. Elles portent sur chacune des trois phases du cycle de vie citées plus tôt, et l'Agence y adjoint des recommandations spécifiques à certains usages : quand le système d'IA générative est destiné à générer du code source, à exposer des services au grand public sur Internet, utiliser un service d'IA générative tiers – comme par exemple un traducteur sur le Web.
Il n'est pas question de reprendre dans le détail la liste des recommandations – encore une fois, le guide est très bien fait, et le lecteur est vivement incité à s'y référer. L'on se contentera ici de les lister :
Recommandations générales
R1 Intégrer la sécurité dans toutes les phases du cycle de vie d'un système d'IA
R2 Mener une analyse de risque sur les systèmes d'IA avant la phase d'entraînement
R3 Évaluer le niveau de confiance des bibliothèques et modules externes utilisés dans le système d'IA
R4 Évaluer le niveau de confiance des sources de données externes utilisées dans le système d'IA 14
R5 Appliquer les principes de DevSecOps sur l'ensemble des phases du projet
R6 Utiliser des formats de modèles d'IA sécurisés
R7 Prendre en compte les enjeux de confidentialité des données dès la conception du système d'IA
R8 Prendre en compte la problématique de besoin d'en connaître dès la conception du système d'IA
R9 Proscrire l'usage automatisé de systèmes d'IA pour des actions critiques sur le SI
R10 Maîtriser et sécuriser les accès à privilèges des développeurs et des administrateurs sur le système d'IA
R11 Héberger le système d'IA dans des environnements de confiance cohérents avec les besoins de sécurité
R12 Cloisonner chaque phase du système d'IA dans un environnement dédié
R13 Implémenter une passerelle Internet sécurisée dans le cas d'un système d'IA exposé sur Internet
R14 Privilégier un hébergement SecNumCloud dans le cas d'un déploiement d'un système d'IA dans un Cloud public
R15 Prévoir un mode dégradé des services métier sans système d'IA
R16 Dédier les composants GPU au système d'IA
R17 Prendre en compte les attaques par canaux auxiliaires sur le système d'IA
Recommandations pour la phase d'entraînement
R18 Entraîner un modèle d'IA uniquement avec des données légitimement accessibles par les utilisateurs
R19 Protéger en intégrité les données d'entraînement du modèle d'IA
R20 Protéger en intégrité les fichiers du système d'IA
R21 Proscrire le ré-entraînement du modèle d'IA en production
Recommandations pour la phase de déploiement
R22 Sécuriser la chaîne de déploiement en production des systèmes d'IA
R23 Prévoir des audits de sécurité des systèmes d'IA avant déploiement en production
R24 Prévoir des tests fonctionnels métier des systèmes d'IA avant déploiement en production
Recommandations pour la phase de production
R25 Protéger le système d'IA en filtrant les entrées et les sorties des utilisateurs
R26 Maîtriser et sécuriser les interactions du système d'IA avec d'autres applications métier
R27 Limiter les actions automatiques depuis un système d'IA traitant des entrées non-maîtrisées
R28 Cloisonner le système d'IA dans un ou plusieurs environnements techniques dédiés
R29 Journaliser l'ensemble des traitements réalisés au sein du système d'IA
Cas particulier de la génération de code source assistée par l'IA
R30 Contrôler systématiquement le code source généré par IA
R31 Limiter la génération de code source par IA pour des modules critiques d'applications
R32 Sensibiliser les développeurs sur les risques liés au code source généré par IA
Cas particulier de services d'IA grand public exposés sur Internet
R33 Durcir les mesures de sécurité pour des services d'IA grand public exposés sur Internet
Cas particulier de l'utilisation de solutions d'IA génératives tierces
R34 Proscrire l'utilisation d'outils d'IA générative sur Internet pour un usage professionnel impliquant des données sensibles
R35 Effectuer une revue régulière de la configuration des droits des outils d'IA générative sur les applications métier
Toutefois, s'il fallait n'en détailler qu'une pour bien faire sentir l'ambiance, on retiendrait la R9. Pour la justifier, l'ANSSI campe le décor en ces termes :
Les IA génératives LLM ont pour la plupart un comportement non-déterministe, et elles peuvent également être sujet à des hallucinations. Cette incertitude sur la réponse obtenue pour une requête donnée implique une plus grande vigilance sur les conséquences indirectes de ces réponses. Ainsi, les interactions d'un système d'IA avec d'autres ressources du SI doivent proscrire l'exécution d'actions automatisées critiques pour l'organisation. [...] Ce principe de précaution doit prévaloir et un système d'IA générative ne doit pas pouvoir prendre des décisions critiques ayant un impact fort sur le métier ou la protection des biens et des personnes, sans un contrôle humain.
Dès lors, l'ANSSI recommande de "proscrire l'usage automatisé de systèmes d'IA pour des actions critiques sur le SI". Cette seule recommandation en dit long sur le degré de confiance qu'il convient d'accorder à un système d'IA générative. On se figure la scène. Invité au Comex à se prononcer sur l'opportunité de déployer Copilot dont il ferait la promotion, le DSI serait interrogé par le DG : "Mais vous l'installeriez chez vous, ce truc ?". Blanc dans la salle...
Enfin, puisque cet article s'adresse avant tout à des informaticiens, et plus généralement parce que les médias ont d'autant plus volontiers relayé cette idée que les LLMs devaient permettre d'automatiser la programmation que cela leur semblait faire l'effet de l'arroseur arrosé, citons les recommandations spécifiques de l'ANSSI en la matière :
  • "Contrôler systématiquement le code source généré par IA" ;
  • "Limiter la génération de code source par IA pour des modules critiques d'applications" ;
  • "Sensibiliser les développeurs sur les risques liés au code source généré par IA".
La lecture de la liste des tâches que l'ANSSI énumère pour expliciter le contrôle à exercer sur le code source généré ne manquera pas de rappeler à certains les joies de la reprise de code dont l'écriture a été confiée à des sous-traitants à l'autre bout du monde, ce qui ne va jamais sans générer des coûts cachés. Mais cela, on l'avait déjà bien pointé dans le premier article consacré à l'utilisation de ChatGPT pour générer du code, il y déjà longtemps !
Au-delà des seuls informaticiens, tout comme la recommandation de ne pas utiliser un système d'IA générative pour accomplir automatiquement des actions critiques sur le SI, ces recommandations sur son utilisation pour générer du code devraient attirer l'attention de tous ceux qui auraient la tentation de recourir à un tel système dans leur domaine d'activité, quel qu'il soit. Quand le cordonnier ne veut pas être le plus mal chaussé, c'est qu'il y a quelque chose de bizarre...
On ressort donc de la lecture du guide de l'ANSSI avec le sentiment que plus que tout autre système, le recours à un système d'IA générative doit être particulièrement encadré, car son fonctionnement est imprévisible. C'est une boite noire, à ce titre délicate à sécuriser, pour autant que cela soit possible.

UNE BOITE NOIRE DÉLICATE À SÉCURISER JURIDIQUEMENT AUSSI

Comme le rappelle l'ANSSI dans son guide, au-delà de la sécurité informatique, d'autres enjeux sont à prendre en compte dans la conception d'un système d'IA générative : "l'éthique, la vie privée, la propriété intellectuelle, la protection du secret des affaires ou encore la protection des données personnelles" – encore l'ANSSI n'évoque-t-elle pas d'autres enjeux qui peuvent selon le cas venir s'ajouter, comme la compliance. Cette énumération démontre, s'il en était besoin, toute l'épaisseur d'un sujet qu'il serait en conséquence suicidaire de réduire à sa seule dimension technique, tant les conséquences peuvent être... conséquentes.
Pour ce qui concerne seulement les droits sur les données, à moins de vivre sous un rocher, il n'aura échappé à personne que parce que son fonctionnement repose sur les données qu'il a ingérées, le recours à un système d'IA générative soulève des enjeux relatifs aux droits sur ces dernières. L'on pense spontanément aux droits d'auteur, du fait que cet enjeu a été particulièrement médiatisé (cf. encadré). Toutefois, ce sont moins ces droits que ceux relatifs aux droits sur les données personnelles dont il va être question ici. La raison en est qu'une autre agence qui traite de l'informatique, la Commission Nationale de l'Informatique et des Libertés (CNIL) a, elle aussi, récemment produit des recommandations sur le sujet.
Les droits d'auteur
Generative AI is a marvel. Is it also built on theft?, interrogeait The Economist en avril dernier. Après un temps d'émerveillement "there is widespread irritation that tech firms are again seeking forgiveness rather than permission" écrivait l'hebdomadaire, évoquant le précédent du streaming de musique et constatant que "the lawyering is now happening".
On le sait, peu de temps après l'apparition de ChatGPT, certains ont entrepris de contester la libre utilisation par les acteurs de l'IA de tout le contenu accessible sur le Web pour entraîner leurs modèles. Pour se défendre, aux Etats-Unis – en Europe, c'est évidemment un autre régime juridique, notamment du fait d'une directive sur le droit d'auteur et les droits voisins adoptée pour faire payer les GAFA en son temps –, ces acteurs invoquent le fair use, une notion dont le CEO de Microsoft a donné une définition pour le moins extensive lors d'un entretien accordé à CNBC, fin juin, pour ce qui concerne le contenu publié sur le Web :
With respect to content that is already on the open web, the social contract of that content since the 90s has been that it is fair use. Anyone can copy it, recreate with it, reproduce with it. That has been freeware, if you like. That's been the understanding.
Sévérino pourrait s'acharner sur Octavie, mais aussi droits qu'ils souhaitent donner l'impression de camper dans leurs bottes – au point que certains, comme OpenAI, ont offert d'indemniser leurs clients qui seraient poursuivis par des auteurs –, les acteurs de l'IA, confrontés à une déferlante d'actions en justice, n'en ont pas moins pris conscience que le sol commençait à se fissurer sous leurs pieds.
C'est pourquoi ils ont parallèlement entrepris de se couvrir en prétendant offrir à tous les détenteurs de droits sur du contenu le moyen technique d'en refuser l'utilisation – des directives à rajouter dans Robots.txt, dont Business Insider rapportait fin juin que l'efficacité est toute relative –, et en cherchant à nouer avec certains des accords pour autoriser cette utilisation – ce qui ne manquera pas de créer une nouvelle rivalité entre eux, dès lors qu'il sera question d'exclusivité.
La position des acteurs de l'IA sur les droits sur le contenu utilisé pour entraîner leurs modèles est donc très ambivalente. Quand cette question sera-t-elle définitivement tranchée aux Etats-Unis, là où l'avenir occidental de l'IA se joue essentiellement ? (*) Nul ne le sait, et peut-être ne sera-t-elle d'ailleurs tranchée qu'au cas par cas, au fil du temps judiciaire et non législatif, qui plus est. Il est seulement certain que l'enjeu est énorme, pour tout le monde. En effet, en imposant la rémunération des détenteurs de droits, ne risquerait-on pas de faire surgir un obstacle au développement de modèles, et cela en faveur des acteurs de l'IA déjà établis ?
En attendant, il est clair que la position des clients des acteurs de l'IA, notamment des organisations qui déploient des systèmes d'IA générative à base de LLM, va rester incertaine...
(*) Certes, il y a la Chine, mais quelle organisation occidentale oserait déployer un modèle chinois ?
En Europe, les droits sur les données à caractère personnel revêtent une importance toute particulière du fait de l'existence d'une règlementation qui n'a pas encore d'équivalent aux Etats-Unis. C'est du Règlement Général de Protection des Données (RGPD) dont il est question, évidemment. En France, veiller au respect de son application incombe en première instance à la CNIL.
Pas plus que l'ANSSI, la CNIL n'est restée les bras croisés face à la déferlante de l'IA générative. Dans le cadre d'un "plan IA" annoncé en mai 2023, qui organise la réflexion et l'action "pour un déploiement de systèmes d'IA respectueux de la vie privée des individus", la Commission a publié une première série de fiches pratiques en avril, qui portent sur le développement de systèmes d'IA, suivie d'une seconde en juin, qui portent sur le déploiement de tels systèmes.
Les recommandations de la CNIL ne valent que tant que le développement et/ou le déploiement impliquent le traitement de données à caractères personnel – si vos données ne présentent pas ce caractère, circulez, y'a rien à voir. Sur ce terrain juridique plus que sur tout autre, les mots ont un sens, aussi convient-il de rappeler ce dont il est question :
  • Défini à l'article 3 du Règlement Intelligence Artificielle (RIA), un système d'IA est "un système automatisé conçu pour fonctionner à différents niveaux d'autonomie, qui peut faire preuve d'une capacité d'adaptation après son déploiement et qui, pour des objectifs explicites ou implicites, déduit, à partir des données d'entrée qu'il reçoit, la manière de générer des résultats tels que des prédictions, du contenu, des recommandations ou des décisions qui peuvent influencer les environnements physiques ou virtuel".
  • Définie à l'article 4 du RGPD, une donnée personnelle est "toute information se rapportant à une personne physique identifiée ou identifiable", et le traitement de telles données correspond à "toute opération ou tout ensemble d'opérations effectuées ou non à l'aide de procédés automatisés et appliquées à des données ou des ensembles de données à caractère personnel".
Comme il est possible de le constater, ces définitions sont assez générales, tout particulièrement celle des données à caractère personnel. Dans ces conditions, celui qui entend traiter des données à tout intérêt à se donner le temps de méditer sur leur nature avant de se lancer, histoire de ne pas s'exposer à un risque juridique – du moins pas trop, car en matière de droit, l'on n'est jamais à l'abri d'une interprétation. Au passage, pour ceux qui y auraient songé, inutile de chercher à se cacher derrière le RIA pour échapper au RGPD, car comme le précise la CNIL, "le règlement sur l'IA n'a pas vocation à remplacer les obligations en matière de protection des données mais bien à les compléter".
Ici encore, l'on ne rentrera pas dans le détail des recommandations de la CNIL, se contentant de lister les fiches. S'il ne faut surtout pas commettre l'erreur de réduire ces fiches à leurs intitulés, ces derniers donnent toutefois une bonne idée la nature du travail à fournir pour être dans les clous :
Fiche 1 Déterminer le régime juridique applicable
Fiche 2 Définir une finalité
Fiche 3 Déterminer la qualification juridique des acteurs
Fiche 4 Assurer que le traitement est licite - Définir une base légale
Assurer que le traitement est licite - En cas de réutilisation des données, effectuer les tests et vérifications nécessaires
Fiche 5 Réaliser une analyse d'impact si nécessaire
Fiche 6 Tenir compte de la protection des données dans la conception du système
Fiche 7 Tenir compte de la protection des données dans la collecte et la gestion des données
Fiche 8 Mobiliser la base légale de l'intérêt légitime pour développer un système d'IA
La base légale de l'intérêt légitime : fiche focus sur la diffusion des modèles en source ouverte (open source)
La base légale de l'intérêt légitime : fiche focus sur les mesures à prendre en cas de collecte des données par moissonnage (web scraping)
Fiche 9 Informer les personnes concernées
Fiche 10 Respecter et faciliter l'exercice des droits des personnes concernées
Fiche 11 Annoter les données
Fiche 12 Garantir la sécurité du développement d'un système d'IA
Comme il est possible de le constater, tout comme celui qui vise à sécuriser un système d'IA générative à base de LLM du seul point de vue technique en suivant les recommandations de l'ANSSI, le travail en question est pour le moins conséquent.
Entre autres, les recommandations de la CNIL visent à permettre aux personnes d'exercer des droits sur leurs données personnelles. La fiche n° 10 rappelle ces droits, au rang desquels l'on compte celui d'effacement, dit droit à l'oubli. Sur ce point, la Commission est très claire : "Elles [les personnes] doivent pouvoir exercer leurs droits à la fois sur les bases de données d'apprentissage et sur les modèles d'IA si ces derniers ne sont pas considérés comme anonymes".
Le lecteur s'en doute, ce point n'est pas relevé ici par hasard. En effet, tout comme l'on a évoqué le problème que pose la propension à halluciner d'un système d'IA générative, il convient de soulever un autre problème, à savoir la difficulté pour supprimer une donnée, doublée de celle de s'assurer qu'elle l'est. Ces problèmes ont en commun d'être renforcés par l'incapacité actuelle à expliquer pourquoi un LLM génère ce qu'il génère – l'on y reviendra en conclusion, c'est un domaine de recherche en soi.
Fin septembre 2023, des chercheurs se sont attaqués au problème de la suppression. Dans Can Sensitive Information Be Deleted From LLMs? Objectives for Defending Against Extraction Attacks, ils rapportent avoir élaboré un framework pour supprimer une information à l'aide de différentes techniques connues à ce jour, et vérifier qu'elle l'a été en tentant ensuite de l'extraire – par des attaques de type white box et black box, pour couvrir tous les cas. L'information n'est pas considérée comme supprimée si jamais il est possible de l'extraire au terme de B essais. Il est tout à fait pertinent de s'acharner ainsi, car comme les chercheurs l'expliquent, qui voudrait extraire un mot de passe pour se connecter à un système pourrait très bien avoir la possibilité de tester plusieurs candidats.
Comme l'on s'en doute, la conclusion n'est guère réjouissante :
Our results suggest that truly deleting sensitive information is a tractable but difficult problem, since even relatively low attack success rates have potentially severe implications for the deployment of language models in a world where individuals enjoy ownership of their personal data, a right to privacy, and safety from harmful model outputs.
Pour ceux qui ne l'avaient pas encore compris, un LLM n'est pas une base de données. Impossible de ressortir de cette lecture sans s'interroger sur la possibilité réelle des personnes à faire valoir leurs droits sur leurs données personnelles dès lors qu'elles ont été avalées par une telle boite noire.
Cela n'a pas échappé à la CNIL, renseignée par ailleurs sur le problème – dans sa fiche n°10, elle pointe les articles Comprendre le désapprentissage machine : anatomie du poisson rouge, et Petite taxonomie des attaques des systèmes d'IA, de son laboratoire d'innovation numérique (LINC), par ailleurs tout à fait intéressants à lire :
La CNIL alerte les responsables de traitement sur le fait que ce constat n'est valable qu'au regard de l'état de l'art actuel, et qu'elle encourage activement la recherche et le développement de pratiques permettant de respecter l'exercice des droits et le principe de la protection des données dès la conception.
L'avenir s'annonce riche en contentieux...

DE LIMITER LE RISQUE À LIMITER LA PEUR DU RISQUE ?

Cela surprend toujours celui qui l'apprend, mais si l'on sait construire un LLM puis l'entraîner, l'on ne sait pas expliquer pourquoi il génère ce qu'il génère. L'interprétabilité, qui vise à le comprendre, est un domaine de recherche en soi, balbutiant qui plus est. A de rares exceptions – peut-être même une seule digne de ce nom, Anthropic, dont il a été question des fascinants travaux dans une précédente chronique –, les éditeurs de LLMs n'investissent pas là-dedans, préoccupés qu'ils sont par conquérir au plus vite des parts de marché.
On l'a dit et redit au fil des chroniques et articles publiés sur ce blog, et cela depuis le début : les LLMs sont de boîtes noires, et tant qu'ils le demeureront, ils ne seront pas sécurisés, n'étant peut-être même pas sécurisables. Partant, tout système d'IA générative qui se fonde dessus présentera le même problème, mais il faudra sans doute attendre une succession de scandales retentissants pour que chacun, des éditeurs de LLMs à ceux qui utilisent les systèmes basés dessus, en passant par ceux qui conçoivent ces systèmes, soient confrontés à leurs responsabilités.
Pour l'heure, c'est Whac-A-Mole. C'est inévitable, tout comme la chasse au zero days de nos systèmes en rien basés sur l'IA, mais il serait inconséquent que la sécurisation des systèmes d'IA générative se limite à cela. Evoquant la multiplication des travaux qui portent sur des techniques de défense des LLMs, les auteurs du papier sur la coercition d'un LLM cité plus tôt pointent l'intérêt de leur travail : "These emerging defenses are not the focus of this work, as we think it is prudent to first understand the space of possible attacks, rather than constructing defenses based on narrowly defined characteristics of current attacks". Bien dit.
Comme cela a été évoqué en reprenant d'ailleurs une mise en garde de l'ANSSI, les risques auxquels une organisation s'expose en prétendant concevoir et/ou déployer un tel système sont multiples, ne ressortissant pas seulement à la sécurité informatique – pour l'illustrer, l'on a notamment évoqué l'obligation de permettre aux personnes d'exercer leurs droits sur leurs données personnelles. A moins d'être incompétent, corrompu et/ou suicidaire, le DSI de toute organisation ne peut ressortir de la lecture des recommandations de l'ANSSI et de la CNIL que totalement circonspect, et n'envisager le recours à un système d'IA générative à base de LLM qu'au prix de la mise en œuvre d'un luxe de précautions dont l'inventaire ne peut que révéler l'ampleur considérable des coûts cachés, que les éditeurs de LLMs masquent derrière l'annonce de prix au token toujours plus dégressifs et décroissants.
Cette situation est d'autant plus inquiétante que ces éditeurs disposent de moyens considérables pour conduire simultanément plusieurs politiques pour rester maîtres du jeu :
  • La première, c'est la diffusion. Plus le temps s'écoule, plus leurs modèles sont utilisés – d'autant plus qu'ils sont ouvertement lâchés dans la nature au prétexte de le tester –, si bien qu'il devient irréaliste de réguler car cela reviendrait à remettre en cause de trop nombreuses activités, souvent transformées de manière irréversible, et cela d'autant plus que la technologie est implantée profondément dans les systèmes, jusqu'au hardware – par exemple, la nouvelle gamme de PC Copilot+ de Microsoft comprend un NPU, et avant que Recall ne fasse scandale, comme rapporté dans notre Chronique de l'IA #7, la fonctionnalité était activée par défaut dans l'OS.
  • La deuxième, c'est la régulation. Comme signalé dans notre Chronique de l'IA #6, fin avril, Time rapportait que si les éditeurs de LLMs font un lobbying extraordinaire auprès des législateurs américains, c'est publiquement pour leur faire adopter une régulation, mais en privé, pour qu'elle soit la moins contraignante possible. C'est de bonne guerre, ce petit jeu a d'ailleurs déjà été joué en Europe : dans notre Chronique de l'IA #3, l'on signalait que fin novembre, Euractiv rapportait comment l'ancien secrétaire Cédric O, co-fondateur de Mistral AI, avait fait pression avec le soutien du gouvernement français pour que le RIA reconnaisse un statut particulier aux "modèles d'IA à usage général".
  • La troisième, c'est l'acceptation, pour ne pas dire la résignation - mais cela impliquerait que les gens sachent de quoi il en retourne, ce à quoi évidemment rien n'est fait pour les éduquer. C'est un peu l'aboutissement des deux politiques précédentes, et elle n'a pas vraiment fait parler d'elle jusqu'alors tant elle peut paraître polémique, mais cela commence. Ainsi, en réponse à l'exploitation de Cygnet par Pliny the Prompter, Zico Kolter, Chief Technical Advisor de Gray Swan AI, a posté sur X un long message où il évoque trois excuses. Les deux premières sont désormais rituelles : (1) si le modèle a été diffusé, c'est justement pour être testé, et cela parce que par ailleurs (2) aucun modèle n'est parfait. La dernière, c'est (3) qu'il va falloir faire avec, car ce serait l'ordre naturel des choses.
En tant qu'elle constitue un aboutissement, la troisième politique est d'une importance capitale, et pour que cela soit bien compris, il convient de citer Zico Kolter in extenso :
Third, and this is maybe the most controversial point, I think that for now it's reasonable to talk about degrees of AI safety and security. This is the standard in software, where many systems are known to be likely exploitable by an adversary with sufficient resources, but the goal is to constantly react/patch to make the system secure to practical threats. This is why we used the language of Cygnet being “more secure” than other models, even when it's clearly breakable.
Vouloir introduire la notion de "degrees of AI safety" n'est pas déraisonnable. Après tout, c'est dire qu'il faut réfléchir aux risques que présentent un système à partir de sa finalité et non de sa nature, ce qui fait que l'on peut autoriser l'usage du feu pour faire rôtir un poulet, mais pas pour décongeler du TNT, sans quoi l'on interdirait le feu au prétexte qu'il peut brûler.
D'ailleurs, en Europe, c'est au cœur du RIA, qui distingue les systèmes d'IA en fonction du niveau de risque pour mieux cibler ceux qui sont à "haut risque". Après, l'on peut se demander si le régulateur avait alors bien compris que personne n'avait compris comment un LLM fonctionne, et anticipé que personne ne le comprendrait encore bientôt deux ans après l'apparition de ChatGPT. Toutefois, c'est une autre question, et quand bien même le régulateur l'aurait ignorée, elle est inéluctablement condamnée à être posée et réglée sur le terrain – comme on l'a vu, l'ANSSI pointe le problème que pose la propension d'un LLM à halluciner, lequel problème n'en serait pas un... si l'on savait pourquoi le LLM hallucine !
Pour autant, pour en revenir à Cygnet, il faut tout de même rappeler de quoi l'on parle. N'est-ce pas d'un chat à base d'un LLM dont il est question, que de plus son éditeur a prétendu plus sécurisé que les autres ? La démonstration de Pliny the Prompter est tout de même fatale, et vouloir en diminuer la portée, pour le moins audacieux. Après, il n'est de couleuvre assez grosse qu'un bon commercial ne tente de faire avaler – au pire, comme nous l'a enseigné Jean-Paul Dusse, "on sait jamais, sur un malentendu, ça peut marcher". Dans ces conditions, il faut s'attendre à ce que d'autres éditeurs de LLMs, et plus généralement de systèmes d'IA générative à base de LLM, reprennent l'argument à leur compte.