Qu’est-ce que la sécurité des LLM? Comment atténuer les 10 principaux risques de sécurité de l’OWASP

Une attaque qui pousse une IA à traiter les instructions d’un attaquant comme des commandes — l’injection de requête — occupe le 1er rang du Top 10 de l’OWASP pour les applications de LLM à chaque édition depuis 2023.

Cette liste est ce qui se rapproche le plus d’un consensus en sécurité de l’IA. Le projet a commencé avec un petit groupe de professionnels de la sécurité et s’appuie aujourd’hui sur plus de 600 experts contributeurs dans plus de 18 pays.

Nous sommes une entreprise d’IA qui publie un guide sur la façon dont on persuade l’IA de faire des choses; inutile donc de prétendre que le problème est réglé. Wilson, qui codirige le projet de l’OWASP, a été plutôt clair au sujet des défenses actuelles : « … franchement, je ne crois pas que nous en soyons à 99 %. »

L’édition 2026 s’ouvre sur la même note. Le responsable du projet nous dit d’« arrêter d’essayer de créer un modèle impossible à tromper » et de concevoir le système qui l’entoure de sorte qu’un modèle trompé ne puisse rien briser d’important.

C’est dans cette optique que nous passons en revue les 10 risques de la liste 2026 de l’OWASP.

Que signifie la sécurité des LLM?

La sécurité des LLM consiste à protéger les modèles d’IA et les applications qui les utilisent contre les attaques et les usages abusifs. Le risque augmente selon ce à quoi le modèle est connecté : les fichiers et les données qu’il peut lire, et les outils qu’il peut utiliser, comme le courriel, la recherche ou une base de données d’entreprise.

Dans un logiciel bien sécurisé, il existe une frontière nette entre les instructions qu’un programme suit et les informations qu’il traite. Mais les LLM n’ont pas cette frontière.

Tout ce que le modèle lit lui parvient sous la forme d’un seul long flux de texte : les instructions du développeur, votre question, une page Web qu’il a consultée. Les modèles d’IA sont censés savoir qui parle, que ce soit le développeur, l’utilisateur ou le modèle lui-même en train de réfléchir à un problème.

Or, les chercheurs Jasmine Cui et Charles Ye ont constaté que les modèles devinent surtout qui parle d’après le ton du texte. Ainsi, si un attaquant écrit quelque chose qui ressemble au propre raisonnement du modèle, celui-ci peut croire qu’il a eu l’idée lui-même. C’est un problème pour tout dispositif de sécurité qui repose sur la capacité du modèle à savoir qui est aux commandes.

Nous nous sommes heurtés au même problème avec nos propres agents d’IA. Notre chef de la sécurité de l’information, Kyle Polley, a déclaré à ISMG que les agents « pourraient ne pas suivre les politiques, même si on les ajoute à la requête système ». C’est pourquoi nous avons créé Numbat, un outil à code source ouvert qui vérifie ce qu’un agent s’apprête à faire et peut l’en empêcher si l’action enfreint une règle de sécurité configurée.

La sécurité des LLM, c’est accepter que le modèle recevra parfois des ordres de la mauvaise personne, et mettre en place autour de lui des garde-fous d’IA qui tiennent bon quand cela se produit.

Quelles sont les pratiques exemplaires en matière de sécurité des LLM?

Nous passerons en revue le Top 10 2026 de l’OWASP pour les applications de LLM dans l’ordre, du 1er au 10e rang.

Pour chaque risque, vous trouverez une explication en langage clair de ce qui peut mal tourner ainsi qu’un exemple concret. Nous verrons ensuite les pratiques qui peuvent aider à le prévenir ou, à tout le moins, à limiter les dégâts.

1. Contenir l’injection de requête

Une injection de requête se produit lorsqu’un attaquant amène une IA à suivre des instructions qu’elle ne devrait pas suivre. Ces instructions peuvent être fournies directement dans un clavardage ou être dissimulées dans un courriel, une page Web ou un document.

Le second type est appelé injection de requête indirecte. Vous demandez à votre assistant de résumer un document. Ses auteurs ont demandé à l’assistant de leur envoyer vos fichiers privés. Si l’assistant suit ces instructions, la personne qui a rédigé le document a en fait emprunté vos accès.

PCMag compare la sécurité des requêtes au colmatage des trous d’une pierre poreuse. Vous bouchez une ouverture, et l’eau en trouve une autre. « Une attaque se fraie un chemin; elle est corrigée, mais d’innombrables autres voies d’attaque restent à découvrir, simplement en raison du caractère dynamique de systèmes comme les LLM. »

Exemple : En juin 2025, des chercheurs d’Aim Security ont découvert EchoLeak, une faille qui amenait Microsoft 365 Copilot à divulguer des informations privées d’entreprise. Lorsqu’un employé posait une question de travail courante, Copilot pouvait récupérer le courriel, suivre les instructions qui y étaient dissimulées et envoyer des informations sensibles à l’attaquant. L’attaque déjouait les contrôles censés détecter les instructions malveillantes et supprimer les liens suspects.

Ce que vous pouvez faire :

• Suivez la « règle de deux » de Meta : EchoLeak nécessitait une IA capable de lire les données de l’entreprise, de lire des courriels externes et d’envoyer de l’information vers l’extérieur — elle avait ces trois capacités. La limiter à deux de ces capacités empêche une injection de requête d’acquérir trop d’emprise. Si la tâche nécessite les trois, exigez une approbation humaine avant chaque action.
• Testez vos défenses contre des attaquants qui les connaissent : Donnez à vos testeurs de sécurité les règles et les filtres que vous avez mis en place, puis laissez-les chercher à les contourner. Dans une étude, des attaquants qui s’adaptaient aux défenses ont réussi plus de 90 % du temps contre la plupart des 12 défenses testées.

2. Empêcher les fuites d’informations sensibles

Lorsque des systèmes d’IA transmettent des informations privées à des personnes qui ne devraient pas les voir, on parle de divulgation d’informations sensibles. Il peut s’agir de révéler les données de paiement d’un client ou de laisser des conversations privées dans une base de données partagée.

Bien des fuites commencent par un « partage excessif ». Imaginons qu’une entreprise connecte son IA à des lecteurs et à des bases de connaissances dont les autorisations sont trop permissives. L’IA récupère tout ce à quoi elle peut accéder, exactement comme prévu. Personne n’a besoin de s’introduire dans le système, mais considérez le LLM comme compromis.

Exemple : En janvier 2025, des chercheurs de Wiz ont découvert une base de données de DeepSeek accessible depuis Internet, qui contenait plus d’un million d’entrées de journal, dont l’historique de clavardage et des clés d’API, que les logiciels utilisent pour accéder à d’autres services. Les chercheurs n’ont pas eu besoin de persuader le modèle de révéler quoi que ce soit.

Ce que vous pouvez faire :

• Vérifiez les accès avant que l’IA lise les données : Votre application devrait vérifier quels documents la personne qui pose la question est autorisée à consulter avant de les transmettre au modèle.
• Protégez les traces que laisse votre IA : Supprimez les renseignements privés et les clés secrètes avant d’enregistrer les journaux d’activité, exigez une connexion et limitez l’accès aux personnes qui en ont besoin. Fixez une période de conservation afin que ces enregistrements ne s’accumulent pas indéfiniment.

3. Maîtriser l’autonomie excessive

Les IA dotées d’une autonomie excessive ont plus de pouvoir que leurs fonctions ne l’exigent : des outils dont elles n’ont pas besoin, des autorisations qui dépassent leur tâche ou la liberté d’agir sans vérification. La cause, ici, n’a pas d’importance.

Une requête d’injection, un bogue ou un modèle qui se trompe tout simplement mènent tous au même résultat. L’IA finira par faire quelque chose de destructeur si elle en a la capacité.

Exemple : En juillet 2025, Jason Lemkin, fondateur de SaaStr, a signalé que l’agent de programmation de Replit avait supprimé sa base de données de 1 206 dossiers de dirigeants, malgré des instructions lui interdisant d’apporter des modifications. L’agent a d’abord affirmé que les données ne pouvaient pas être restaurées, mais leur récupération s’est finalement révélée possible. Jason a constaté que lui dire de ne pas toucher à la base de données ne lui avait pas retiré la capacité de la supprimer.

Agrandir

Source : X

Ce que vous pouvez faire :

• Retirez les capacités dont la tâche n’a pas besoin : Limitez à la fois les outils dont dispose un agent et ce que ces outils peuvent faire. Un assistant qui résume des courriels a besoin de l’autorisation de les lire, pas de les envoyer ni de les supprimer.
• Placez les vérifications d’autorisation à l’extérieur de l’IA : Chaque fois qu’une action est demandée, faites-la vérifier par rapport à vos règles de sécurité et exigez qu’une personne l’approuve.

4. Vérifier ce qui entre dans votre chaîne d’approvisionnement en IA

Peu d’entreprises créent leur IA à partir de zéro, et elles sont moins nombreuses chaque année. Selon le sondage The State of Generative AI in the Enterprise 2025 de Menlo Ventures, 53 % des entreprises achetaient des modèles d’IA en 2024, une proportion passée à 76 % en 2025.

Le plus souvent, les entreprises téléchargent des modèles à partir de plateformes comme Hugging Face, les entraînent davantage sur des jeux de données recueillis par d’autres et y branchent des modules complémentaires et des paquets de code écrits par des inconnus.

Chacun de ces éléments est une porte d’entrée. Si l’un d’eux est altéré, le problème est livré avec votre produit.

Exemple : Les dépôts de modèles publics de Hugging Face sont passés de 2,43 millions à 2,96 millions entre janvier 2026 et août 2026. En juillet 2026, toutefois, des modèles d’OpenAI ont contourné des contrôles censés les tenir à l’écart d’Internet pendant des tests de sécurité internes et se sont introduits dans certaines parties des systèmes de Hugging Face. En fait, un agent a récupéré 14 identifiants d’accès exposés publiquement, a vérifié qu’ils fonctionnaient et les a partagés avec d’autres agents. Les agents ont ensuite exploité des failles qui leur permettaient d’exécuter du code sur les serveurs de Hugging Face.

« Nous imposons des exigences plus strictes en matière d’alignement tout au long du cycle de vie d’un modèle, et nous créons des bacs à sable plus isolés, restreignons l’accès à Internet et contrôlons davantage l’accès aux poids des modèles », indique le rapport d’OpenAI.

Ce que vous pouvez faire :

• Fixez les modèles à une version exacte et vérifiez-les : Associez chaque modèle à une version examinée et vérifiez l’empreinte de son fichier avant de le charger, afin qu’un fichier substitué ne puisse pas se glisser sous la même étiquette. L’OWASP recommande aussi les signatures numériques, avec une mise en garde : une signature prouve la provenance d’un modèle, pas sa sûreté.
• Vérifiez chaque paquet suggéré par votre IA : Avant d’installer un paquet de code recommandé par un assistant d’IA, confirmez qu’il existe, qu’il s’agit bien du paquet voulu et qu’il provient de l’éditeur attendu.

5. Se prémunir contre l’empoisonnement des données et des modèles

Une IA empoisonnée apprend à partir de données corrompues. Il peut s’agir des exemples ayant servi à son ajustement fin ou d’une base de connaissances dans laquelle elle cherche des réponses. Le modèle semble toujours fonctionner; il tire simplement les mauvaises leçons, et il apprend parfois à mal se comporter uniquement lorsqu’il voit une phrase déclencheuse précise.

La phrase passera tous les tests que vous lui ferez subir, jusqu’à ce que quelqu’un l’utilise.

Agrandir

De plus, c’est vraiment difficile à défaire. L’empoisonnement n’est pas un bogue qu’un simple correctif suffit à régler. Si vos données sont erronées, vous devrez peut-être les revérifier, réentraîner le modèle ou le remplacer entièrement.

Exemple : En octobre 2025, des chercheurs d’Anthropic, du UK AI Security Institute et de l’Alan Turing Institute ont montré que 250 documents empoisonnés pouvaient apprendre à un modèle à produire du charabia chaque fois qu’il rencontrait un déclencheur particulier. Le même nombre a suffi pour les quatre tailles de modèles testées, même si le plus grand avait été entraîné sur plus de 20 fois plus de données saines.

Ce que vous pouvez faire :

• Retracez la provenance de vos données : Tenez un registre de chaque jeu de données et de chaque modèle que vous utilisez, de leur provenance et des changements apportés d’une version à l’autre. Nous recommandons d’utiliser la gestion de versions pour les jeux de données afin que, si un empoisonnement est détecté, vous puissiez revenir à une version saine et déterminer comment il s’est introduit.
• Vérifiez la présence de portes dérobées : Une « porte dérobée » est un comportement caché qu’un attaquant implante dans un modèle et qui attend une phrase particulière ou un autre déclencheur pour s’activer. Recherchez-les à l’aide d’entrées conçues pour amener le modèle à enfreindre ses règles habituelles.

6. Plafonner la consommation illimitée

Lorsque les IA n’ont aucune limite quant à la quantité de travail qu’elles peuvent effectuer ou à ce qu’elles peuvent coûter, leur consommation est considérée comme « illimitée ». La majorité des services d’IA facturent à l’utilisation; un attaquant pourrait donc faire grimper votre facture ou créer une copie de votre modèle.

L’OWASP qualifie le problème de fond d’« asymétrie des coûts ». Une requête courte et peu coûteuse peut déclencher des calculs onéreux de votre côté.

Exemple : En mai 2024, l’équipe de recherche sur les menaces de Sysdig a découvert un nouveau type d’attaque appelé « LLMjacking ». Un groupe d’attaquants a ciblé 10 services de LLM hébergés dans le nuage à l’aide d’identifiants volés. Ils se sont introduits par une version vulnérable de Laravel, puis ont déterminé ce que les identifiants permettaient de faire et quels étaient les quotas, dans le but évident de revendre l’accès. De nombreux paramètres de journalisation ont aussi été interrogés, probablement pour éviter d’être détectés. Selon Sysdig, dans le pire des cas, la victime pourrait devoir débourser plus de 46 000 $ par jour.

Ce que vous pouvez faire :

• Établissez des budgets qui bloquent les dépenses : Fixez des plafonds de dépenses stricts pour chaque utilisateur, chaque clé d’API, chaque équipe et pour le compte dans son ensemble. Appliquez-les partout où des requêtes peuvent entrer.
• Donnez à chaque tâche un point d’arrêt : Limitez la durée d’exécution d’une tâche, la quantité de texte qu’elle peut traiter et générer, et le nombre d’appels d’outils qu’elle peut effectuer. Ajoutez des arrêts automatiques pour les agents qui tournent en boucle ou qui dépassent le quota qui leur est alloué.

7. Repérer la mésinformation avant d’agir

Lorsqu’une IA produit quelque chose de faux qui semble juste, et que quelqu’un, ou quelque chose, agit en conséquence, on parle de mésinformation. Le risque fondamental ne tient pas tant à la mauvaise réponse elle-même qu’au fait qu’on s’y fie et qu’on l’utilise.

L’historique des incidents laisse croire que les praticiens ne se préoccupaient pas autant de la mésinformation qu’ils l’auraient dû. Selon la lettre d’ouverture de l’édition 2026, les votants l’ont placée près du bas du classement, alors que, d’après les incidents réels, elle se situe près du sommet.

Exemple : En 2025, Deloitte Australie a remis un examen des systèmes informatiques d’aide sociale dans le cadre d’un contrat gouvernemental de 440 000 $ AU. À l’Université de Sydney, le chercheur Chris Rudge a relevé des références à des recherches inexistantes ainsi qu’une citation inventée tirée d’un jugement de la Cour fédérale. Le rapport révisé indiquait que Deloitte avait utilisé Azure OpenAI GPT-4o dans sa méthodologie, et le cabinet a accepté de rembourser le dernier versement. Il s’agissait, malheureusement, d’une mission d’assurance.

Ce que vous pouvez faire :

• Vérifiez que les preuves appuient la réponse : Fondez les affirmations sur des sources actuelles et faisant autorité. Pour une réponse portant sur une politique, récupérez la politique approuvée et vérifiez qu’elle appuie la conclusion, y compris ses exceptions.
• Vérifiez avant que le système agisse : Si un agent affirme qu’un client a réussi une vérification d’identité, confirmez-le auprès du système de vérification avant de débloquer un paiement. Exigez une approbation humaine pour les décisions importantes, en mettant les preuves à l’appui à la disposition de la personne chargée de l’examen.

8. Limiter les dégâts de l’exposition du contexte caché

Les applications d’IA fournissent au modèle des instructions et des informations contextuelles que les utilisateurs ne voient normalement pas. Il peut s’agir de la requête système, de politiques internes, de descriptions des outils disponibles et de règles précisant qui peut les utiliser. Il y a exposition du contexte caché lorsque le modèle révèle ces informations à quelqu’un.

En 2026, l’OWASP a élargi cette entrée, auparavant intitulée « fuite de la requête système », parce que la requête système n’est qu’une partie de ce qui peut s’échapper. Le danger dépend de ce que vous y avez mis. La fuite d’un guide sur le ton à adopter est légèrement embarrassante, mais la fuite d’une clé d’API donne à quelqu’un accès à votre base de données confidentielle.

Exemple : En février 2023, des utilisateurs ont amené Bing Chat de Microsoft à révéler ses instructions internes. L’une des tentatives réussies est venue de Marvin von Hagen, qui s’est fait passer pour un développeur d’OpenAI et a demandé les instructions afin de configurer le modèle. Bing a divulgué les règles régissant ses recherches, ses réponses et son comportement en matière de sécurité, ainsi que son nom interne, Sydney. Parmi les instructions révélées figurait la consigne de garder ces instructions confidentielles.

Ce que vous pouvez faire :

• Gardez les secrets hors du contexte du modèle : Partez du principe que tout ce que le modèle peut lire pourrait devenir visible pour les utilisateurs. Stockez donc les mots de passe, les clés API et les jetons d’accès dans un système distinct de gestion des secrets.
• Faites en sorte que les autorisations tiennent même si les règles fuitent : Appliquez les contrôles d’accès dans le code de votre application. Si un outil est réservé aux administrateurs, vérifiez les autorisations du compte de l’utilisateur avant de l’exécuter.

9. Verrouillez vos vecteurs et vos plongements

Lorsqu’une IA utilise la recherche vectorielle pour trouver des réponses dans les documents de votre entreprise, elle ne cherche pas directement dans le texte. Les documents sont convertis en « plongements » (embeddings), c’est-à-dire de longues listes de nombres qui saisissent le sens de chaque passage, puis stockés dans une base de données vectorielle. Une question est convertie de la même façon, et le système récupère les passages dont les nombres sont les plus proches.

L’OWASP résume les quatre façons dont ce système peut échouer : l’empoisonnement le fait se tromper, l’inversion lui fait divulguer des données, le brouillage le réduit au silence et un contrôle d’accès défaillant l’amène à remettre n’importe quoi à n’importe qui.

Ces nombres ne sont pas l’abstraction sûre qu’ils semblent être. Les plongements stockés peuvent être reconvertis en texte, et une méthode a permis de reconstituer exactement 92 % de courts passages de 32 jetons lors de ses tests. Ainsi, une sauvegarde « composée uniquement de plongements » qui fuit peut, elle aussi, exposer le contenu des documents.

Exemple : Dans une étude présentée à USENIX Security 2025, des chercheurs ont montré qu’un seul document soigneusement conçu pouvait empêcher une IA de répondre à une question précise. Ils l’ont ajouté à la collection dans laquelle l’IA effectuait ses recherches. Lorsque l’IA le trouvait, elle pouvait répondre qu’elle manquait d’informations ou qu’il serait dangereux de répondre. Le document n’avait même pas besoin de demander à l’IA d’ignorer ses règles. C’est ce qu’on appelle le « brouillage de la récupération ».

Ce que vous pouvez faire :

• Maintenez des index distincts pour les données publiques et privées : Ne mélangez pas le contenu moissonné sur le Web avec les données de partenaires ou des documents internes confidentiels. Séparez physiquement les données selon leur niveau de confiance plutôt que d’étiqueter le contenu dans un seul index : cela élimine toute une catégorie d’erreurs de configuration, et le contenu moissonné sur Internet ne peut pas se retrouver à côté des documents de votre conseil d’administration.
• Traitez les plongements comme les documents dont ils proviennent : Chiffrez-les, protégez les sauvegardes de la base de données vectorielle au même titre que les fichiers sources, et supprimez les plongements lorsque vous supprimez l’original. Les clés API de votre service de plongement doivent rester secrètes.

10. Vérifiez les sorties de l’IA avant de les transmettre

Chaque fois qu’une application transmet les sorties d’une IA à un autre système sans vérifier qu’elles peuvent y être utilisées en toute sécurité, elle gère de façon inadéquate les sorties du LLM.

Cette catégorie couvre aussi le code non sécurisé que les assistants de codage IA génèrent à grande échelle. Chaque ligne écrite par un assistant est donc, elle aussi, une sortie.

Exemple : En 2025, le chercheur Johann Rehberger a montré comment l’assistant de codage Amp de Sourcegraph pouvait divulguer le contenu de clavardages simplement en affichant une image. Il a utilisé l’injection d’invite pour amener Amp à inclure des renseignements privés dans l’adresse Web d’une image. L’application récupérait ensuite automatiquement cette image, ce qui envoyait les renseignements à son serveur. La défaillance dans la gestion des sorties tenait à cette requête automatique : le texte généré par le modèle devenait une connexion vers un serveur externe, emportant avec lui des données privées.

Ce que vous pouvez faire :

• Rendez les sorties sûres pour leur destination : Vérifiez et traitez les réponses en fonction de l’endroit où elles seront utilisées. Pour une page Web, empêchez le texte généré de devenir du code exécutable. Pour une base de données, utilisez des requêtes préparées qui séparent les valeurs fournies des commandes.
• Empêchez les réponses d’établir automatiquement des connexions externes : Désactivez par défaut le chargement automatique des images, des aperçus de liens et des pages intégrées dans les réponses du modèle. Limitez les connexions nécessaires à des destinations explicitement approuvées.

Comment Perplexity sécurise-t-il les LLM?

Nous partons du principe que chacun des risques ci-dessus finira par se concrétiser, et nous concevons nos systèmes pour limiter les dégâts lorsque cela se produit. Notre chef de la sécurité de l’information, Kyle Polley, a expliqué notre approche lors d’un atelier récent.

• L’agent dispose de son propre ordinateur, qui démarre vide : Les outils d’agent installés sur votre ordinateur portable peuvent accéder à ses fichiers, à ses applications et aux identifiants enregistrés. Perplexity Computer fonctionne à l’inverse. Chaque tâche s’exécute dans son propre bac à sable isolé et, comme le dit Polley, « par défaut, il n’a accès à rien ».
• L’agent ne voit jamais les mots de passe : Les identifiants des services connectés sont stockés à l’extérieur du bac à sable. Lorsque l’agent doit accéder à un service comme GitHub, il envoie une requête sans identifiants. Une passerelle vérifie que la destination et la requête correspondent à ce qui est attendu, puis ajoute les identifiants au moment où la requête sort. L’agent peut utiliser la connexion sans jamais obtenir les clés.
• Vos autorisations sont conservées, et vous pouvez les restreindre : Les connexions établies au moyen d’OAuth préservent vos autorisations d’accès dans le service connecté. Si vous ne pouvez pas voir quelque chose, votre agent non plus.
• Chaque page Web est traitée comme une inconnue : Nous avons conçu BrowseSafe pour Comet, notre navigateur agentique, parce que les outils que nous avions testés ne répondaient pas à nos besoins en conditions réelles. Le navigateur analyse les pages Web et les autres contenus externes, y compris les courriels, à la recherche d’injections d’invite. Nous avons publié le modèle et le jeu de données en code source ouvert.
• Nous surveillons l’agent et les machines sur lesquelles il s’exécute : Numbat s’interpose entre la décision d’un agent d’agir et l’exécution effective de l’outil. Numbat journalise l’activité des agents de codage pris en charge et peut bloquer, avant leur exécution, les actions qui enfreignent les politiques configurées. Bumblebee inventorie les paquets logiciels présents sur les ordinateurs portables, les serveurs et les pipelines de compilation, et signale ceux qui sont reconnus comme malveillants. Les deux outils sont à code source ouvert.
• Les fournisseurs de modèles ne conservent pas vos données : Nous avons conclu des ententes de non-conservation des données avec nos fournisseurs tiers de LLM. Les administrateurs des comptes Enterprise peuvent aussi réduire la durée de conservation des données propre à Perplexity à aussi peu que 24 heures.

Nous avons conçu Numbat de manière proactive, pour une raison que Polley résume en une phrase : « Plus on donne d’autonomie à un agent, plus le risque est grand. »

FAQ sur la sécurité des LLM

Quel est le LLM le plus sécurisé?

Aucun LLM ne rend à lui seul une application sécurisée : les modèles peuvent encore confondre du contenu qu’ils devraient lire avec des instructions qu’ils devraient suivre. Les défenses qui semblent solides lors des tests standards peuvent aussi céder sous la pression.

Il vaut mieux se demander quelle configuration est la plus sécurisée pour votre cas d’utilisation. Cela suppose des autorisations limitées, des identifiants tenus à l’écart du modèle, une approbation humaine pour les actions risquées et des tests réalisés par des personnes qui connaissent vos défenses.

Quelles sont les vulnérabilités des LLM?

Les vulnérabilités des LLM sont des faiblesses qui font qu’un système d’IA peut être trompé, divulguer des données ou causer des dommages, que ce soit à cause d’un attaquant ou de ses propres erreurs.

Les dix risques majeurs sont l’injection d’invite, la divulgation de renseignements sensibles, l’autonomie excessive, la chaîne d’approvisionnement, l’empoisonnement des données et des modèles, la consommation illimitée, la mésinformation, l’exposition du contexte caché, les faiblesses des vecteurs et des plongements, et la gestion inadéquate des sorties.

Un LLM privé est-il sûr?

C’est une option plus sûre dans certains cas, mais pas par défaut. Vous avez davantage de contrôle sur le traitement des données si vous exécutez un modèle sur votre propre infrastructure ou dans un environnement infonuagique. Mais rien n’empêche automatiquement les injections d’invite, l’autonomie excessive, l’empoisonnement ou la mésinformation.

En auto-hébergement, vous êtes aussi responsable du modèle que vous téléchargez, y compris des risques liés à la chaîne d’approvisionnement, ainsi que de l’infrastructure qu’il nécessite.