TL; DR #
La sécurité des modèles de langage (LLM) consiste à protéger les applications construites sur ces modèles contre les attaques exploitant leur interprétation du langage, leurs interconnexions et leurs droits d'action. Ceci est crucial car un modèle de langage ne peut dissocier avec certitude les instructions des données : tout arrive dans le même contexte, si bien que tout texte lu par le modèle peut potentiellement être interprété comme une commande. Le changement majeur en 2026 réside dans le fait que l'objectif n'est plus de concevoir un modèle infaillible, mais de développer une application qui reste sécurisée même lorsque le modèle est trompé. C'est pourquoi cette discipline se concentre sur les privilèges, l'accès aux outils, la gestion des sorties et l'étendue de l'attaque, plutôt que sur le seul filtrage des invites.
Qu'est-ce que LLM Security ? #
La sécurité des modèles de langage (LLM) est généralement présentée comme un problème de contenu : si du texte erroné est introduit, du texte erroné sera extrait, il faut donc filtrer le texte. Cette description reste valable le temps de connecter le modèle à une base de données. Le véritable risque n'est pas ce que le modèle lit, mais ce à quoi il peut accéder.
Voici le problème structurel. Dans une application classique, le code et les données d'entrée sont séparés par l'architecture elle-même : le programme est compilé, les données d'entrée arrivent via un paramètre, et la frontière entre les deux est gérée par l'environnement d'exécution. Un modèle de langage étendu ne présente pas une telle frontière. L'invite système, le message de l'utilisateur, un document récupéré, le contenu d'une page web, la réponse d'un outil et un courriel que l'agent doit résumer arrivent tous sous forme de jetons dans la même fenêtre de contexte. Le modèle les pondère, mais ne les authentifie pas.
Voici donc la définition de travail : La sécurité LLM est la discipline qui consiste à concevoir, construire et exploiter des applications LLM de manière à ce que des entrées non fiables ne puissent pas entraîner d'actions non autorisées, et à ce que les conséquences soient limitées lorsque cela se produit. Il englobe le modèle, la couche d'invite, les données que le modèle récupère, les outils qu'il peut appeler, la sortie qu'il produit et l'identité sous laquelle il agit.
C'est cette dernière clause que les équipes sous-estiment. Un LLM seul peut générer une requête incorrecte. Un LLM connecté à une base de données, une API de paiement et un shell peut générer une requête incorrecte qui s'exécute.
Signification de la sécurité LLM, décomposée en ses parties #
La manière la plus claire de comprendre la signification du terme « LLM sécurité » consiste à distinguer les trois choses que les gens confondent lorsqu'ils utilisent cette expression.
- Sécurité du modèle. Propriétés du modèle lui-même : ce qu’il a mémorisé, ce qu’il divulguera, son comportement face à des formulations adverses et la conformité des pondérations utilisées avec celles publiées par l’éditeur. Ces propriétés sont en grande partie héritées si vous utilisez un modèle hébergé, et en grande partie personnalisées si vous le paramétrez.
- Sécurité des applications. Câblage autour du modèle : invites système, récupération pipelineLes définitions des outils et des fonctions, les permissions des agents, la gestion des sorties et l'identité sous laquelle le système agit constituent le cœur du système. C'est là que se produisent la plupart des incidents réels, et c'est la couche que l'équipe contrôle réellement.
- Sécurité opérationnelle. Ce qui se passe au fil du temps : surveillance, détection des abus, limites de coûts et de débit, réponse aux incidents, et le fait qu’une version de modèle, une invite système ou un outil connecté peut changer sans que personne ne dépose de ticket.
En résumé, la signification du terme « LLM sécurité » sur laquelle la plupart des praticiens s'accordent est la suivante : Partons du principe que le modèle finira par faire ce qu'un attaquant lui demandera, et concevons-le de manière à ce qu'il puisse survivre à cette attaque. Il ne s’agit pas d’« empêcher la manipulation du modèle », mais de contenir cette manipulation. Cette inversion est l’idée la plus utile dans ce domaine, et elle constitue également la thèse des recommandations actuelles de l’OWASP.
#
Que protège LLM Security ? La surface d’attaque #
Comprendre ce qu'est la sécurité LLM en pratique signifie savoir dans quelle couche se situe un risque donné, car le contrôle se situe dans la même couche.
| Couche | Ce qu'un agresseur recherche | Là où vit le contrôle |
|---|---|---|
| Le modèle | Données d'entraînement mémorisées, comportement dangereux face à une formulation adverse, poids falsifiés | Sélection du modèle, vérification de la provenance, évaluation avant adoption |
| Invites et contexte | Injection directe et indirecte d'invites, exposition de contexte caché, extraction d'invites système | Isolation du contexte, gestion des entrées, traitement de tout texte récupéré comme non fiable |
| Récupération et données | Documents empoisonnés, manipulation intégrée, exfiltration via les données que le modèle peut extraire | Listes blanches de sources, contrôles d'ingestion, limitation de l'accès au stockage vectoriel |
| Outils et agents | Agence excessive : faire agir le modèle, et non se contenter de répondre. | Portée des outils basée sur le principe du moindre privilège, identité par agent, approbation humaine pour les actions irréversibles |
| Sortie | Exécution en aval du texte du modèle : code, requêtes, appels d’API, balisage rendu | Validation et encodage des données chez chaque consommateur, sans jamais se fier au texte généré. |
| Supply chain | Des modèles, des paquets, des plugins et des serveurs MCP malveillants s'intègrent à la pile. | Contrôles des dépendances et des artefacts, inventaire, provenance |
| Opérations | Consommation illimitée, épuisement des coûts, dérive silencieuse de la configuration | Limites de débit et de budget, surveillance, examen des modifications apportées aux invites et aux configurations |
La plupart des équipes commencent par paramétrer la couche de réponse, car c'est la plus visible. Les couches qui transforment une réponse inappropriée en incident sont les outils et l'identité ; il s'agit donc de configuration, et non d'apprentissage automatique.
Le Top 10 OWASP LLM 2026 : les changements et leur importance #
Le projet OWASP GenAI Security a publié en août 2026 son classement des 10 principales applications LLM, qui constitue la référence la plus partagée dans le domaine. L'édition 2026 est également la première à confronter le vote de la communauté à un ensemble d'incidents réels, et non plus seulement à l'avis d'experts.
Il convient d'interpréter trois mouvements comme des signaux plutôt que comme des détails insignifiants.
- L'injection rapide est restée en tête du classement. Non pas à cause d'une défaillance des défenses, mais parce que la cause profonde est architecturale. Les instructions et les données non fiables partagent toujours le même contexte, et aucune solution définitive n'existe. Il faut considérer cela comme une contrainte permanente à contourner lors de la conception, et non comme un bug en attente d'un correctif.
- L'agence excessive est passée de la sixième à la troisième place. C’est le changement d’agentivité qui se manifeste dans le rapport d’incident. Lorsque la sortie du modèle exécute des commandes, appelle des API ou écrit dans les systèmes de manière autonome, une manipulation cesse d’être un problème de contenu et devient un problème d’autorisation.
- La gestion incorrecte des sorties est passée de la cinquième à la dixième place, et la fuite des invites système s'est étendue à l'exposition du contexte caché. Le domaine a cessé de considérer le texte du modèle comme la principale surface de risque et a commencé à considérer comme surface de risque tout ce que le modèle peut atteindre.
Comment fonctionne concrètement la sécurité LLM ? #
Comprendre ce qu'est la sécurité LLM est une chose. La mettre en œuvre repose sur quatre boucles de contrôle, qui correspondent à la surface d'attaque décrite ci-dessus plutôt qu'à une catégorie de produits.
1. Inventaire : repérer la surface LLM avant de la fixer. #
Vous ne pouvez pas contrôler ce que personne n'a déclaré : modèles, clés API, invites et modèles d'invites, définitions d'agents, serveurs MCP, récupération. pipelineet les outils de programmation d'IA que vos développeurs ont déjà installés. L'IA fantôme est la norme, et non l'exception, et son inventaire est systématiquement plus vaste que celui que l'on peut recenser. Cette boucle produit le Nomenclature AI-BOM, ce que l'auditeur finira par demander.
2. Contrainte : réduire le rayon de l'explosion avant de rendre le modèle complexe. #
Le principe du moindre privilège s'applique aux outils, et pas seulement aux utilisateurs. Chaque outil doit être limité aux fonctionnalités les plus restreintes nécessaires à sa fonction. Chaque agent doit disposer d'une identité propre plutôt que d'un compte de service partagé. Toute action irréversible doit faire l'objet d'une approbation humaine. Toute réponse d'un outil doit être considérée comme une entrée non fiable, car un attaquant qui contrôle un document récupéré par l'agent contrôle le texte que le modèle interprétera comme une instruction. C'est à ce niveau que le problème de l'autonomie excessive est réellement résolu, et cela ne relève en rien de l'apprentissage automatique.
3. Test : évaluation contradictoire comme critère de publication #
Structuré Équipe rouge de l'IA contre la configuration déployée, et non contre le modèle isolé : injection directe et indirecte, exfiltration de données par récupération, extraction d’invites système, chaînes d’utilisation abusive d’outils et consommation illimitée. Les résultats sont des taux, et non des exploits individuels ; le résultat est donc un ensemble documenté de conditions que l’équipe décide d’accepter, d’atténuer ou de bloquer. Exécutez-le pour chaque version, idéalement par pull request qui modifie une invite, la définition d'un outil ou une autorisation.
4. Observation : supposer que la configuration dérive #
Surveillez les tentatives d'injection, les séquences d'appels d'outils anormales, les schémas de sortie suggérant une exfiltration et les pics de consommation. Surveillez la configuration elle-même, car une invite système, un fichier de règles ou une configuration MCP peuvent être modifiés. pull request Ces éléments sont considérés comme de la documentation par les examinateurs. Reliez-les à un chemin d'incident, en indiquant un responsable et une cible de restauration.
En résumé, la sécurité LLM : Identifiez la surface d'attaque, réduisez les privilèges, testez le mode de défaillance et surveillez la configuration. Le filtrage des invites s'y trouve intégré et, pris isolément, il est le plus faible des quatre.
Là où s'arrête le LLM en sécurité et où commencent les autres disciplines #
Il convient de le préciser, car ces termes sont souvent utilisés indifféremment dans la documentation des fournisseurs. La sécurité LLM couvre l'aspect utilisateur : invites, récupération, agents, accès aux outils et comportement du modèle lors de l'inférence. MLSecOps couvre la partie construction et entraînement : données d’entraînement, artefacts du modèle, pipelineet la provenance. Sécurité IA La sécurité des applications est le cadre qui les englobe tous les trois. C'est la discipline dont ils héritent tous les trois, et la raison pour laquelle les conclusions de LLM doivent être traitées avec la même priorité que toutes les autres, plutôt que dans un outil séparé que personne n'utilise.
Commencez par les questions auxquelles vous pouvez répondre cette semaine #
La plupart des programmes de sécurité LLM s'enlisent sur les mauvaises questions. Les équipes débattent de l'approche de garde-fous à adopter alors que personne ne sait combien d'agents existent dans le code source, quels outils chacun peut appeler, ni qui a approuvé le serveur MCP reçu. pull request Il y a quatre mois, cette demande a été examinée à titre de documentation. Ce ne sont pas des questions de recherche. Elles ont des réponses, et ces réponses se trouvent actuellement dans vos archives.
Il est primordial de répondre à trois questions avant toute autre chose. Quelles invites, définitions d'agents et configurations MCP sont présentes dans votre code ? À quoi chacune a-t-elle accès : quels outils, quelles données, et quelle identité ? Et quelles autorisations personne n'accorderait si on les lui demandait directement, une par une, lors d'une réunion ? La troisième question est la plus délicate, car un excès d'autorisations est rarement une bonne chose.cisL'ion. Il s'accumule, un champ d'application pratique à la fois, et il représente désormais le troisième risque le plus important dans ce domaine.
Xygéni Les deux premières questions sont traitées sans enquête. Découverte continue de toutes les ressources d'IA dans vos référentiels : modèles, frameworks, jeux de données, points d'accès d'inférence, agents, serveurs MCP, compétences, invites, guardrailset les outils de codage IA que vos développeurs ont installés à l'insu de tous. Un scanner IA dédié, conçu pour les failles spécifiques aux applications LLM (injection de prompts, injection d'outils, fuite de données par récupération, contournement des prompts système et contrôle excessif de l'utilisateur), est associé à chacune des 10 principales vulnérabilités OWASP LLM, des 10 principales vulnérabilités des applications à contrôle excessif et des 10 principales vulnérabilités MCP, et identifie la ligne de code exacte à l'origine de la vulnérabilité. DevAI dans l'IDE, bloquer les modifications non sécurisées avant le pipeline exécutions. Une nomenclature IA prête pour l'audit, et une vue prioritaire sur les risques à travers les résultats de l'IA et les résultats d'application que vous gérez déjà.
La troisième question est à vous de répondre. Démo et commencez par constituer votre propre inventaire.
FAQ – Qu'est-ce que le MLSecOps ? (Réponses courtes) #
Protéger les applications construites sur de grands modèles de langage contre les attaques exploitant le langage. Puisque le modèle ne peut distinguer les instructions des données, tout texte qu'il lit peut être interprété comme une commande ; la défense consiste donc à limiter les actions autorisées au modèle plutôt qu'à contrôler ce qu'il est autorisé à lire.
La majeure partie de ces informations reste valable, et la partie qui s'applique est celle que vous contrôlez. Vous héritez de la sécurité du modèle du fournisseur, mais l'invite système et la récupération pipelineLes définitions des outils, les autorisations des agents et la gestion des sorties sont entièrement de votre responsabilité. C'est là que les incidents surviennent.
Pas complètement, et l'édition 2026 de l'OWASP indique clairement que les instructions et les données non fiables partagent toujours une même fenêtre de contexte, sans solution définitive. Les mesures d'atténuation réduisent la fréquence des incidents. Le confinement en atténue les conséquences, c'est pourquoi la conception des privilèges est plus importante que le filtrage.
Un système capable d'effectuer plus d'actions, avec plus d'autorisations et de manière plus autonome que ne l'exige la tâche. L'OWASP identifie trois causes principales : fonctionnalités excessives, autorisations excessives et autonomie excessive. Ce système est passé de la sixième à la troisième place en 2026 car les incidents de production se concentrent désormais autour d'agents qui exécutent plutôt que de répondre.
L’approche par la traçabilité et l’intégrité des données prime sur la simple détection. Elle inclut l’enregistrement de la provenance des données, le hachage et la signature des ensembles de données, le contrôle d’accès à l’étiquetage et la validation par des méthodes contradictoires avant leur diffusion. L’empoisonnement est difficile à repérer dans le modèle et bien plus facile à contrôler à la source.
