Les problèmes de sécurité IA les plus difficiles se trouvent maintenant en dehors du modèle

Le 2026 OWASP Top 10 pour les applications LLM offre une perspective critique sur la maturité de l’IA en production. Il saisit un changement décisif : l’industrie dépasse le bac à sable et se confronte aux complexités de l’intégration en conditions réelles.

Lorsque vous connectez un LLM aux outils et flux de travail d’entreprise, la surface d’attaque change fondamentalement. Les risques liés à l’autorité et à l’utilisation des ressources deviennent nettement plus difficiles à contenir. Simultanément, des vulnérabilités comme la mauvaise gestion des sorties reculent du premier plan, non pas parce qu’elles sont résolues, mais parce que d’autres problèmes ont pris le devant de la scène.

Le classement OWASP Top 10 reflète cette évolution. « Excessive Agency » est passé du sixième au troisième rang, tandis que « Unbounded Consumption » a grimpé au sixième. En revanche, « Improper Output Handling » est tombé à la dixième place.

Cela ne diminue pas le risque lié à la gestion des sorties. Si la réponse d’un LLM atteint un shell ou une base de données sans validation rigoureuse, les failles d’injection traditionnelles persistent. Cependant, le paradigme a changé. Dans un système agentique, la réponse du modèle n’est pas la destination ; c’est une entrée portant une autorité. Lorsqu’un modèle détient des identifiants ou interagit avec une API, sa sortie agit comme un vecteur pouvant déclencher des actions à travers des systèmes disparates.

Le défi de sécurité ne consiste plus seulement à évaluer le modèle ; il s’agit de définir les limites de ce qui se produit après l’inférence. Votre architecture détermine si une hallucination reste sous forme de texte ou se manifeste sous forme de mutation non autorisée d’une base de données.

Le classement suit les dommages

OWASP a exploité 7 714 incidents, 75 % motivés par le consensus de la communauté et 25 % par des données d’incidents empiriques. Cette base de preuves a imposé un véritable réordonnancement des priorités.

« Excessive Agency » a augmenté parce que la réalité des environnements de production a rattrapé la théorie. Les organisations accélèrent le déploiement de capacités autonomes plus rapidement qu’elles n’établissent les plans de contrôle nécessaires. La vulnérabilité critique n’est pas seulement la réponse fournie par le modèle, mais le contexte d’autorisation dans lequel cette réponse est exécutée.

Bien que « Improper Output Handling » demeure une préoccupation, les équipes DevOps ont gagné en maturité dans leur capacité à sécuriser les points de sortie en aval grâce à la validation de schémas et aux requêtes paramétrées. Il s’agit de pratiques de sécurité applicative bien établies.

L’agence, toutefois, constitue une catégorie de problème différente. Un appel d’outil peut être structurellement valide mais contextuellement illégitime. Le modèle peut invoquer une fonction approuvée pour une tâche inappropriée ou cibler la mauvaise ressource. La désinfection statique ne peut pas juger de l’intention. Cela nécessite une autorisation sophistiquée et contextuelle que le modèle ne doit jamais exécuter de manière isolée.

Considérez chaque outil comme une capacité exposée

De nombreuses équipes traitent les définitions d’outils comme de simples tuyaux d’intégration. C’est une erreur à la fois risible et fondamentale. Chaque outil, connecteur ou point de terminaison d’API élargit le champ d’influence de l’application IA.

Imaginez un agent conçu pour résumer une boîte aux lettres. Si l’implémentation utilise un connecteur large incluant des capacités d’écriture ou de suppression, vous avez introduit une fonctionnalité excessive avant même que le premier prompt ne soit traité.

Vous devez appliquer le principe du moindre privilège :

• Restreindre l’interface : fournir à l’agent des outils en lecture seule plutôt que des connecteurs polyvalents.
• Contexte limité : exécuter les requêtes dans l’identité OAuth à portée de l’utilisateur.
• Points d’application de la politique (PEP) : implémenter la logique d’autorisation comme un middleware obligatoire entre le modèle et les systèmes en aval. Chaque action doit être validée par rapport à la politique avant son exécution.
• Humain dans la boucle (HITL) : exiger une approbation explicite pour les opérations difficiles à annuler ou ayant un impact matériel important.

Cette approche nécessite un changement dans le pipeline de livraison. Votre processus de révision doit s’étendre au-delà du modèle pour englober les modifications des schémas d’outils, des identités de service et des portées d’autorisations. Une mise à jour du modèle peut sembler bénigne, mais une modification du contexte d’autorisation d’un connecteur peut engendrer une vulnérabilité catastrophique.

La visibilité est non négociable. Vous devez consigner l’exécution spécifique de l’outil, l’identité autorisante et la modification résultante dans le système cible. Cette chaîne de responsabilité est essentielle pour la réponse aux incidents, vous permettant d’interrompre un processus actif et de reconstruire la trace d’audit après l’incident.

Chaque exécution autonome nécessite un arrêt ferme

« Unbounded Consumption » a explosé parce que le volume de requêtes est une métrique inadéquate du risque de ressources. Un seul prompt concis peut déclencher une chaîne récursive d’appels d’outils gourmande en ressources. Le compteur ne s’arrête pas tant que l’agent n’a pas terminé.

Une simple alerte est insuffisante lorsque la vitesse d’exécution dépasse la réponse humaine. Vous avez besoin de limites déterministes et strictes qui restent hors du contrôle de l’agent. Implémentez des plafonds rigoureux pour l’utilisation des jetons, le temps écoulé, la profondeur de récursion et le coût opérationnel cumulé. Si une exécution dépasse ces paramètres, le système doit interrompre ou réguler l’exécution.

L’étendue opérationnelle exige une rigueur similaire. Déterminez le nombre maximal d’enregistrements qu’un agent peut modifier et définissez les limites de la propagation des tâches. Si votre architecture ne dispose pas d’un mécanisme « stop » déterministe, vous avez essentiellement délégué de l’autorité sans en définir le périmètre.

Construire pour la mauvaise réponse

L’ingénierie des systèmes s’appuie depuis longtemps sur une architecture résiliente pour sécuriser des composants intrinsèquement peu fiables. Nous anticipons les pannes de composants et l’instabilité du réseau ; la sécurité découle de cette hypothèse, et non d’une illusion de perfection. Les LLM exigent la même discipline architecturale.

Ne fondez pas votre stratégie de sécurité sur l’hypothèse d’un alignement parfait du modèle. Prévoyez l’échec, qu’il s’agisse d’une mauvaise interprétation bénigne ou d’une exploitation malveillante. Limitez les capacités de l’agent au strict minimum requis et maintenez des contextes d’autorisation utilisateur stricts pour tous les appels en aval. Il est essentiel que l’application des politiques se situe en dehors du modèle afin d’empêcher les injections d’invite ou les erreurs de raisonnement de contourner vos contrôles.

Nous considérons aujourd’hui l’injection d’invite moins comme une vulnérabilité que comme une loi physique. Elle sera toujours présente. Le fait est que les modèles eux‑mêmes ne peuvent pas être des décideurs efficaces pour des questions critiques en matière de sécurité. Dans un projet d’agentic réel que je construis, nous réalisons environ 100 tests automatisés « red team ». Nous nous assurons de les réussir tous. Mais nous le faisons en construisant des contrôles stricts en dehors du modèle. Nous pouvons désactiver ces contrôles et observer les taux de réussite/échec du modèle seul. Le modèle le plus ancien et le plus faible que nous testons échoue 17 % du temps. Le modèle le plus récent et le plus grand échoue 2 % du temps. Un grand progrès, n’est‑ce pas ? Mais 98 % est‑il suffisant quand chaque échec entraîne une fuite de données sensibles ? Pas du tout.

Les opérations à fort impact doivent être observables, auditées et, idéalement, réversibles. Chaque exécution autonome nécessite des garde‑fous immuables qui restent hors de portée du modèle.

Les classements de 2026 éclairent vraiment le moment où les défaillances de l’IA se transforment en conséquences matérielles. Le modèle peut initier l’erreur, mais l’architecture définit le rayon d’explosion. Pour l’IA en production, le travail de sécurité le plus critique se situe dans le pipeline post‑inférence.