OWASP LLM Top 10 (2025) : quels risques une passerelle corrige-t-elle réellement

Ce qu'est réellement l'OWASP LLM Top 10

Le OWASP Top 10 pour les applications de grands modèles de langage (LLM) est une liste consensuelle des risques de sécurité les plus critiques pour les logiciels basés sur les LLM, maintenue par le projet OWASP GenAI Security. La version actuelle est la liste 2025 disponible sur genai.owasp.org/llm-top-10. La version 1.1 de 2023/24 y est toujours archivée et largement citée ; ainsi, si une publication mentionne le vol de modèle ou la dépendance excessive, elle fait référence à la version retirée.

La liste 2025 telle que publiée par l'OWASP :

Les changements indiquent où l'attention s'est portée. La fuite de prompt système et les faiblesses des vecteurs et des embeddings sont nouveaux. Le déni de service de modèle est devenu le plus large Consommation illimitée. Conception de plugins non sécurisée intégrée à la chaîne d'approvisionnement et agence excessive à mesure que les outils se sont structurés autour de protocoles comme le MCP. Vol de modèle a complètement disparu.

Où se situent réellement les contrôles

C'est la partie que la plupart des articles omettent. Les classements du Top 10 risques, et un risque n'est pas une fonctionnalité produit. Quatre appartiennent au chemin d'inférence, là où se trouve une passerelle. Trois relèvent du code applicatif. Trois concernent des pipelines qu'une passerelle ne voit jamais.

Quatre sont directement concernés, trois partiellement, et trois nécessitent un responsable ailleurs. Si votre cadre de sécurité IA comporte une ligne de passerelle pour LLM04 et LLM08, cette ligne est purement décorative.

Une passerelle couvre bien LLM01, LLM02, LLM06 et LLM10 car ces quatre problèmes sont liés au chemin de requête : ils surviennent au moment précis où une requête est envoyée ou un outil déclenché, ce qui est le seul moment où une passerelle intervient. Les autres ont été décidés des semaines auparavant, lors d'une phase d'entraînement ou d'une tâche d'indexation.

Où les équipes se trompent

Traiter cette liste comme une simple liste de contrôle de conformité. L'OWASP publie une taxonomie des risques accompagnée de conseils d'atténuation, et non une certification. Il n'existe aucun audit OWASP LLM Top 10 ni aucun organisme délivrant une validation. Une matrice prétendant que les dix points sont « couverts » par un seul outil est conçue pour survivre à une réunion, pas à une attaque.

Placer la validation des sorties au mauvais endroit. LLM05 concerne la manière dont votre application traite les résultats générés par le modèle. Une passerelle peut signaler qu'une réponse contient os.system ou une balise de script non échappée. Elle ne peut cependant pas empêcher votre service d'injecter cette chaîne dans un shell. Le contrôle doit s'exercer là où le résultat est consommé ; la vérification par la passerelle constitue une défense en profondeur.

Considérer la détection d'injection comme une prévention. La détection repose sur un classificateur, et les classificateurs présentent des faux négatifs, tandis que les attaquants s'adaptent pour les contourner. La mesure d'atténuation durable pour LLM01 consiste à admettre que l'injection peut parfois réussir et à rendre le système résilient — ce qui relève en réalité de la problématique LLM06. Réduisez la surface d'exposition aux outils, et une injection réussie atteindra un modèle sans aucune fonction dangereuse à appeler.

Ignorer LLM10 en le considérant comme une simple question de facturation. Un agent bloqué dans une boucle constitue un déni de service pour votre propre budget, et les requêtes à haut volume sont la méthode utilisée pour l'extraction de modèles. C'est la porte d'entrée la plus facile à verrouiller, et pourtant celle qui est le plus souvent laissée ouverte.

Want to see which of these you can close today?

Attach a guardrail group to a single model and watch it fire in Request Traces.

Get started free

Comment cela fonctionne dans TrueFoundry

L'AI Gateway de TrueFoundry implémente ces contrôles sous forme de garde-fous sur des hooks situés dans le chemin de la requête. Il en existe quatre, et les risques que vous pouvez traiter dépendent du hook utilisé.

Pour les requêtes LLM : input, avant que le prompt n'atteigne le modèle, et output, après que celui-ci a répondu.

Pour les appels d'outils MCP : mcp_pre_tool, avant l'exécution de l'outil, et mcp_post_tool, après son retour.

Ces hooks MCP rendent le OWASP MCP question tractable. Les garde-fous s'exécutent sur chaque appel d'outil séparément - cinq outils à la suite signifient cinq séries de vérifications. Un échec avant l'exécution de l'outil empêche son lancement ; un échec après l'exécution bloque le résultat.

Chaque garde-fou possède un mode de fonctionnement - « validate » inspecte et peut bloquer, « mutate » réécrit également - ainsi qu'une stratégie d'application couvrant les violations et les erreurs de garde-fou :

‍