~5 minutes
Le Shadow IT version IA. Des développeurs déploient des serveurs MCP en dehors de tout contrôle de sécurité, avec des configs permissives, des credentials hardcodées et zero monitoring. Et ça se propage vite dans les organisations.
Partie de la série OWASP MCP Top 10
Description du risque
On constate que les Shadow MCP Servers prolifèrent dans les organisations à une vitesse alarmante , c’est le Shadow IT sous stéroïdes.
Les Shadow MCP Servers sont des déploiements non approuvés de serveurs MCP qui opèrent en dehors de la gouvernance sécurité. Ils utilisent typiquement des credentials par défaut, des configurations permissives ou des APIs non sécurisées.
C’est le Shadow IT classique, version IA. L’impact est amplifié car un serveur MCP expose des outils avec accès aux systèmes internes, aux données, et à l’infrastructure.
Le pattern est toujours le même : un développeur déploie un serveur MCP “en attendant”, et ce “en attendant” devient permanent. Personne dans l’équipe sécurité ne sait qu’il existe.
Developer A : "J'ai besoin d'un agent pour automatiser mes tâches."
Réalité du déploiement "rapide" :
├── Auth : désactivée ("pour aller vite")
├── Port : 8080 ouvert sur tout le réseau interne
├── Credentials : hardcodées dans le code
├── Monitoring : aucun
├── Mise à jour : jamais
└── Sécurité : "on verra plus tard"
Vecteurs d’attaque
On distingue quatre vecteurs principaux d’exploitation des serveurs MCP non déclarés :
1. Découverte réseau
Un attaquant scanne les ports courants pour identifier des serveurs MCP non référencés :
nmap -p 8080,8443,3000,5000,8000 10.0.0.0/16 --open
curl http://target:8080/mcp/tools/list
2. Credentials hardcodées
Le code source du serveur shadow contient des credentials en clair. Lien direct avec MCP01.
3. Pivot via agent compromis
Un agent légitime se connecte au serveur shadow non audité et exécute des actions hors du périmètre de surveillance.
4. Propagation interne
Un développeur partage son serveur MCP “pratique” via Slack. Le serveur se propage horizontalement sans revue sécurité.
Analyse STRIDE
| Catégorie STRIDE | Applicable | Explication |
|---|---|---|
| Spoofing (Usurpation d’identité) | Oui | Un serveur shadow peut se faire passer pour un endpoint MCP légitime. |
| Tampering (Falsification) | Oui | Les données transitant par le serveur shadow peuvent être modifiées sans détection. |
| Repudiation (Répudiation) | Oui (PRIMAIRE) | Les serveurs shadow opèrent en dehors du périmètre d’audit. Aucun log, aucune traçabilité. Lien avec MCP08. |
| Information Disclosure (Divulgation d’informations) | Oui (PRIMAIRE) | Credentials hardcodées, accès bases de données, systèmes de fichiers sans restriction. |
| Denial of Service (Déni de service) | Modéré | Serveur non dimensionné, absence de rate limiting, outils exploitables pour surcharger les backends. |
| Elevation of Privilege (Élévation de privilèges) | Oui | Déployé avec les permissions du développeur ; souvent des comptes sur-privilégiés. |
Impact potentiel
| Impact | Niveau | Description de l'impact |
|---|---|---|
| Confidentialité | Critique | Accès non contrôlé aux bases de données de production, systèmes de fichiers internes, credentials. L'absence de classification rend impossible l'évaluation du périmètre de fuite. |
| Intégrité | Critique | Les outils exposés (SQL, shell) permettent la modification directe des données de production. Sans audit, ces modifications sont indétectables. |
| Disponibilité | Modéré | Vecteur de DoS involontaire (requête SQL mal formée) ou intentionnel. L'absence de monitoring empêche la détection rapide. |
| Réputation | Sévère | RGPD art. 32 : l'absence de contrôle sur les systèmes traitant des données personnelles est une circonstance aggravante. L'organisation ne peut même pas prouver qu'elle savait que ce serveur existait. |
Recommandations de mitigation
Inventaire centralisé
Maintenir un inventaire centralisé de tous les serveurs MCP autorisés, avec leur périmètre, propriétaire et date de déploiement. Scanner régulièrement le réseau pour détecter toute nouvelle écoute sur les ports typiques des serveurs MCP (3000, 8080, 443, etc.) et bloquer toute communication vers un serveur non référencé.
Processus d’enregistrement obligatoire
Avant tout déploiement, soumettre le serveur MCP à une revue sécurité : authentification, surface d’exposition, secrets utilisés, droits accordés. Intégrer ce processus dans la pipeline CI/CD via une gate obligatoire. Archiver le résultat de la revue dans le registre d’inventaire, avec le niveau de risque résiduel accepté et le responsable signataire.
Template sécurisé par défaut
Fournir aux équipes un template de déploiement MCP pré-configuré avec auth OAuth2/mTLS, TLS 1.3, rate limiting et monitoring inclus dès le départ. Rendre le chemin sécurisé plus simple que le chemin artisanal. Ce template doit être versionné, maintenu par la sécurité et validé à chaque mise à jour des dépendances.
Détection automatique des serveurs fantômes
Configurer l’EDR/NDR pour alerter en temps réel sur toute nouvelle écoute réseau sur les ports associés aux frameworks MCP courants. Corréler les alertes avec le registre d’inventaire : si le processus n’est pas référencé, c’est une anomalie à traiter immédiatement. Sur Kubernetes, utiliser des NetworkPolicy strictes pour bloquer par défaut toute communication non déclarée vers ou depuis un pod MCP.
Formation des développeurs
Informer les équipes aux risques concrets du Shadow MCP : pas de discours théorique, mais des cas réels — credentials leakées, pivot réseau, accès DB non loggés. La formation doit couvrir les bonnes pratiques de déploiement (secrets management, least privilege, logging) et le processus d’enregistrement interne. L’objectif est que chaque développeur comprenne que déployer un serveur MCP “pour tester” sans passer par le registre, c’est ouvrir une porte dérobée dans le SI.
Politique “MCP sécurisé par défaut”
Mettez en place une politique “MCP sécurisé par défaut” : le chemin sécurisé doit être le chemin de moindre résistance. Si le template est prêt à l’emploi, les développeurs n’ont aucune raison de partir de zéro. Toute déviation — serveur sans auth, secrets en clair, pas de logs — doit déclencher un incident de sécurité traité comme tel, pas comme une dette technique. Le principe : si c’est compliqué de faire sécurisé, les gens feront l’artisanal. Mon job, c’est de rendre la sécurité plus simple que l’insécurité.
Quelques références pour aller plus loin
À retenir
