Notre méthodologie d'audit
Lorsque les équipes cybersécurité de Niji réalisent un audit d'un système d'information intégrant une intelligence artificielle, elles s'appuient sur les bonnes pratiques publiées par l'OWASP, notamment le LLM Top 10, référentiel reconnu au sein de la communauté cybersécurité.
L'audit est structuré en plusieurs axes. D'abord, un contrôle des bonnes pratiques générales de sécurité du système d'information : OWASP Top Ten pour les applications web, recommandations de l'ANSSI pour les audits internes. Puis une analyse spécifique de l'intégration de l'IA, conforme aux recommandations du cahier des charges et, le cas échéant, à la PSSI-IA du CLUSIF. Les auditeurs recherchent les vulnérabilités et les défauts de conception propres à ces systèmes (empoisonnement des données, inversion de modèle, injection de prompts, dérive, fuites d'informations) et formulent des préconisations opérationnelles assorties de recommandations et de bonnes pratiques de développement.
Ce qui suit est une sélection non exhaustive de vulnérabilités découvertes par nos auditeurs lors de missions récentes, à titre d'illustration concrète des risques traités lors de nos audits.
Injection de prompt et exfiltration du contexte système
Sur l'un de nos audits d'assistant conversationnel, un simple prompt a suffi à forcer le modèle à révéler son contexte système :
Le modèle a restitué intégralement les instructions confidentielles de l'éditeur : logique métier, contraintes de comportement, données sensibles. Ce type de vulnérabilité correspond au LLM01 – Prompt Injection du LLM Top 10 OWASP, et illustre bien les risques quand aucun cloisonnement n'existe entre les instructions système et les entrées utilisateur.
Analyse de code source par agents spécialisés & vulnérabilités MCP
Quand nous avons accès au code source, des agents IA viennent épauler les auditeurs pour repérer des vulnérabilités. Cette approche combinée nous a notamment permis d'identifier des failles dans des intégrations Model Context Protocol (MCP), un protocole de plus en plus répandu pour connecter les LLM à des outils et services externes.
Exécution de code à distance (RCE) via un outil MCP
Sur une des plateformes auditées, voici la chaîne d'attaque que nous avons reconstituée :
En soumettant une adresse email avec le bon domaine, même pour un compte inexistant, l'API d'authentification délivrait un jeton valide sans aucune vérification côté SSO.
Une fois connecté, il suffisait d'inciter l'assistant à utiliser un outil MCP de traitement de fichiers, ouvrant sur une vulnérabilité d'exécution de commande côté serveur.
Les protections bloquant certains mots-clés ont été contournées en découpant les chaînes à l'exécution, par exemple "urllib.re" + "quest" pour importer un module sans déclencher les règles de détection.
Le code exécuté depuis le contexte MCP permettait d'atteindre une API interne hébergée sur le réseau privé, sans aucun token d'authentification inter-services pour bloquer les appels.
Avec un simple jeton utilisateur, nos auditeurs ont récupéré des credentials MCP, des listes de groupes Active Directory, des configurations LLM et des system prompts. Avec un jeton à privilèges élevés, le périmètre s'est encore élargi : des dizaines de system prompts contenant des données internes classifiées (RH, finances, juridique, SSI) et la configuration complète de l'ensemble des assistants de la plateforme.
Cinq étapes, zéro exploit complexe. Chacune prise isolément semble mineure : un contournement de vérification, une concaténation de chaînes, une absence de token inter-services. Mises bout à bout, elles ont ouvert un accès à des données classifiées RH, finances, juridique et SSI de l'ensemble de la plateforme.
Lecture de fichiers locaux (LFI) via un serveur MCP
Un serveur MCP exposait une fonction permettant de récupérer le contenu d'une page web à partir d'une URL. Le problème venait du comportement de l'application : en cas d'échec de la requête HTTP, le serveur relançait automatiquement la tentative via un moteur de rendu de pages (de type Playwright). Nos auditeurs ont exploité ce comportement en passant une URL pointant vers le système de fichiers local (file://), ce qui a suffi à lister et lire des fichiers sur la machine hébergeant le MCP, sans aucune authentification supplémentaire.
Ce que nous recommandons
Ces vulnérabilités reposent sur des causes bien connues. Elles combinent des failles classiques de sécurité applicative (contournement d'authentification, absence de cloisonnement réseau) à des angles morts propres aux architectures agentiques : confiance implicite accordée aux outils MCP, absence de validation stricte des schémas d'URL, absence de cloisonnement entre instructions système et entrées utilisateur.
- Cloisonner instructions système et entrées utilisateur. Un prompt utilisateur ne doit jamais pouvoir faire remonter le contenu du system prompt ou des instructions métier.
- Appliquer le principe de moindre privilège aux jetons MCP. Un token utilisateur ne doit pas ouvrir l'accès à des credentials, configurations ou données partagées par l'ensemble de la plateforme.
- Authentifier les appels inter-services. Un pivot depuis le contexte d'un agent vers une API interne doit être bloqué par un jeton de service, pas seulement par la position réseau.
- Valider strictement les schémas et protocoles acceptés en entrée. Un outil qui récupère une URL ne doit accepter que
http(s), jamaisfile://ni un repli silencieux vers un moteur de rendu qui contourne les contrôles.
Notre conviction : auditer une IA n'est pas un audit sur un périmètre à part, c'est auditer un système d'information augmenté de nouveaux points d'entrée. Le socle (authentification, cloisonnement réseau, moindre privilège) reste la première ligne de défense ; les contrôles spécifiques à l'IA (prompt injection, empoisonnement des données, dérive) viennent ensuite. Les deux couches sont nécessaires.
