L’adoption d’applications basées sur des modèles de langage de grande taille, connus sous le nom de LLM, transfère une partie des risques de sécurité traditionnels vers une nouvelle couche : la façon dont ces modèles reçoivent, utilisent des outils et génèrent des réponses pouvant ensuite s’exécuter dans d’autres systèmes. Le nouveau OWASP Top 10 pour les applications LLM 2026 compile les dix risques que l’organisation considère comme les plus critiques pour ce type d’architecture, allant de l’injection de prompts aux failles dans la gestion des résultats générés par l’IA.

Les clés des risques de sécurité liés à l’IA en 30 secondes

• OWASP positionne l’injection de prompts en tête du classement, tout en avertissant des problématiques apparaissant lorsque un LLM a accès à des données, outils et mémoires.
• La divulgation d’informations confidentielles peut se produire dans les réponses, les logs, les embeddings, les appels à des outils ou d’autres composants de l’application.
• Un excès d’autonomie augmente le risque lorsqu’un agent peut modifier des données, envoyer des messages, exécuter du code ou effectuer des opérations sans supervision.
• Les risques liés à la chaîne d’approvisionnement, au poisoning de données et à la consommation illimitée impactent à la fois la sécurité et les coûts.
• Les quatre derniers risques concernent la désinformation, l’exposition de contexte caché, les vulnérabilités dans les embeddings et un traitement peu sécurisé des réponses du modèle.

Ce rapport met en évidence une différence importante par rapport à de nombreuses applications logicielles classiques. Dans une application traditionnelle, les frontières entre données, instructions et permissions sont généralement définies par le code. Dans une application impliquant un LLM, ces frontières passent souvent par un modèle qui traite du texte, des images, des documents, de la mémoire et des résultats d’outils dans un même flux contextuel.

Cela signifie que la sécurité ne peut plus reposer uniquement sur la détection d’une entrée malveillante avant qu’elle n’atteigne le modèle. OWASP préconise donc la mise en place de contrôles couvrant toute l’architecture : permissions, outils, données, stockage, fournisseurs, validation des résultats et supervision humaine.

1. Injection de prompts: le modèle ne distingue pas une instruction d’une donnée

L’injection de prompts occupe la première place dans le classement. Le problème survient lorsqu’une entrée modifie le comportement prévu du modèle. Cette entrée peut être un message utilisateur, mais aussi un document récupéré via RAG, un email, une page web, une image, une réponse d’un outil ou une information stockée en mémoire persistante.

L’une des difficultés réside dans le fait que le LLM traite instructions et données comme des tokens dans son contexte. Si l’application mélange le prompt système, les instructions utilisateur, les documents externes et la mémoire sans contrôles appropriés, une partie de ce contenu peut influencer son comportement.

OWASP distingue l’injection directe, provenant de l’utilisateur, et l’injection indirecte, qui survient lorsque le modèle traite un contenu externe contenant des instructions malveillantes, que l’utilisateur n’a peut-être même pas vues.

Le risque augmente lorsque l’agent dispose d’outils. Une instruction insérée dans un document peut passer d’un simple texte malicieux à une requête déclenchant un appel API, la modification d’un fichier ou l’envoi d’informations.

C’est pourquoi le rapport recommande de garder hors du modèle les certificats, capacités de modification d’état, de réduire les permissions et d’exiger une validation humaine pour toute action privilégiée ou irréversible. Il est aussi essentiel d’instaurer des contrôles stricts lorsque un agent dispose d’accès à des informations sensibles, à du contenu non fiable ou de communication externe.

2. Exposition d’informations confidentielles : l’information peut fuir par plusieurs canaux

Le deuxième risque concerne l’exposition d’informations sensibles. Il ne se limite pas à une réponse accidentelle contenant un secret.

Les arguments envoyés aux outils, les fragments récupérés via RAG, les logs, la télémétrie, les embeddings et même certaines propriétés observables du système peuvent devenir des vecteurs de fuite de données.

OWASP identifie plusieurs moments clés où cette exposition peut se produire : lors de l’entraînement, de l’inférence, des processus d’ajustement ou de distillation, ainsi que lors des phases de surveillance et de monitoring.

Le rapport attire aussi l’attention sur les stockages vectoriels. Une sauvegarde contenant uniquement des embeddings ne doit pas être considérée comme sûre par défaut, car des techniques peuvent permettre de reconstruire des informations provenant des documents originaux.

Il est recommandé de classifier et contrôler les données dès leur origine, de limiter la quantité d’informations accessibles aux fournisseurs externes, d’autoriser l’accès avant la récupération de chaque fragment et d’implémenter des mécanismes de détection et de filtrage.

3. Excès d’autonomie : quand l’agent peut faire trop

Le troisième risque concerne l’excès d’autonomie. Il désigne des systèmes où le LLM dispose de trop d’outils, permissions ou autonomie.

Un assistant conçu pour lire des documents pourrait aussi avoir accès à des fonctions pour les modifier ou supprimer. Un outil devant interroger une base de données pourrait disposer de droits d’écriture, même si ce n’est pas nécessaire pour sa tâche.

La situation se complique si le modèle peut envoyer des emails, exécuter des commandes, effectuer des paiements ou modifier des systèmes sans validation extérieure.

OWASP recommande de limiter les outils et leurs fonctionnalités, d’utiliser des permissions minimales et de faire la validation en dehors du LLM. Le modèle doit décider de ses actions, sans déterminer seul s’il possède la permission de le faire.

La validation humaine devient particulièrement critique pour les actions irréversibles ou à fort impact.

4. Chaîne d’approvisionnement : le risque vient aussi des modèles et dépendances

La chaîne d’approvisionnement occupe la quatrième position. En IA, le périmètre dépasse celui des bibliothèques logicielles.

Elle inclut aussi les modèles pré-entraînés, ensembles de données, adaptateurs, composants tiers et processus de conversion, quantification ou fusion de modèles.

Un modèle apparemment légitime peut avoir été manipulé, une dépendance contenir du code malveillant ou un jeu de données comporter des informations contaminées. Les questions sur les licences et conditions d’utilisation de certains modèles ou données posent aussi des risques.

OWASP recommande de tenir un inventaire actualisé, de vérifier la provenance des composants, d’utiliser des signatures et contrôles d’intégrité, ainsi que d’évaluer la sécurité et de faire du red teaming sur les modèles de tiers.

5. Envenenement de données et de modèles : une IA peut apprendre des comportements erronés

Le poisoning de données et modèles affecte l’intégrité du système. Un attaquant peut chercher à injecter des données malveillantes lors de l’entraînement, de l’ajustement, de la génération d’embeddings, via RAG ou en apprentissage continu.

Le danger, c’est que le système fonctionne apparemment normalement tout en intégrant des comportements incorrects.

OWASP recommande de suivre la traçabilité des données et des modèles avec des mécanismes comme les fiches techniques logiciels et ML (SBOM, ML-BOM), en vérifiant leur provenance et en contrôlant les modifications tout au long de leur cycle de vie.

Pour les applications RAG, il est également crucial de définir des frontières de confiance et de filtrer le contenu avant son intégration au contexte du modèle.

6. Consommation illimitée : une requête peut engendrer des coûts imprévus

La consommation illimitée introduit une dimension économique souvent absente des systèmes classiques. Une application autorisant des inférences très longues ou multiples peut engendrer des problèmes de disponibilité, des coûts inattendus ou une surconsommation des capacités du modèle.

Les modèles de raisonnement, les entrées multimodales, ou les agents utilisant plusieurs appels d’outils peuvent faire croître exponentiellement le coût d’une seule requête.

OWASP cite l’exemple de la Denial of Wallet : un attaquant génère un volume suffisant d’opérations pour faire exploser la facture d’un service IA basé sur la consommation.

Pour se défendre, il faut mettre en place des limites de fréquence, des quotas par utilisateur ou application, contrôler la taille des entrées, et automatiser la coupure de flux quand les seuils sont dépassés.

7. Désinformation : une réponse convaincante peut être fausse

Le risque de désinformation générée par le modèle ne se limite pas à une réponse absurde. Elle peut sembler crédible, incitant une personne ou une application à la traiter comme vraie.

Les causes incluent hallucinations, information obsolète, contexte insuffisant, données erronées ou résultats d’outils non vérifiés.

Ce risque s’accentue lorsque le résultat du LLM déclenche des actions : une erreur dans une conversation peut rester une simple erreur, mais dans un agent, elle peut modifier l’état d’un système, générer du code ou prendre des décisions opérationnelles.

OWASP recommande de séparer la génération et l’exécution, de valider les affirmations avant d’agir, et de vérifier les arguments, permissions et conditions des appels d’outils.

8. Exposition de contexte caché : les prompts système recèlent aussi des informations sensibles

Le risque d’exposition du contexte caché concerne les instructions que l’application fournit au modèle, souvent invisibles à l’utilisateur : system prompts, règles internes, politiques, schémas d’outils, instructions de développeurs ou informations récupérées dans des systèmes internes.

Extraire ce contexte ne constitue pas toujours une vulnérabilité en soi. Cependant, il devient problématique si ce contenu contient des secrets, des règles internes, des permissions ou des informations permettant de contourner ou d’attaquer la sécurité de l’application.

OWASP recommande d’éviter de placer des secrets dans ces contextes et de maintenir la gestion des accès et contrôles de sécurité en dehors du LLM.

9. Vulnérabilités dans les vecteurs et embeddings : le moteur de recherche est aussi une surface d’attaque

Les vecteurs et embeddings sont essentiels pour de nombreuses applications RAG, mais présentent aussi des risques spécifiques.

Une application peut convertir documents, images, code ou audio en représentations numériques et utiliser la similarité entre vecteurs pour décider quel contenu récupérer. Si le contrôle d’accès intervient après cette recherche, un utilisateur pourrait accéder à des documents d’un autre client par des modèles de résultats, des scores ou des temps de réponse.

OWASP signale également des risques liés à l’inversion d’embeddings, l’inférence d’appartenance, la manipulation de la récupération, la contamination des caches sémantiques et les attaques contre des systèmes multimodaux.

La solution consiste à appliquer les permissions avant ou durant la récupération, à différencier les données selon leur niveau de confiance, à vérifier la provenance des sources, et à surveiller toute activité anormale.

10. Mauvaise gestion des résultats : il ne faut jamais faire confiance aveuglément à une sortie du LLM

Le dixième risque concerne la mauvaise gestion des résultats. Il survient lorsqu’une réponse produite par le modèle est transmise à un autre système sans validation, filtration ou encodage approprié.

Un LLM pourrait générer une requête SQL non paramétrée, une commande shell ou du contenu HTML inséré sans échappement adéquat.

Il existe également des risques moins évidents, comme des séquences de contrôle envoyées à des terminaux, des panneaux d’administration ou des systèmes de logs.

OWASP recommande de traiter chaque sortie du modèle comme une entrée potentiellement dangereuse, de la valider selon le contexte, d’implémenter des contrôles d’autorisation indépendants et d’éviter que le LLM exécute directement des opérations privilégiées.

En résumé, la classification OWASP souligne une idée clé pour les développeurs de systèmes IA : le modèle ne doit pas devenir la barrière de sécurité de l’application. Les permissions, les identifiants, la validation et les décisions à fort impact doivent rester sous contrôle externe au modèle.

Au fur et à mesure que les LLM évoluent vers la lecture de documents, la consultation de bases, l’exécution de code ou l’utilisation d’outils, la sécurité dépendra de plus en plus de la conception globale de l’architecture. Les dix risques OWASP servent précisément de checklist pour évaluer cette architecture avant qu’un assistant IA n’accède à des systèmes ou informations que qu’une application classique ne pourrait toucher sans contrôles stricts.

Questions fréquentes

Quel est le principal risque de sécurité pour les applications LLM selon OWASP ?

OWASP Top 10 pour les applications de LLM 2026 place l’ injection de prompts en première position. Le risque peut venir aussi bien d’instructions directement introduites par un utilisateur que de contenu externe traité par le modèle.

Pourquoi l’excès d’autonomie est-il dangereux pour les agents IA ?

Parce qu’un agent peut disposer d’outils et permissions pour modifier des données, exécuter des commandes ou communiquer avec d’autres systèmes. OWASP recommande de limiter ces capacités et de maintenir la validation hors du modèle.

Les embeddings peuvent-ils aussi poser des problèmes de sécurité ?

Oui. Les embeddings font partie du périmètre de confiance dans de nombreuses applications RAG, et peuvent faire l’objet d’attaques telles que l’inversion, le poisoning, l’inférence ou des problèmes de contrôle d’accès entre utilisateurs.

Peut-on faire confiance directement à la sortie d’un LLM ?

Non, surtout si cette sortie doit servir à exécuter des actions ou alimenter d’autres systèmes. OWASP recommande de valider et sanitiser les résultats du modèle avant leur utilisation en aval.