Audit de sécurité d’un projet IA : méthode de revue et plan de correction

Un audit de sécurité d’un projet IA ne commence pas par un scan ou une tentative d’exploitation. Il commence par une question simple : quels composants, données, identités et actions sont réellement dans le périmètre ? Un agent, une API de modèle, un serveur d’outils, une base, un dashboard et un stockage d’uploads peuvent avoir des risques très différents. Sans inventaire et autorisation, un test technique peut créer plus de confusion que de preuve.

Cette méthode est non intrusive. Elle aide à organiser une revue de conception et de configuration avant toute action active. Pour un test de pénétration, une vérification de production ou un environnement réglementé, obtenez un mandat, une fenêtre et des règles d’engagement explicites.

Ce que vous allez apprendre

Vous allez délimiter l’audit, cartographier les flux de données et permissions, examiner les secrets et dépendances, relire la journalisation, classer les écarts et produire un plan de correction vérifiable. L’objectif n’est pas une note abstraite : chaque constat doit avoir une preuve, un impact, un propriétaire et un critère de fermeture.

Prérequis

• Un sponsor qui précise l’objectif et les composants autorisés.
• Un inventaire initial des services, environnements et comptes de service.
• L’accès en lecture aux configurations et à la documentation pertinente.
• Une politique de traitement des données d’audit et des secrets rencontrés.
• Un canal pour signaler immédiatement un risque critique sans l’exposer dans un rapport large.

N’incluez pas de secrets bruts, de données personnelles ou de vulnérabilités exploitables dans un document de travail partagé. Référencez-les par emplacement contrôlé et limitez qui peut consulter les détails.

1. Cadrer le périmètre et les règles

Documentez les applications, environnements, dates, personnes de contact et activités autorisées. Distinguez lecture de configuration, revue de code, tests automatisés, appels d’API et toute activité susceptible de modifier un état. Définissez également les exclusions : production, données réelles, fournisseurs tiers ou systèmes sans propriétaire disponible.

Un projet IA peut dépendre d’un modèle distant, de prompts, d’outils, de connecteurs et de données externes. Précisez lequel de ces éléments est audité et lequel est seulement constaté. Une promesse « audit complet » n’a pas de sens si les outils appelés par l’agent restent inconnus.

Vérification : faites valider le périmètre par le sponsor et les propriétaires techniques. Toute modification de périmètre doit être ajoutée au journal avant d’être examinée.

2. Cartographier les données et les frontières

Suivez les données depuis l’entrée jusqu’au stockage ou à la sortie : demande utilisateur, documents joints, prompt construit, appel de modèle, résultat d’outil, log, base et webhook. Marquez les données sensibles, les identifiants, les fichiers non fiables et les destinations externes. L’objectif est de rendre visibles les moments où un contenu peut influencer un agent ou quitter le périmètre prévu.

Ne supposez pas qu’une donnée est sûre parce qu’elle est interne. Un ticket, une page wiki ou un résultat d’outil peut être erroné, compromis ou simplement conçu pour un autre usage. Les frontières d’autorité doivent rester dans la configuration et les validations, pas dans le texte lu par le modèle.

Vérification : choisissez un parcours réel et demandez à chaque étape : qui lit, qui écrit, où la donnée est conservée et quelles données sont envoyées à un tiers ? Les étapes sans réponse deviennent des écarts à investiguer.

3. Examiner identités et permissions

Listez les comptes humains, comptes de service, clés API, rôles cloud, tokens de CI et identités d’outils. Pour chacun, indiquez le propriétaire, la portée, la durée de vie, le lieu de stockage et la procédure de révocation. Cherchez les privilèges qui dépassent la tâche : clé de lecture qui écrit, token de développement utilisé en production, agent autorisé à exécuter un shell général ou connecteur qui accède à tout un espace de travail.

Les actions externes doivent être limitées par des interfaces étroites et, lorsque leur conséquence est forte, validées indépendamment. Un modèle ne doit pas pouvoir s’accorder de nouveaux droits à partir d’une instruction contenue dans une source de données.

Vérification : sélectionnez un compte à risque et suivez son utilisation depuis sa création jusqu’à sa révocation. Vérifiez que l’ancien identifiant échoue réellement après retrait.

4. Revoir secrets et dépendances

Recherchez les secrets dans le code, les variables d’environnement, les fichiers de build, les journaux et les configurations d’outil. Une clé trouvée dans un dépôt ou une image doit être traitée comme potentiellement exposée : documentez l’emplacement sous contrôle, révoquez-la selon le processus prévu et empêchez sa réintroduction avec un contrôle adapté.

Inventoriez les dépendances directes, images de conteneurs, plugins et serveurs d’outils. Vérifiez leur origine, version, mainteneur, licence et mécanisme de mise à jour. Pour les composants qui donnent à un agent accès à des fichiers ou à des actions, examinez aussi leur contrat d’outils, les domaines réseau et les données retournées. Une dépendance fonctionnelle peut introduire une nouvelle frontière de confiance.

Vérification : pour une dépendance critique, confirmez quelle version est déployée, d’où elle vient et comment elle serait remplacée ou désactivée en cas d’incident.

5. Évaluer logs et supervision

Les logs doivent aider à comprendre une décision et une erreur sans devenir une copie intégrale des conversations ou secrets. Vérifiez les identifiants de corrélation, les événements de permission, les échecs d’outil, les changements de configuration et les alertes d’accès anormal. Examinez qui lit les journaux, combien de temps ils sont conservés et comment les données sensibles sont filtrées.

Contrôlez aussi les angles morts : un agent peut appeler une API ou générer une action sans que le propriétaire puisse lier l’événement à une tâche. La supervision utile suit le comportement opérationnel, pas seulement la disponibilité du serveur.

Vérification : prenez un incident bénin de test et vérifiez que vous pouvez identifier l’agent, l’outil, la décision de validation et le résultat, sans retrouver de token ou de contenu privé dans les traces.

6. Classer les écarts et planifier les corrections

Chaque constat doit distinguer fait observé, impact plausible, condition nécessaire et incertitude. Classez le risque selon l’exposition, le privilège, la sensibilité des données et la capacité de détection ou de reprise. Évitez les scores précis sans modèle explicite ; une priorité compréhensible avec une preuve est plus actionnable qu’un chiffre décoratif.

Pour chaque correction, indiquez le propriétaire, la date cible, le changement prévu et le contrôle de fermeture. Par exemple, « réduire le scope d’un token » se ferme lorsque le token est remplacé, l’ancien refusé et une tâche normale validée. Une recommandation sans preuve de fermeture reste ouverte.

Vérification : relisez le plan avec les équipes produit et exploitation. Elles doivent pouvoir identifier ce qui est urgent, ce qui est accepté temporairement et ce qui doit être retesté après correction.

Problèmes fréquents et solutions

Le périmètre est vague. Arrêtez les conclusions globales, faites valider une carte des systèmes et séparez ce qui est vérifié de ce qui ne l’est pas.

Le rapport contient des secrets. Retirez-les du document partagé, stockez les détails dans le canal sécurisé prévu et lancez la révocation nécessaire.

Une recommandation est trop générale. Ajoutez le composant, la permission, le propriétaire et le test de fermeture.

On confond analyse de risque et test d’intrusion. Gardez les activités non intrusives distinctes et obtenez une autorisation avant tout test actif.

FAQ

Faut-il auditer le modèle lui-même ?

Évaluez au minimum l’usage qui en est fait : données envoyées, réglages, outils, sorties et validations. Le fournisseur ou le modèle peut relever d’un périmètre séparé selon votre mandat.

Combien de temps dure un audit ?

Cela dépend du périmètre, des preuves disponibles et des environnements. Commencez par les flux et permissions les plus sensibles plutôt que de promettre une durée universelle.

Peut-on auditer la production ?

Oui avec une autorisation, des règles d’engagement et des contrôles adaptés. Cette méthode ne donne pas l’autorisation de réaliser des tests actifs sur la production.

Une dépendance sans CVE est-elle sûre ?

Non. Une CVE est un signal, pas une preuve d’absence de risque. Examinez l’origine, la maintenance, les permissions et l’usage effectif du composant.

Quand considérer un écart corrigé ?

Lorsqu’une preuve montre le changement, que le comportement normal fonctionne et que la condition de risque est vérifiée comme réduite ou supprimée.

Conclusion

Un audit de sécurité IA utile relie chaque flux de données, permission et dépendance à une preuve et à une correction vérifiable. Cadrez avant d’observer, limitez les données du rapport, priorisez les effets concrets et testez la fermeture. Cette discipline est plus durable qu’une liste de vulnérabilités sans propriétaire.

Sources et limites

Sources primaires : OWASP LLM Top 10, OWASP Agentic AI Threats and Mitigations et NIST AI RMF. Cette revue non intrusive ne remplace pas une autorisation de test de pénétration, une analyse juridique ou une certification.