LLM en production : cartographie des surfaces d’attaque

Déployer des LLM en production introduit une surface d’attaque structurellement nouvelle, mal couverte par les référentiels de sécurité applicative traditionnels. Tour d’horizon des vecteurs critiques, illustrés par des cas réels et éclairés par le référentiel de l’Open Web Application Security Project (OWASP).

La sécurité, victime collatérale de la course au marché

Une remarque liminaire s’impose. Comme pour toute technologie portée par un fort impératif de mise sur le marché, la sécurité est fréquemment reléguée au second plan, derrière la vitesse et la conquête d’usages. L’IA n’échappe pas à cette règle — elle l'illustre même de façon spectaculaire. Au Pwn2Own Berlin 2026, plusieurs produits d’IA de premier plan sont tombés précisément là où le système fait une confiance inconditionnelle à un outil ou à un protocole externe : le fameux problème de la « frontière de confiance ». Autrement dit, beaucoup de ces systèmes ont été conçus pour fonctionner, pas pour résister.

Pourquoi les LLM constituent une cible singulière

Un LLM n’est pas une simple interface de programmation. C’est un système probabiliste qui interprète le langage naturel, maintient un contexte, accède le cas échéant à des outils externes et produit des sorties par nature non déterministes. Cette fluidité, qui fait sa puissance, est aussi sa faiblesse fondamentale : là où une API REST valide des paramètres stricts, un LLM accepte des instructions formulées librement. C’est cette absence de frontière nette entre données et instructions qui ouvre des catégories d’attaques entièrement nouvelles, recensées par l’OWASP dans son référentiel dédié, l’OWASP Top 10 for LLM Applications, dont la version 2025 fait autorité.

1. L’injection de prompt (LLM01) — la faille matricielle

L’injection de prompt est aux applications d’IA générative ce que l’injection Structured Query Language (SQL) fut aux bases de données : l’attaque fondamentale, celle qui exploite la confusion entre données et instructions. Le National Institute of Standards and Technology (NIST) a qualifié l’injection indirecte de « plus grande faille de sécurité de l’IA générative », et l’OWASP la classe au premier rang de son palmarès.

L’illustration la plus parlante est récente. En juin 2025, les chercheurs d’Aim Security (Aim Labs) ont divulgué EchoLeak (référencée CVE-2025-32711, score critique de 9,3) : la première attaque par injection de prompt « zéro clic » documentée contre un outil de productivité d'entreprise, Microsoft 365 Copilot. Un simple e-mail piégé suffisait. Sans aucune action de la victime, Copilot traitait les instructions dissimulées dans le message et exfiltrait des données internes — fichiers, conversations, contenus SharePoint. Les chercheurs ont baptisé le mécanisme « violation de périmètre du LLM » (LLM scope violation), où une entrée externe non fiable amène le modèle à accéder à des données privilégiées et à les divulguer. Microsoft a corrigé la faille côté serveur, sans exploitation constatée.

2. L’empoisonnement des données et du modèle (LLM04)

L’empoisonnement (data poisoning) vise les phases d’entraînement ou d’affinage : en injectant des exemples malveillants, un attaquant introduit une porte dérobée (backdoor) déclenchée par un motif particulier. On supposait jusqu’ici qu’il fallait contrôler un pourcentage significatif des données d’entraînement. Une étude conjointe d’Anthropic, de l’UK AI Security Institute et de l’Alan Turing Institute, publiée en octobre 2025 et présentée comme la plus vaste enquête du genre, a renversé cette hypothèse : environ 250 documents malveillants suffisent à implanter une porte dérobée, et ce, quel que soit le nombre de paramètres du modèle — d’un modèle de 600 millions à un modèle de 13 milliards de paramètres. Le risque ne dépend pas d’un pourcentage, mais d'un nombre absolu, trivial à atteindre. Pour les organisations qui affinent un modèle sur leurs propres données, la chaîne d'approvisionnement de ces données devient une surface d'attaque de premier ordre.

3. Le traitement non sécurisé des sorties (LLM05)

Les modèles produisent du texte — mais ce texte peut être interprété comme du code, du HTML ou des commandes par les composants situés en aval. Plusieurs scénarios concrets en découlent. Une sortie de modèle affichée sans échappement dans une interface web devient un vecteur d’injection de script (XSS). Une sortie transmise à un interpréteur de commandes peut entraîner une exécution arbitraire. Plus subtil, et bien réel : EchoLeak exploitait notamment des images au format Markdown automatiquement chargées par le client pour exfiltrer les données vers un serveur contrôlé par l’attaquant — la sortie du modèle servant elle-même de canal de fuite. Le principe directeur est sans appel : toute sortie de LLM doit être traitée comme une donnée non fiable, même lorsqu'elle paraît anodine.

4. L’autonomie excessive (LLM06) — la question du rayon d’action

Les agents modernes disposent d’un accès à des outils puissants : navigateur, système de fichiers, API métier, bases de données. L’autonomie excessive désigne la situation où un agent dispose de privilèges disproportionnés au regard de ses besoins réels — une violation du principe de moindre privilège. La campagne GTG-1002 évoquée plus haut en est la démonstration grandeur nature : un agent suffisamment outillé et autonome, une fois détourné, a pu enchaîner reconnaissance, exploitation, collecte d'identifiants et exfiltration à un rythme « impossible pour des opérateurs humains », selon Anthropic. La leçon est constante : plus on confère de capacités à un agent pour qu’il soit utile, plus on élargit la surface de dommage en cas de compromission.

Recommandations à l’intention des équipes de sécurité

• Traiter toute entrée comme non fiable, à tous les niveaux, y compris le prompt système lui-même.
• Déployer des garde-fous en entrée comme en sortie. Certains WAF (Web Application Firewall) et CDN (Content Delivery Network) proposent désormais des protections spécifiques : Cloudflare, par exemple, a lancé « AI Security for Apps » (ex-Firewall for AI), un pare-feu indépendant du modèle qui détecte les tentatives d’injection de prompt, attribue un score à chaque requête et adresse plusieurs risques du Top 10 LLM de l'OWASP.
• Appliquer strictement le principe de moindre privilège à l’ensemble des outils exposés aux agents.
  Auditer la chaîne d’approvisionnement des données d’entraînement avec la rigueur d'une chaîne logicielle.
• Intégrer des tests adversariaux (red teaming de LLM) dans les chaînes d’intégration continue.
• Superviser les usages atypiques : volume et nature des requêtes, latences, taux d’erreur.