Un serveur MCP peut exposer des fichiers, une base de données, un outil de déploiement ou un système métier à un agent IA. Une erreur de configuration ne produit donc pas seulement une mauvaise réponse : elle peut déclencher une action non autorisée.
La sécurité doit être pensée autour de trois frontières : qui appelle, quelle ressource peut être atteinte et quelle action peut être exécutée.
MCP n'est pas un mécanisme d'authentification magique
Pour les transports HTTP, la spécification MCP s'appuie sur des pratiques d'autorisation standardisées et sur OAuth 2.1. La documentation officielle déconseille d'écrire soi-même la validation des jetons et recommande des bibliothèques éprouvées.
Pour un transport local stdio, les identifiants doivent être récupérés depuis l'environnement, jamais intégrés dans le fichier de configuration ou transmis dans un prompt.
Sept contrôles indispensables
1. Valider chaque jeton
Vérifiez la signature, l'expiration, l'émetteur, l'audience et les scopes. Un jeton valide pour un autre service ne doit pas être accepté. Le passage aveugle d'un jeton vers un service aval est explicitement à éviter.
2. Utiliser des jetons courts
La durée de vie limite l'impact d'un vol. Associez-la à une révocation et à une rotation documentées.
3. Appliquer le moindre privilège
Séparez lecture, écriture, administration et déploiement. Un outil qui recherche un ticket n'a pas besoin de pouvoir le supprimer. Si l'agent doit lire un répertoire, n'exposez pas tout le système de fichiers.
4. Ne pas confondre session et identité
Les bonnes pratiques MCP indiquent qu'une session ne doit pas servir d'authentification. Les identifiants de session doivent être aléatoires, expirables et associés à l'utilisateur authentifié.
5. Borner les paramètres des outils
Validez les chemins, domaines, tailles, types et valeurs autorisées. Refusez les chemins relatifs ambigus et les commandes arbitraires. Un outil métier étroit est plus sûr qu'un outil execute_shell universel.
6. Prévoir une validation humaine
Les actions destructrices ou externes doivent demander une confirmation explicite : suppression, publication, envoi de message, changement de permission, achat ou déploiement en production.
7. Journaliser sans exposer les secrets
Tracez l'identité, l'outil appelé, la décision d'autorisation, le statut et un identifiant de corrélation. Masquez jetons, mots de passe, contenus personnels et arguments sensibles.
Le risque d'injection indirecte
Un agent peut lire une page, un ticket ou un document contenant une instruction malveillante. OWASP classe l'injection de prompt parmi les risques majeurs des applications LLM. Le contenu récupéré doit être traité comme une donnée non fiable, jamais comme une nouvelle politique système.
Les outils doivent rester soumis aux mêmes autorisations, même si le modèle affirme qu'une action est urgente ou autorisée.
Architecture recommandée
Placez le serveur MCP derrière une couche d'autorisation et séparez les connecteurs sensibles. Chaque requête suit ce parcours : authentification, validation de l'audience, contrôle du scope, validation des paramètres, exécution bornée, filtrage de la réponse et journal d'audit.
Pour les opérations critiques, utilisez un compte de service dédié et des permissions temporaires. Évitez les identifiants personnels d'un administrateur.
Test de sécurité minimal
Votre campagne doit vérifier : jeton expiré, mauvaise audience, scope absent, accès à un chemin interdit, paramètre trop long, injection dans une ressource lue, rejeu de session, appel concurrent et tentative d'exfiltration dans les logs.
Complétez ces tests par la méthode décrite dans IA locale ou cloud : protéger son code et par une revue de code assistée par IA supervisée.
quel controle de securite MCP vous parait le plus difficile a appliquer dans un environnement reel ?
Publié dans la discussion