OWASP LLM Top 10 (2025) : les risques qu'une Gateway résout réellement

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

Le OWASP Top 10 pour les applications basées sur les modèles de langage (LLM) est une liste consensuelle des risques de sécurité les plus critiques dans les logiciels s'appuyant sur des LLM, maintenue par le OWASP GenAI Security Project. La version actuelle est la liste 2025 disponible sur genai.owasp.org/llm-top-10. La liste v1.1 de 2023/24 y est toujours archivée et largement citée - ainsi, si un article mentionne Model Theft ou Overreliance, il décrit la version obsolète.

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

L'évolution montre où l'attention s'est déplacée. System Prompt Leakage et Vector and Embedding Weaknesses sont nouveaux. Model Denial of Service a évolué vers le concept plus large de Unbounded Consumption. Insecure Plugin Design a été intégré dans la supply chain et l'excessive agency à mesure que l'outillage s'est stabilisé autour de protocoles comme MCP. Model Theft a complètement disparu.

Où réside réellement chaque contrôle

C'est la partie que la plupart des analyses omettent. Le Top 10 répertorie des risques, et un risque n'est pas une fonctionnalité produit. Quatre appartiennent au parcours d'inférence, là où se situe une gateway. Trois appartiennent au code de l'application. Trois appartiennent aux pipelines qu'une gateway ne voit jamais.

Quatre sont pleinement dans son périmètre, trois le sont partiellement, et trois nécessitent un responsable ailleurs. Si votre framework de sécurité AI comporte une ligne gateway pour LLM04 et LLM08, cette ligne est décorative.

Une gateway couvre efficacement LLM01, LLM02, LLM06 et LLM10 car tous quatre sont des problèmes liés au parcours de la requête : ils surviennent au moment précis où un prompt est envoyé ou qu'un outil est déclenché, ce qui est l'unique moment visible par la gateway. Les autres ont été décidés des semaines plus tôt, lors d'une session d'entraînement ou d'une tâche d'indexation.

Les erreurs fréquemment commises par les équipes

Traiter la liste comme une checklist de conformité. L'OWASP publie une taxonomie des risques accompagnée de conseils d'atténuation, et non une certification. Il n'existe pas d'audit OWASP LLM Top 10 ni d'organisme qui délivre un certificat. Une matrice affirmant que les dix points sont « couverts » par un seul outil est conçue pour passer une réunion, pas pour résister à une attaque.

Placer la validation de sortie au mauvais endroit. LLM05 concerne l'usage que fait votre application de la sortie du modèle. Une gateway peut signaler qu'une réponse contient os.system ou une balise script non échappée. Elle ne peut pas empêcher votre service de transmettre cette chaîne à un shell. Le contrôle appartient à l'endroit où la sortie est consommée ; le contrôle de la gateway relève de la défense en profondeur.

Supposer que la détection d'injection équivaut à la prévention. La détection repose sur un classificateur, les classificateurs comportent des faux négatifs, et les attaquants s'adaptent. L'atténuation durable pour LLM01 consiste à assumer qu'une injection réussira parfois et à faire en sorte que le système y survive - ce qui relève en réalité d'un problème LLM06. Restreignez la surface des outils pour qu'une injection réussie atteigne un modèle sans aucune fonction dangereuse à appeler.

Ignorer LLM10 comme simple préoccupation de facturation. Un agent bloqué dans une boucle constitue un déni de service contre votre propre budget, et les requêtes à fort volume sont le moyen par lequel l'extraction de modèle s'effectue. C'est la porte la plus facile à fermer, et la plus souvent laissée ouverte.

Vous voulez voir lesquels vous pouvez corriger dès aujourd'hui ?

Associez un groupe de guardrails à un modèle unique et observez son déclenchement dans les Request Traces.

Commencer gratuitement

Comment cela fonctionne dans TrueFoundry

L'AI Gateway de TrueFoundry implémente ces contrôles sous forme de guardrails sur des hooks situés dans le parcours de la requête. Il y en a quatre, et les risques que vous pouvez traiter dépendent du hook sur lequel vous vous positionnez.

Pour les requêtes LLM : input, avant que le prompt n'atteigne le modèle, et output, après sa réponse.

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 la question du mcp owasp abordable. Les guardrails s'exécutent sur chaque appel d'outil séparément - cinq outils à la suite impliquent cinq séries de vérifications. Un échec en pre-tool signifie que l'outil ne s'exécute jamais ; un échec en post-tool retient le résultat.

Chaque guardrail dispose d'un mode d'opération - validate inspecte et peut bloquer, mutate réécrit également - et d'une stratégie d'application couvrant les violations et les erreurs de guardrails :

LLM01: Prompt Injection

Le guardrail natif Prompt Injection est propulsé par Azure Prompt Shield et géré par TrueFoundry, sans nécessiter de clés tierces. Il analyse séparément le prompt de l'utilisateur et tout contenu de document ou de contexte, de sorte qu'une injection indirecte masquée dans un document récupéré est détectée au même titre qu'un « ignore all previous instructions » direct. Mode Validate uniquement. Ajoutez-le depuis la section Guardrails :

Il s'exécute sur LLM Input et MCP Pre Tool, où il recherche les injections au sein des paramètres d'outils. Pour utiliser vos propres identifiants fournisseurs, AWS Bedrock Guardrails réalise la même tâche - activez Prompt Attack, définissez l'action sur Block, puis enregistrez-le :

LLM02: Sensitive Information Disclosure

Deux fonctionnalités natives couvrent la majeure partie de ce besoin. PII / PHI Detection identifie les noms, adresses, SSN et numéros de dossiers médicaux avec des catégories d'entités configurables. Secrets Detection repère les clés AWS, les clés API OpenAI et Anthropic, les tokens GitHub et GitLab, les JWT, les clés privées, les chaînes de connexion à des bases de données et les chaînes à haute entropie situées à proximité de mots-clés comme api_key.

Secrets Detection est essentiel à comprendre : c'est le seul module natif qui s'exécute sur les quatre hooks, et chacun intercepte un échec différent.

Il s'exécute au sein de la gateway sans appels API externes, et en mode mutate, il remplace les éléments détectés par un texte configurable, ***REDACTED*** par défaut. Pour les PII sur des déploiements auto-hébergés, Azure PII avec votre propre clé, Presidio via un guardrail personnalisé, ou le filtre de Bedrock fonctionnent tous très bien.

LLM06: Excessive Agency

C'est ici que les hooks MCP prennent tout leur sens. SQL Sanitizer intercepte les requêtes DROP, TRUNCATE, DELETE ou UPDATE sans clause WHERE, ainsi que l'interpolation de chaînes. Code Safety Linter signale eval, exec, os.system, les appels subprocess et les commandes shell dangereuses. Cedar et OPA appliquent des politiques précises de type « deny by default » aux appels d'outils MCP.

En dessous réside le modèle d'accès, la partie la plus importante du LLM06 : les outils peuvent être désactivés pour ne jamais apparaître dans tools/list, les appels sensibles peuvent exiger un MCP Server Approver, et l'OAuth par utilisateur garantit que le système en amont évalue les permissions réelles de l'utilisateur actif plutôt que celles d'un token partagé. Notre article sur le contrôle d'accès MCP détaille cette couche.

LLM10: Unbounded Consumption

Il ne s'agit pas du tout d'un guardrail - c'est la configuration de la limitation de débit et du budget, soit la couverture la plus complète de la liste. Les règles s'appliquent selon le sujet, le modèle ou les métadonnées et plafonnent les requêtes ou les tokens par minute, heure ou jour :

rate_limit_applies_per accepte user, virtualaccount, model, ou metadata.*, jusqu'à deux par règle, afin que chaque entité dispose de son propre compteur au lieu d'entrer en compétition sur un compteur partagé. L'application utilise une fenêtre glissante ; un dépassement de limite renvoie un code HTTP 429 avec un en-tête x-tfy-applied-rules indiquant la règle appliquée :

Le reste de la liste

LLM09 Misinformation est partiellement traitable via des prestataires externes - Patronus AI et Fiddler proposent des évaluateurs d'hallucination et de fidélité des réponses sur le hook de sortie. Considérez-les comme un signal, pas comme une correction définitive.

LLM05 Improper Output Handling bénéficie de Code Safety Linter et de Secrets Detection sur le hook de sortie. Ni l'un ni l'autre ne remplace la validation dans votre propre code.

LLM03, LLM04 et LLM08 marquent la limite de notre intervention. La supply chain concerne les achats et le pipeline de build ; la seule contribution de la gateway consiste à contrôler quels modèles et serveurs MCP existent dans votre registre. L'empoisonnement se produit pendant l'entraînement. Les faiblesses vectorielles résident dans le pipeline RAG sur lequel la gateway n'intervient pas. Si un fournisseur prétend le contraire, demandez-lui sur quel hook s'exécute son contrôle.

Un exemple concret

Prenons l'exemple d'un agent de support qui lit les tickets clients et interroge une base de données de production via MCP. Quatre des dix risques sont actifs, nécessitant quatre contrôles distincts.

Étape une - enregistrer les guardrails. Créez un groupe de guardrails et ajoutez Prompt Injection, PII Detection et Secrets Detection. Si aucun module natif ne convient, utilisez un Custom Guardrail pointant vers votre propre endpoint HTTPS :

Un guardrail personnalisé reçoit le requestBody au format OpenAI, un objet de configuration défini dans le formulaire, et un contexte véhiculant le sujet appelant. Pour les guardrails d'outils MCP, context.metadata transporte également un objet claims contenant les revendications vérifiées du JWT de l'appelant, ce qui vous permet d'autoriser par application ou par scope :

Un détail du contrat piège souvent les utilisateurs : renvoyez HTTP 2xx avec verdict: false pour refuser. Un code 400 est interprété comme une erreur d'exécution, et sous la règle enforce_but_ignore_on_error, la requête est autorisée à passer.

Étape deux - rédiger la politique. Enregistrer un guardrail ne l'applique à rien. Dans Policies → Guardrails, créez une règle définissant quels guardrails s'exécutent sur quels hooks, pour quels modèles, serveurs MCP, sujets et métadonnées.

Pour cet agent : Prompt Injection sur LLM Input (LLM01) ; PII Detection sur Input et Secrets Detection sur Output (LLM02) ; SQL Sanitizer sur MCP Pre-Invoke et Secrets Detection sur Post-Invoke (LLM06). Une règle de limitation de débit avec rate_limit_applies_per: ['user'] traite le point LLM10.

Toutes les règles sont évaluées par requête et les règles correspondantes s'assemblent par hook, ainsi une règle de base et une règle de production plus stricte s'appliquent toutes deux. Un Custom Error Message utilisant {{failed_guardrails}} prévaut sur la sortie brute du fournisseur.

Étape trois - observez avant de faire confiance. Démarrez chaque guardrail en mode Audit. Chacun apparaît sous la forme d'un span dédié dans Monitor → Request Traces, indiquant la latence, le résultat, le périmètre et les détections :

Passez ensuite à Enforce But Ignore On Error, qui bloque les violations sans laisser une panne du fournisseur interrompre votre application. N'utilisez le mode Enforce complet que là où la conformité l'exige strictement.

Prêt à traiter les quatre risques gérés par une Gateway ?

Associez un groupe de guardrails et une règle de limitation de débit à votre premier modèle en quelques minutes.

Commencer gratuitement sur TrueFoundry

Les pièges à connaître

Les guardrails de sortie ne s'exécutent pas sur les réponses en streaming. Lorsque stream: true est activé, ils sont complètement ignorés - l'évaluation d'une réponse nécessite le texte complet, or le streaming livre les tokens au fur et à mesure de leur génération. Cela a son importance pour la couverture LLM02 et LLM05, car l'interface de chat déployée par la majorité utilise le streaming par défaut. Définissez stream: false là où les contrôles de sortie sont essentiels, validez côté client, ou acceptez que vos contrôles sur le hook de sortie soient inactifs. Les guardrails d'entrée ne sont pas impactés.

Les system prompts sont exclus des guardrails par défaut. La gateway les retire avant d'envoyer le contenu à un guardrail, ils ne sont donc jamais inspectés, bloqués ou masqués. CrowdStrike AIDR fait seule exception - elle voit le system prompt mais ne le modifie jamais. Bon à savoir pour LLM07 : la gateway surveille les tentatives d'exfiltration à l'entrée et les secrets à la sortie, pas le prompt lui-même.

Où les échecs de validation coûtent de l'argent. La validation d'entrée s'exécute en parallèle de la requête modèle ; si elle échoue, la gateway annule l'appel en cours pour vous éviter de payer. La validation de sortie s'exécute après l'arrivée de la réponse - le blocage protège votre utilisateur, mais les tokens ont été consommés.

Trois fonctionnalités natives sont réservées au SaaS. Content Moderation, PII / PHI Detection et Prompt Injection ne sont pas disponibles sur les déploiements auto-hébergés. Des alternatives existent - Azure Prompt Shield ou Palo Alto Prisma AIRS pour l'injection, Azure PII ou CrowdStrike pour les PII, OpenAI Moderations ou Bedrock Guardrails pour la modération - mais elles nécessitent vos propres identifiants.

Lectures associées

• Construire un framework de gouvernance IA — la couche politique à laquelle ces contrôles se rapportent
• Sécurité MCP — le côté appel d'outil de LLM06 en détail
• Contrôle d'accès MCP — les permissions au niveau des outils et des serveurs en pratique
• Qu'est-ce qu'une Gateway MCP — l'emplacement du point d'application des règles
• Authentification API et RBAC dans l'AI Gateway — qui peut appeler quoi, avant l'exécution des guardrails

Conclusion

Le OWASP LLM Top 10 est une excellente liste souvent mal utilisée. En tant que taxonomie, elle vous indique ce qui peut mal tourner et dans quel ordre approximatif s'en soucier. En tant que checklist à cocher d'un seul achat, elle produit une matrice de contrôle en apparence complète mais qui ne défend rien.

La question utile n'est pas « ce produit couvre-t-il le Top 10 », mais « lesquels de ces dix risques surviennent dans le parcours de la requête, et y a-t-il un contrôle actif à cet endroit ». Quatre répondent à ce critère. Une gateway est l'emplacement idéal pour ces quatre-là, et le seul endroit où vous pouvez les appliquer de manière centralisée sur l'ensemble des modèles, équipes et agents au lieu de demander à dix équipes applicatives de le gérer individuellement.

Pour les six autres, identifiez le responsable. La supply chain concerne la personne qui approuve les modèles. L'empoisonnement concerne l'équipe qui gère l'entraînement. Les faiblesses vectorielles appartiennent à l'équipe qui a conçu l'index. Inscrivez leurs noms à côté des risques. Ce document a bien plus de valeur que la déclaration de couverture de n'importe quel fournisseur, y compris la nôtre.

Tritez les quatre risques gérés par une Gateway

Commencer gratuitement sur TrueFoundry