Sécuriser les solutions d’IA générative

L’Open Web Application Security Project, ou OWASP, a publié la version 1 du Top 10 des risques et vulnérabilités pour les LLM et les applications d’IA générative. Le schéma ci-dessous illustre ces vulnérabilités dans le contexte d’une architecture d’IA agentique.

1. L’injection de prompt se produit lorsqu’un hacker parvient à injecter du contenu malveillant dans des prompts LLM. Le contenu peut être constitué de prompts/instructions intégrés dans un prompt de plus grande envergure, dans des hyperliens vers un contenu qui sera lu par le LLM (par exemple, « Lire et analyser le texte de l’URL suivante. »), ou par d’autres moyens. Une injection de prompt peut permettre à un hacker de manipuler le modèle pour qu’il ignore les instructions et/ou fournisse des productions indésirables ou erronées.
   
   
2. Un traitement non sécurisé des sorties survient lorsque les sorties d’un LLM ne sont pas suffisamment validées pour détecter un potentiel ou une intention malveillante. Voici des exemples de ce type de vulnérabilités : un LLM est invité à générer du code JavaScript qui est transmis au navigateur de l’utilisateur pour exécution, et l’exécution directe de scripts shell ou d’un autre code « système » généré par un LLM.
   
   
3. L’empoisonnement des données d’entraînement se produit lorsqu’un hacker est en mesure de modifier ou de manipuler les données d’entraînement et/ou de configuration d’un modèle afin d’y introduire des vulnérabilités. Par exemple, un acteur malveillant peut modifier la description d’un processus métier pour autoriser des transferts d’argent illimités vers une personne en particulier, ou lorsqu’un concurrent peut modifier les données d’optimisation afin que le modèle recommande ses produits plutôt que ceux de l’entreprise.
   
   
4. Un déni de service du modèle survient lorsqu’un hacker parvient à manipuler un modèle pour consommer une grande quantité de ressources, ce qui entraîne de mauvaises performances ou l’indisponibilité du modèle pour les autres utilisateurs. Parmi les exemples de déni de service des modèles, citons l’envoi répété de prompts dont la taille est inférieure à la taille de la fenêtre contextuelle du modèle, ce qui consomme une grande quantité de mémoire, ainsi que l’envoi de prompts qui amènent le modèle à développer et à traiter de manière récursive la fenêtre contextuelle (une boucle sans fin).
   
   
5. Les vulnérabilités de la chaîne d’approvisionnement sont à la fois les vulnérabilités typiques associées à l’utilisation de logiciels tiers pouvant contenir des vulnérabilités inconnues exploitables par un hacker, ainsi que les vulnérabilités créées par des modèles utilisant des données non vérifiées et/ou collectées participativement lors de leur processus d’entraînement.
   
   
6. La divulgation d’informations sensibles se produit lorsqu’un modèle divulgue des informations sensibles ou personnelles. Cela peut survenir à la suite d’une attaque d’injection de prompt réussie résultat d’une gestion non sécurisée des sorties système d’entreprise, ou à cause de prompts malveillants qui manipulent le modèle pour produire des sorties sensibles, comme des numéros de carte bancaire valides.
   
   
7. La conception de plug-in non sécurisée se produit lorsque les outils appelés directement par les modèles ne sont pas conçus de manière sécurisée ; par exemple, des outils fonctionnant en tant qu’utilisateur administratif, ou des outils qui permettent une injection de prompt via leurs sorties.
   
   
8. On parle d’excès d’autonomie lorsqu’un modèle ou un agent autonome a la capacité d’effectuer des actions dommageables ou non autorisées en réponse à des résultats inattendus ou ambigus d’un LLM.
   
   
9. On parle d’excès de dépendance lorsque l’exactitude des résultats d’un modèle n’est pas vérifiée par rapport à des sources factuelles ou à des contrôles procéduraux. L’exemple le plus courant d’excès de dépendance survient lorsqu’un modèle hallucine et que la sortie erronée est acceptée comme factuelle ; un chatbot fournissant une réponse incorrecte à un client sur la politique de retour d’un magasin, par exemple. En revanche, un excès de dépendance peut également se produire avec du code ou des images générés par le modèle.
   
   
10. Le vol de modèles se produit lorsqu’un hacker parvient à compromettre, à voler physiquement ou à copier un modèle, ses pondérations et/ou ses paramètres. Une fois en possession d’un modèle, un hacker peut tirer parti de la propriété intellectuelle précieuse intégrée dans le modèle ou créer un doublon du modèle pour son propre usage.
     

La figure ci-dessous complète l’architecture pour montrer l’emplacement des composants de sécurité destinés à protéger ou à atténuer les vulnérabilités du Top 10 de l’OWASP.

Un composant de gestion des identités et des accès (IAM) est ajouté pour fournir des identités et des rôles utilisateur solides. Le risque de vol de modèles est ainsi limité grâce au contrôle de l’accès aux fonctionnalités de l’application et aux API qui pourrait autrement entraîner un vol ou une divulgation de modèles.

L’identification et le contrôle d’accès des agents (Agent Access Control), qui fonctionnent de manière similaire à l’utilisateur privilégié, sont ajoutés pour faire correspondre les droits d’accès des agents aux identités et aux rôles des utilisateurs, se protégeant ainsi contre l’excès d’autonomie et les actions anormales des agents résultant d’hallucinations ou de prompts mal formés ou ambigus.

Des composants de surveillance de l’IA générative(GenAI Monitoring) sont ajoutés à l’ensemble de l’architecture pour se prémunir contre l’injection de prompt, le traitement non sécurisé des sorties, la divulgation de données sensibles et l’excès de dépendance. Une combinaison de surveillance d’IA générative et de surveillance traditionnelle des fuites de données est déployée pour empêcher les attaques basées sur les prompts/réponses, par exemple un prompt injecté dans les résultats d’une requête SQL, ainsi que contre la divulgation d’informations sensibles pouvant apparaître dans les résultats d’appels d’API, de requêtes de base de données, etc.

Les attaques par empoisonnement des données d’entraînement sont atténuées grâce à l’ajout d’outils de gestion de la configuration et de surveillance, ainsi que par un processus structuré de contrôle de version et de publication en lien avec l’entraînement, le réglage fin et les données de configuration du modèle.

Enfin, un composant de surveillance intégrée du comportement et de corrélation d’événements est ajouté pour identifier les vulnérabilités et les attaques potentielles à partir des journaux des composants individuels. Un composant de notification et d’alerte est ajouté pour informer les opérateurs du système des problèmes potentiels. De même, un composant d’orchestration des réponses est ajouté pour automatiser et/ou coordonner les réponses du système et les réponses manuelles aux problèmes identifiés.