OWASP pour les applications IA : risques et contrôles prioritaires

OWASP propose des ressources utiles pour parler des risques des applications IA, notamment les LLM et agents, mais elles ne remplacent pas la compréhension de votre architecture. Une liste de risques ne devient pas un plan de sécurité tant qu’elle n’est pas reliée à des données, des outils, des identités et des actions réels. Utilisez OWASP comme une grille pour poser de meilleures questions, pas comme une certification automatique.

La priorité dépend de l’impact concret. Un chatbot documentaire en lecture seule n’a pas le même profil qu’un agent capable d’envoyer un email, modifier une base ou appeler des outils externes. Plus l’agent peut agir, plus les permissions, validations et journaux doivent être examinés en premier.

Ce que vous allez apprendre

Vous allez transformer un référentiel OWASP en revue adaptée à votre application : cartographier les flux, associer les risques aux composants, choisir des contrôles proportionnés, ajouter des tests négatifs et suivre les corrections. Le guide reste non prescriptif : un contrôle n’est pertinent que si son effet peut être observé dans votre environnement.

Prérequis

• Une description de l’application, de ses utilisateurs et de ses actions possibles.
• L’inventaire des modèles, fournisseurs, outils, bases et connecteurs utilisés.
• La liste des données personnelles, confidentielles ou non fiables qui traversent le système.
• Un propriétaire par composant et un canal de gestion des risques.
• Un environnement de test pour vérifier les contrôles sans toucher la production.

Ne commencez pas par classer tous les risques de la même façon. Un catalogue sert à guider l’enquête ; votre analyse doit préciser ce qui est présent, absent ou non vérifié.

1. Cartographier l’application avant le référentiel

Décrivez le chemin d’une demande : entrée utilisateur, documents consultés, contexte envoyé au modèle, sorties générées, outils appelés, stockage et journaux. Ajoutez les frontières externes : API de modèle, stockage, recherche web, systèmes métiers, emails et webhooks. Indiquez aussi quels composants peuvent écrire ou déclencher une action.

Cette carte rend visibles les risques les plus fréquents. Une instruction malveillante dans un document concerne l’entrée et l’agent ; une fuite de secret concerne les variables, logs ou appels externes ; une dépendance compromise concerne la chaîne de build et les serveurs d’outils. Sans cette carte, on applique des contrôles au hasard.

Vérification : choisissez un parcours utilisateur réel et confirmez pour chaque étape ce qui est lu, envoyé, modifié et journalisé. Toute zone inconnue devient un point de revue, pas une supposition de sécurité.

2. Lire les risques OWASP comme des scénarios

Les ressources OWASP consacrées aux LLM traitent notamment de l’injection de prompt, de la gestion des sorties, de la divulgation d’informations sensibles, des dépendances et des permissions excessives. Au lieu de chercher une correspondance théorique, formulez chaque thème comme un scénario : « une source non fiable peut-elle provoquer une action ? », « une sortie de modèle devient-elle une requête sans validation ? », « un secret peut-il apparaître dans un contexte ou un log ? ».

Pour les agents, examinez aussi les outils. Un outil peut avoir une description, des paramètres et un résultat qui influencent le modèle. Son origine, sa version, ses permissions, ses domaines réseau et sa procédure de révocation font partie de la sécurité de l’application, pas seulement de l’infrastructure.

Vérification : pour chaque scénario retenu, citez le composant concerné, l’action possible et la preuve qui montrerait que le risque est réduit. Évitez les constats du type « OWASP recommande » sans effet observable.

3. Prioriser par impact et capacité d’action

Commencez par les chemins où une entrée non fiable peut atteindre un privilège élevé : accès à des secrets, écriture de données, publication, paiement, suppression, administration ou exfiltration réseau. Ajoutez ensuite les données les plus sensibles et les composants les moins observables. Un risque peu probable mais irréversible peut mériter une action avant une anomalie fréquente sans conséquence métier.

Ne confondez pas une note numérique avec une décision. Décrivez l’exposition, le privilège requis, les contrôles existants, les preuves manquantes et le propriétaire de la correction. Cette formulation permet à une équipe produit, sécurité et exploitation de discuter du compromis sans prétendre à une précision artificielle.

Vérification : faites relire les priorités par le propriétaire métier. Il doit pouvoir expliquer quelles actions l’application ne doit jamais pouvoir accomplir automatiquement.

4. Appliquer des contrôles proportionnés

Pour une injection de prompt, réduisez l’effet possible : séparez les données des règles, limitez les outils, restreignez les fichiers et validez les actions externes. Pour une sortie générée, utilisez un schéma, des allowlists de paramètres et une validation métier avant toute exécution. Pour les secrets, donnez des identités limitées et révocables, évitez leur présence dans les prompts et logs, puis testez leur retrait.

Pour les dépendances et serveurs d’outils, épinglez les versions quand cela est possible, vérifiez l’origine, examinez les changements de permissions et gardez une procédure de désactivation. Pour les données, minimisez la collecte, séparez les environnements et définissez la durée de conservation. Aucun contrôle isolé ne suffit : les couches se complètent.

Vérification : associez chaque contrôle à un test positif et négatif. Par exemple, la tâche autorisée doit fonctionner ; une destination non autorisée ou une écriture hors périmètre doit échouer.

5. Tester et observer les contrôles

Construisez des jeux de test non sensibles qui contiennent une demande hors contrat, une donnée ambiguë ou une destination invalide. Le résultat souhaité n’est pas que le modèle « reconnaisse » tous les cas, mais que les interfaces refusent les actions non permises. Testez aussi une clé révoquée, un outil absent et un redémarrage : les erreurs doivent rester utiles sans exposer de détails sensibles.

Journalisez les décisions importantes : version de l’agent, outil demandé, paramètres validés, résultat, refus et incident. N’enregistrez pas intégralement les contenus ou secrets par défaut. Les journaux doivent permettre de comprendre un comportement sans devenir une fuite de données secondaire.

Vérification : exécutez un scénario de refus de bout en bout et vérifiez à la fois l’absence d’action externe et la trace redactionnée qui permet de l’expliquer.

6. Piloter les corrections dans le temps

Pour chaque écart, créez une action limitée, un propriétaire et une condition de fermeture. « Sécuriser l’agent » n’est pas une tâche testable ; « remplacer le token global par une clé de lecture dédiée et confirmer le refus de l’ancienne » l’est. Distinguez les risques acceptés temporairement, les correctifs en cours et les éléments non vérifiés.

Reprenez la revue après un changement de modèle, de connecteur, de fournisseur, de permission ou de type de données. La sécurité des applications IA dérive avec leur surface d’outils : une configuration acceptable pour un résumé en lecture seule peut devenir insuffisante dès qu’un agent publie ou exécute des actions.

Problèmes fréquents et solutions

La liste OWASP est traitée comme une checklist à cocher. Reliez chaque thème à une architecture et une preuve ; les éléments non applicables doivent être justifiés, pas ignorés.

Une règle de prompt est la seule défense. Ajoutez les permissions techniques, les validations de sorties et les limites de réseau. Les instructions textuelles ne remplacent pas les contrôles.

Les outils disposent d’un token global. Créez des identités par tâche ou service, réduisez leur scope et testez la révocation.

Les logs sont trop pauvres ou trop riches. Conservez les événements nécessaires à l’audit, filtrez les secrets et limitez l’accès et la rétention.

FAQ

OWASP est-il obligatoire pour une application IA ?

Il fournit des ressources largement utilisées, mais les obligations applicables dépendent de votre organisation, secteur et juridiction. Utilisez-le comme une base de travail, pas comme un substitut à vos exigences.

Faut-il traiter tous les risques OWASP ?

Évaluez-les tous à un niveau adapté, puis priorisez ceux qui correspondent réellement à vos données, outils et actions. Documentez ce qui est hors périmètre et pourquoi.

Les agents sont-ils plus risqués que les chatbots ?

Ils peuvent l’être lorsqu’ils disposent d’outils ou d’actions externes. Le risque dépend surtout de la capacité d’impact et des validations, pas du seul nom du produit.

Comment prouver qu’un contrôle fonctionne ?

Par un test représentant une action normale et un test négatif qui démontre le refus de l’action non autorisée, complétés par des traces redactionnées.

À quelle fréquence revoir l’analyse ?

Après toute évolution de modèle, d’outil, de données, d’identité ou d’exposition, ainsi que selon un calendrier de revue défini.

Conclusion

Utiliser OWASP pour les applications IA aide à transformer des risques généraux en décisions concrètes : limiter les permissions, valider les actions, protéger les données et tester les refus. La priorité n’est pas de cocher un référentiel, mais de réduire les scénarios où une entrée non fiable obtient plus d’accès ou d’impact que prévu.

Sources et limites

Sources primaires : OWASP Top 10 for LLM Applications, OWASP GenAI Security Project et OWASP Application Security Verification Standard. Les thèmes et éditions évoluent ; vérifiez la version applicable à votre revue. Ce guide ne constitue ni une certification ni une garantie de conformité.