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 prompt — occupe la première place du Top 10 OWASP pour les applications LLM dans chaque édition depuis 2023.

Cette liste est sans doute ce qui se rapproche le plus d’un consensus en matière de sécurité de l’IA. Le projet a débuté avec un petit groupe de professionnels de la sécurité et s’appuie désormais sur plus de 600 experts contributeurs dans plus de 18 pays.

Nous sommes une entreprise d’IA qui publie un guide sur la manière dont on parvient à manipuler l’IA : nous ne ferons donc pas semblant que le problème est résolu. Wilson, qui codirige le projet OWASP, a été plutôt clair au sujet des défenses actuelles : « ... franchement, je ne pense pas que nous en soyons à 99 %. »

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

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

Que recouvre 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 avec 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 la messagerie, la recherche ou une base de données d’entreprise.

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

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, qu’il s’agisse du développeur, de l’utilisateur ou du modèle lui-même en train de réfléchir à un problème.

Mais les chercheurs Jasmine Cui et Charles Ye ont constaté que les modèles devinent surtout qui parle d’après la tonalité 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 avons rencontré le même problème avec nos propres agents d’IA. Notre RSSI, Kyle Polley, a déclaré à ISMG que les agents « pourraient ne pas respecter les politiques même si on les ajoute au prompt système ». C’est pourquoi nous avons créé Numbat, un outil open source qui vérifie ce qu’un agent s’apprête à faire et peut le bloquer si l’action enfreint une règle de sécurité configurée.

La sécurité des LLM consiste à accepter que le modèle recevra parfois des ordres de la mauvaise personne, et à l’entourer de garde-fous d’IA qui tiennent bon même dans ce cas.

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

Nous allons passer en revue le Top 10 OWASP 2026 pour les applications LLM dans l’ordre, du n° 1 au n° 10.

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

1. Contenir l’injection de prompt

Une injection de prompt se produit lorsqu’un attaquant amène une IA à suivre des instructions qu’elle ne devrait pas suivre. Ces instructions peuvent arriver directement dans une conversation ou être dissimulées dans un e-mail, une page web ou un document.

Le second type est appelé injection de prompt indirecte. Vous demandez à votre assistant de résumer un document. Ses auteurs y ont glissé une consigne demandant à l’assistant de leur envoyer vos fichiers privés. Si l’assistant suit ces instructions, la personne qui a rédigé le document s’est de fait approprié vos accès.

PCMag compare la sécurité des prompts au colmatage des trous d’une pierre poreuse. Vous bouchez une ouverture, et l’eau en trouve une autre. « Une attaque parvient à passer ; 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 confidentielles de l’entreprise. Lorsqu’un employé posait une question professionnelle de routine, Copilot pouvait récupérer l’e-mail, suivre les instructions qui y étaient cachées et envoyer des informations sensibles à l’attaquant. L’attaque parvenait à contourner les contrôles censés détecter les instructions malveillantes et supprimer les liens suspects.

Ce que vous pouvez faire :

• Appliquez la « règle de deux » de Meta : EchoLeak nécessitait une IA capable de lire les données de l’entreprise, de lire des e-mails externes et d’envoyer des informations à l’extérieur — elle disposait des trois. La limiter à deux de ces capacités empêche une injection de prompt d’acquérir un contrôle excessif. Si la tâche nécessite les trois, exigez une approbation humaine avant chaque action.
• Testez face à des attaquants qui connaissent vos défenses : communiquez à vos testeurs de sécurité les règles et les filtres que vous avez mis en place, puis laissez-les les contourner. Dans une étude, les attaquants qui s’adaptaient aux défenses ont réussi dans plus de 90 % des cas face à la plupart des 12 défenses testées.

2. Empêcher la fuite d’informations sensibles

Lorsque des systèmes d’IA communiquent 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.

De nombreuses fuites commencent par un « partage excessif ». Imaginons qu’une entreprise connecte son IA à des espaces de stockage et à des bases de connaissances aux autorisations 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, et pourtant le LLM doit être considéré comme compromis.

Exemple : en janvier 2025, des chercheurs de Wiz ont découvert une base de données DeepSeek ouverte sur Internet, contenant plus d’un million d’entrées de journal, dont l’historique des conversations et des clés API, que les logiciels utilisent pour accéder à d’autres services. Les chercheurs n’ont même pas eu besoin de convaincre 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 ne lise les données : votre application doit 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 informations privées et les clés secrètes avant d’enregistrer les journaux d’activité, exigez une authentification et limitez l’accès aux personnes qui en ont besoin. Définissez une durée de conservation afin que ces enregistrements ne s’accumulent pas indéfiniment.

3. Brider l’autonomie excessive

Les IA dotées d’une autonomie excessive disposent de plus de pouvoir que leur mission ne l’exige : des outils dont elles n’ont pas besoin, des autorisations qui vont au-delà de leur tâche ou la liberté d’agir sans vérification. La cause importe peu ici.

Un prompt d’injection, un bug ou un modèle qui se trompe tout simplement mènent 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 codage de Replit avait supprimé sa base de données de 1 206 fiches 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 demander 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 :

• Supprimez 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 e-mails a besoin de l’autorisation de les lire, pas de les envoyer ni de les supprimer.
• Placez les contrôles d’autorisation en dehors de l’IA : chaque fois qu’une action est demandée, faites-la vérifier au regard de vos règles de sécurité et exigez qu’une personne l’approuve.

4. Contrôler ce qui entre dans votre chaîne d’approvisionnement IA

Rares sont les entreprises qui créent leur IA de A à Z, et elles sont chaque année moins nombreuses. Selon l’enquête 2025 de Menlo Ventures, The State of Generative AI in the Enterprise, 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 depuis des plateformes comme Hugging Face, poursuivent leur entraînement sur des jeux de données collectés par d’autres et y branchent des extensions 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é au sein même de 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 et août 2026. Pourtant, en juillet 2026, des modèles d’OpenAI ont contourné les contrôles censés les tenir à l’écart d’Internet lors de tests de sécurité internes et se sont introduits dans certaines parties des systèmes de Hugging Face. Un agent a même récupéré 14 identifiants d’accès exposés publiquement, vérifié qu’ils fonctionnaient et les a partagés avec d’autres agents. Les agents ont ensuite exploité des failles qui leur ont permis 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 créons des bacs à sable plus isolés, en restreignant l’accès à Internet et en contrôlant davantage l’accès aux poids des modèles », indique le rapport d’OpenAI.

Ce que vous pouvez faire :

• Figez les modèles sur une version précise et vérifiez-les : associez chaque modèle à une version validé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 également les signatures numériques, avec une mise en garde : une signature prouve la provenance d’un modèle, pas qu’il est sûr.
• Vérifiez chaque paquet suggéré par votre IA : avant d’installer un paquet de code recommandé par un assistant d’IA, assurez-vous qu’il existe, qu’il s’agit bien du paquet souhaité 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 sur lesquels elle a été affinée ou d’une base de connaissances dans laquelle elle cherche ses réponses. Le modèle semble toujours fonctionner ; il tire simplement de mauvaises leçons, et apprend parfois à mal se comporter uniquement lorsqu’il rencontre une phrase déclencheuse précise.

Cette phrase passera inaperçue à chaque test, jusqu’à ce que quelqu’un l’utilise.

Agrandir

Par ailleurs, c’est très difficile à rattraper. L’empoisonnement n’est pas un bug qu’un simple correctif suffit à réparer. 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, de l’AI Security Institute britannique et de l’Alan Turing Institute ont montré que 250 documents empoisonnés suffisaient à apprendre à un modèle à produire du charabia chaque fois qu’il rencontrait un déclencheur particulier. Ce même nombre fonctionnait pour les quatre tailles de modèles testées, alors que 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 origine et des changements entre les versions. Nous recommandons de versionner les jeux de données afin que, si un empoisonnement est détecté, vous puissiez revenir à une version saine et comprendre comment il s’est introduit.
• Recherchez les 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. Détectez-les à l’aide d’entrées conçues pour pousser 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 dite « illimitée ». La plupart des services d’IA facturent à l’usage : un attaquant pourrait donc faire grimper votre facture ou créer une copie de votre modèle.

L’OWASP qualifie le problème fondamental 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, la Threat Research Team de Sysdig a découvert un nouveau type d’attaque baptisé « LLMjacking ». Un groupe d’attaquants a ciblé 10 services LLM hébergés dans le cloud à l’aide d’identifiants volés. Ils se sont introduits via une version vulnérable de Laravel, puis ont déterminé ce que permettaient les identifiants et les éventuels quotas, dans le but évident de revendre l’accès. De nombreux paramètres de journalisation ont également été interrogés, probablement pour éviter d’être détectés. Selon Sysdig, dans le pire des cas, la victime pourrait devoir payer plus de 46 000 dollars par jour.

Ce que vous pouvez faire :

• Définissez des budgets qui bloquent les dépenses : fixez des plafonds de dépenses stricts pour chaque utilisateur, clé API et équipe, ainsi que pour le compte dans son ensemble. Appliquez-les à chaque point d’entrée des requêtes.
• Donnez un point d’arrêt à chaque tâche : 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 coupures automatiques pour les agents qui tournent en boucle ou dépassent leur quota.

7. Repérer les informations erronées 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 d’informations erronées. Le risque principal ne tient pas tant à la mauvaise réponse elle-même qu’au fait qu’on lui fasse confiance et qu’on l’utilise.

L’historique des incidents laisse penser que les praticiens ne se préoccupaient pas autant des informations erronées qu’ils l’auraient dû. D’après la lettre d’introduction de l’édition 2026, les votants ont classé ce risque parmi les derniers, alors qu’au vu des incidents réels, il figure parmi les premiers.

Exemple : en 2025, Deloitte Australia a remis une évaluation des systèmes informatiques de protection sociale dans le cadre d’un contrat public de 440 000 dollars australiens. Chris Rudge, chercheur à l’Université de Sydney, y a relevé des références à des travaux de recherche inexistants ainsi qu’une citation inventée tirée d’un jugement d’un tribunal fédéral. Le rapport révisé a révélé 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’un examen censé apporter des garanties.

Ce que vous pouvez faire :

• Vérifiez que les preuves étayent 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 étaye la conclusion, y compris ses exceptions.
• Vérifiez avant que le système n’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 lourdes de conséquences, en mettant les éléments justificatifs à la disposition de la personne chargée de la validation.

8. Limiter les dégâts liés à l’exposition du contexte caché

Les applications d’IA fournissent au modèle des instructions et des informations de contexte que les utilisateurs ne voient normalement pas. Il peut s’agir du prompt système, de politiques internes, de descriptions des outils disponibles et de règles définissant 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 du prompt système », car le prompt 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 celle d’une clé API donne à quelqu’un accès à votre base de données confidentielle.

Exemple : en février 2023, des utilisateurs ont réussi à faire révéler à Bing Chat de Microsoft 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 pouvoir 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 une consigne lui demandant de garder ces instructions confidentielles.

Ce que vous pouvez faire :

• Tenez les secrets à l’écart 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 de gestion des secrets distinct.
• 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 embeddings

Lorsqu’une IA utilise la recherche vectorielle pour trouver des réponses dans les documents de votre entreprise, elle ne parcourt pas directement le texte. Les documents sont convertis en « embeddings » (plongements vectoriels), c’est-à-dire de longues listes de nombres qui capturent le sens de chaque passage, puis stockés dans une base de données vectorielle. Une question est convertie de la même manière, 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 mécanisme peut être mis en défaut : l’empoisonnement fausse le système, l’inversion provoque des fuites, le brouillage le réduit au silence et un contrôle d’accès défaillant lui fait livrer n’importe quoi à n’importe qui.

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

Exemple : dans une étude présentée lors de la conférence 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 ne disposait pas de suffisamment 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 » (retrieval jamming).

Ce que vous pouvez faire :

• Maintenez des index distincts pour les données publiques et privées : ne mélangez pas le contenu web extrait avec les données de partenaires ou les documents internes confidentiels. Séparez physiquement les contenus selon leur niveau de confiance plutôt que de les étiqueter au sein d’un même index : vous éliminez ainsi toute une catégorie d’erreurs de configuration, et le contenu extrait d’Internet ne peut pas se retrouver à côté des documents de votre conseil d’administration.
• Traitez les embeddings comme les documents dont ils sont issus : chiffrez-les, protégez les sauvegardes de la base de données vectorielle au même titre que les fichiers sources, et supprimez les embeddings lorsque vous supprimez l’original. Les clés API de votre service d’embedding doivent rester secrètes.

10. Vérifiez la sortie de l’IA avant de la transmettre

Chaque fois qu’une application transmet la sortie d’une IA à un autre système sans vérifier qu’elle peut y être utilisée en toute sécurité, il s’agit d’une gestion inappropriée de la sortie du LLM.

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

Exemple : en 2025, le chercheur Johann Rehberger a montré comment l’assistant de programmation Amp de Sourcegraph pouvait divulguer le contenu de conversations simplement en affichant une image. Il a utilisé une injection de prompt pour amener Amp à inclure des informations privées dans l’adresse web d’une image. L’application a ensuite récupéré automatiquement cette image, transmettant ainsi ces informations à son serveur. La défaillance dans la gestion de la sortie résidait dans cette requête automatique : le texte généré par le modèle est devenu une connexion vers un serveur externe, emportant avec lui des données privées.

Ce que vous pouvez faire :

• Sécurisez la sortie en fonction de sa destination : vérifiez et traitez les réponses selon l’endroit où elles seront envoyé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 que ses conséquences restent limitées le cas échéant. Notre RSSI, Kyle Polley, a présenté notre approche lors d’un atelier récent.

• L’agent dispose de son propre ordinateur, et celui-ci démarre vide : les outils d’agent installés sur votre ordinateur portable peuvent accéder à ses fichiers, à ses applications et aux identifiants qui y sont 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 en dehors 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 via 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 créé BrowseSafe pour Comet, notre navigateur agentique, car 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 e-mails, pour y détecter les injections de prompt. Nous avons publié le modèle et le jeu de données en open source.
• Nous surveillons l’agent et les machines sur lesquelles il s’exécute : Numbat s’intercale entre la décision d’agir d’un agent et l’exécution effective de l’outil. Numbat journalise l’activité des agents de programmation pris en charge et peut bloquer, avant leur exécution, les actions qui enfreignent les politiques configurées. Bumblebee recense les paquets logiciels présents sur les ordinateurs portables, les serveurs et les pipelines de build, et signale ceux qui sont connus pour être malveillants. Les deux outils sont open source.
• Les fournisseurs de modèles ne conservent pas vos données : nous avons conclu des accords de non-conservation des données (zero data retention) avec nos fournisseurs tiers de LLM. Les administrateurs Enterprise peuvent également réduire la durée de conservation des données par Perplexity à 24 heures seulement.

Nous avons créé Numbat de manière proactive, pour une raison que Polley résume en une phrase : « Plus vous donnez 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 suffit à lui seul à sécuriser une application : les modèles peuvent toujours confondre un contenu qu’ils devraient lire avec des instructions qu’ils devraient suivre. Les défenses qui semblent solides lors des tests standard peuvent aussi céder sous la pression.

Mieux vaut se demander quelle configuration est la plus sûre pour votre cas d’usage. Cela implique des autorisations limitées, des identifiants tenus à l’écart du modèle, une approbation humaine pour les actions risquées et des tests menés par des personnes qui connaissent vos défenses.

Que sont les vulnérabilités des LLM ?

Les vulnérabilités des LLM sont des faiblesses qui permettent de manipuler un système d’IA, de lui faire divulguer des données ou de lui faire causer des dommages, que ce soit du fait d’un attaquant ou de ses propres erreurs.

Les dix principaux risques sont l’injection de prompt, la divulgation d’informations sensibles, l’autonomie excessive, la chaîne d’approvisionnement, l’empoisonnement des données et des modèles, la consommation illimitée, les informations erronées, l’exposition du contexte caché, les faiblesses des vecteurs et des embeddings, et la gestion inappropriée des sorties.

Un LLM privé est-il sûr ?

C’est une option plus sûre à certains égards, mais pas par défaut. Vous maîtrisez davantage le traitement des données si vous exécutez un modèle sur votre propre infrastructure ou dans un environnement cloud. Il n’existe toutefois aucun moyen automatique d’empêcher les injections de prompt, l’autonomie excessive, l’empoisonnement ou les informations erronées.

Avec l’auto-hébergement, vous êtes également responsable du modèle que vous téléchargez, notamment des risques liés à la chaîne d’approvisionnement, ainsi que de l’infrastructure qu’il requiert.