Cadres légaux applicables
Québec
Article 10 (mesures de sécurité), article 3.5 (incidents de confidentialité)
Loi québécoise sur la protection des renseignements personnels en vigueur depuis le 22 septembre 2023, encadrant la collecte, l'utilisation, la communication et la conservation des renseignements personnels par les entreprises et organismes publics. Inclut des obligations sur la prise de décision automatisée (article 12.1).
International
A.6 (gestion des risques), A.10 (sécurité)
Norme certifiable décrivant les exigences pour mettre en place un système de management de l'IA. Pertinente pour les démarches de certification volontaire.
Manage 4.2
Cadre volontaire de gestion des risques d'IA structuré autour de quatre fonctions : Govern, Map, Measure, Manage. Référence courante en gouvernance d'IA.
UE
Article 15 (cybersécurité)
Règlement européen établissant un cadre harmonisé pour l'IA, fondé sur une approche par risque (risque inacceptable, élevé, limité, minimal). Pertinent pour les organisations québécoises faisant affaire en UE.
Exemples sectoriels québécois
Banque et assurance
Un attaquant exploite une injection de prompt dans un agent IA exposé aux clients d'une coopérative financière pour extraire les instructions système et lister les fonctions internes.
Manufacturier
Une chaîne de production équipée de modèles de vision est trompée par des autocollants adversariaux qui font passer des pièces défectueuses pour conformes.
Mitigations recommandées
- 2.1Sécurité des modèles et de l'infrastructure
Garde-fous techniques et physiques qui sécurisent les modèles d'IA, leurs poids et l'infrastructure pour prévenir l'accès non autorisé, le vol, l'altération et l'espionnage.
- 2.3Ingénierie de sûreté des modèles
Méthodes techniques et garde-fous qui encadrent les comportements des modèles et les protègent contre l'exploitation et les vulnérabilités.
- 3.1Tests et audits
Évaluations internes et externes systématiques qui examinent les systèmes d'IA, l'infrastructure et les processus de conformité pour identifier les risques, vérifier la sûreté et s'assurer que la performance respecte les normes.
- 3.6Réponse et reprise en cas d'incident
Protocoles et systèmes techniques qui répondent aux incidents de sécurité, aux défaillances de sûreté ou aux usages abusifs des capacités afin de contenir les préjudices et de rétablir des opérations sûres.
- 4.3Signalement des incidents
Processus et protocoles formels qui documentent et partagent les incidents de sûreté de l'IA, les brèches de sécurité, les quasi-incidents et les renseignements de menaces pertinents avec les parties prenantes appropriées pour permettre des réponses coordonnées et des améliorations systémiques.
Risques documentés (112)
Entrées du AI Risk Repository (MIT) classées dans ce sous-domaine. Contenu original en anglais.
112 entrées
02.03.04Vulnérabilités logicielles
« Les programmeurs sont habitués à utiliser des outils de génération de code, tels que Github Copilot, pour le développement de programmes, ce qui peut dissimuler des vulnérabilités dans le programme. »
02.04.00Problèmes de sécurité logicielle
« La chaîne d'outils de développement logiciel des LLM est complexe et pourrait présenter des menaces pour le LLM développé. »
02.04.01Langage de programmation
« La plupart des LLM sont développés en utilisant le langage Python, tandis que les vulnérabilités des interpréteurs Python posent des menaces aux modèles développés. »
02.04.02Frameworks de deep learning
Les LLM sont mis en œuvre à l'aide de frameworks de deep learning. Il est à noter que diverses vulnérabilités dans ces frameworks ont été révélées ces dernières années. Selon les rapports des cinq dernières années, les trois types de vulnérabilités les plus courants sont les attaques par dépassement de tampon (buffer overflow), la corruption de mémoire et les problèmes de validation des entrées.
02.04.03Chaînes d'approvisionnement logicielles
La chaîne d'outils de développement logiciel des LLM est complexe et pourrait présenter des menaces pour le LLM développé.
02.04.04Outils de prétraitement
Les outils de prétraitement jouent un rôle crucial dans le contexte des LLM. Ces outils, souvent impliqués dans des tâches de vision par ordinateur (CV), sont vulnérables aux attaques qui exploitent les failles de sécurité dans des outils comme OpenCV.
02.05.00Vulnérabilités matérielles
Les vulnérabilités des systèmes matériels utilisés pour l'entraînement et l'inférence posent des problèmes aux applications basées sur les LLM.
02.05.01Appareils réseau
L'entraînement des LLM repose souvent sur des systèmes de réseau distribués [171], [172]. Lors de la transmission des gradients via les liens entre les nœuds de serveurs GPU, un trafic volumétrique important est généré. Ce trafic peut être sujet à des perturbations causées par un trafic en rafale, comme les attaques pulsées [161]. De plus, les frameworks d'entraînement distribué peuvent rencontrer des problèmes de congestion [173].
02.05.02Plateformes de calcul GPU
L'entraînement des LLM nécessite d'importantes ressources GPU, ce qui introduit une préoccupation de sécurité supplémentaire. Des attaques par canal auxiliaire (side-channel attacks) sur GPU ont été développées pour extraire les paramètres des modèles entraînés [159], [163].
02.05.03Mémoire et stockage
À l'instar des programmes conventionnels, les infrastructures matérielles peuvent également introduire des menaces pour les LLM. Les vulnérabilités liées à la mémoire, telles que les attaques rowhammer [160], peuvent être exploitées pour manipuler les paramètres des LLM, donnant lieu à des attaques comme l'attaque Deephammer [167], [168].
02.06.00Problèmes liés aux outils externes
Les outils externes (par exemple, les API web) présentent des problèmes de fiabilité et de confidentialité pour les applications basées sur les LLM.
02.06.01Erreurs factuelles injectées par des outils externes
Les outils externes incorporent généralement des connaissances supplémentaires dans les prompts d'entrée [122], [178]–[184]. Ces connaissances supplémentaires proviennent souvent de ressources publiques telles que les API web et les moteurs de recherche. Comme la fiabilité des outils externes n'est pas toujours garantie, le contenu retourné par ces outils peut inclure des erreurs factuelles, amplifiant ainsi le problème d'hallucination.
02.06.02Exploitation d'outils externes pour des attaques
Les fournisseurs d'outils adverses peuvent intégrer des instructions malveillantes dans les API ou les prompts [84], ce qui amène les LLM à divulguer des renseignements sensibles mémorisés dans les données d'entraînement ou les prompts des utilisateurs (CVE2023-32786). En conséquence, les LLM n'ont aucun contrôle sur la sortie, ce qui entraîne la divulgation de renseignements sensibles aux fournisseurs d'outils externes. De plus, les attaquants peuvent facilement manipuler les données publiques pour lancer des attaques ciblées, générant des sorties malveillantes spécifiques en fonction des entrées de l'utilisateur. Par ailleurs, l'introduction d'informations provenant d'outils externes dans les LLM peut entraîner des attaques par injection [61]. Par exemple, des entrées non vérifiées peuvent entraîner l'exécution de code arbitraire (CVE-2023-29374).
02.10.00Attaques de modèles
Les attaques de modèles exploitent les vulnérabilités des LLM, visant à voler des informations précieuses ou à entraîner des réponses incorrectes.
02.10.01Attaques par extraction
Les attaques par extraction [137] permettent à un adversaire d'interroger un modèle victime de type « boîte noire » et de construire un modèle de substitution en s'entraînant sur les requêtes et les réponses. Le modèle de substitution pourrait atteindre presque les mêmes performances que le modèle victime. Bien qu'il soit difficile de répliquer entièrement les capacités des LLM, les adversaires pourraient développer un modèle spécifique à un domaine qui tire des connaissances du domaine des LLM.
02.10.02Attaques par inférence
Les attaques par inférence [150] incluent les attaques par inférence d'appartenance, les attaques par inférence de propriété et les attaques par reconstruction de données. Ces attaques permettent à un adversaire d'inférer la composition ou les informations de propriété des données d'entraînement. Des travaux antérieurs [67] ont démontré que les attaques par inférence pouvaient facilement fonctionner dans les PLM précédents, ce qui implique que les LLM peuvent également être attaqués.
02.10.03Attaques par empoisonnement
Les attaques par empoisonnement [143] pourraient influencer le comportement du modèle en apportant de petits changements aux données d'entraînement. Un certain nombre d'efforts pourraient même exploiter des techniques d'empoisonnement de données pour implanter des déclencheurs cachés dans les modèles pendant le processus d'entraînement (c'est-à-dire, les attaques par porte dérobée, backdoor attacks). De nombreux types de déclencheurs dans les corpus de texte (par exemple, caractères, mots, phrases et syntaxe) pourraient être utilisés par les attaquants.
02.10.04Attaques par surcharge
Les attaques par surcharge [146] sont également appelées attaques énergie-latence. Par exemple, un adversaire peut concevoir des exemples « éponge » (sponge examples) soigneusement élaborés pour maximiser la consommation d'énergie dans un système d'IA. Par conséquent, les attaques par surcharge pourraient également menacer les plateformes intégrées aux LLM.
02.10.05Nouvelles attaques contre les LLM
Tableau d'exemples: « Prompt Abstraction Attacks [147]: Abstraire les requêtes pour réduire les coûts en utilisant l'API d'un LLM. Reward Model Backdoor Attacks [148]: Construire des déclencheurs de porte dérobée sur le processus RLHF d'un LLM. LLM-based Adversarial Attacks [149]: Exploiter les LLM pour construire des échantillons pour les attaques de modèles. »
02.10.06Attaques par évasion
Les attaques par évasion [145] visent à provoquer des changements significatifs dans la prédiction d'un modèle en ajoutant des perturbations aux échantillons de test pour construire des exemples adversariaux. Plus précisément, les perturbations peuvent être mises en œuvre sur la base de changements de mots, de gradients, etc.
Évaluez ce risque pour votre cas d'usage
Notre wizard d'évaluation des risques arrive prochainement.