~4 minutes
Beaucoup de serveurs MCP sont déployés avec l’authentification désactivée “pour tester” et finissent en prod comme ça. Dans un système multi-agents, c’est une porte d’entrée béante pour n’importe qui sur le réseau.
Partie de la série OWASP MCP Top 10
Description du risque
L’insuffisance d’authentification et d’autorisation dans les serveurs MCP expose des chemins d’attaque critiques. Quand un serveur MCP ne vérifie pas qui l’appelle, n’importe quel agent — ou n’importe quel attaquant — peut invoquer ses outils.
Le problème est exacerbé par la manière dont MCP est souvent déployé : en local sans auth, puis poussé en production sans sécuriser. Dans un réseau d’entreprise, “sans auth” + “port ouvert” = compromission garantie.
Prenons le schéma suivant : un serveur MCP en localhost:8080 sans authentification, conteneurisé et déployé sur Kubernetes. Le port est accessible depuis tout le cluster. Zéro JWT, zéro mTLS. Tous les outils MCP ouverts au premier pod compromis.
“Sans auth” + “port ouvert” = compromission garantie. C’est la règle la plus simple et la plus violée de la sécurité MCP.
Vecteurs d’attaque
On distingue cinq vecteurs principaux d’exploitation des faiblesses d’authentification MCP :
1. Accès direct sans authentification
Le serveur MCP expose ses endpoints sans aucun mécanisme d’auth. Un attaquant sur le réseau appelle directement les routes.
2. Spoofing d’identité inter-agents
Un agent compromis forge des requêtes en se faisant passer pour un agent légitime. Sans JWT signé, un simple agent_id dans le JSON suffit.
3. Absence de RBAC
Même avec une auth basique, l’absence de contrôle d’accès granulaire permet à tout agent authentifié d’accéder à tous les outils.
4. Token replay
Les tokens statiques sans expiration permettent le replay indéfiniment après interception.
5. Mouvement latéral via chaîne d’agents
Un agent compromis utilise ses accès au serveur MCP pour pivoter vers d’autres systèmes connectés.
Analyse STRIDE
| Catégorie STRIDE | Applicable | Explication |
|---|---|---|
| Spoofing (Usurpation d’identité) | Oui (PRIMAIRE) | Sans auth, n’importe qui peut se faire passer pour un agent légitime. Un agent_id déclaratif ne prouve rien. |
| Tampering (Falsification) | Oui | Accès non autorisé permet de modifier des données via les outils MCP exposés. |
| Repudiation (Répudiation) | Oui | Sans auth, les actions sont anonymes. Impossible de déterminer quel agent a fait quoi. |
| Information Disclosure (Divulgation d’informations) | Oui | Accès non autorisé expose toutes les données des outils MCP : bases de données, fichiers, APIs. |
| Denial of Service (Déni de service) | Oui | Utilisateurs non autorisés peuvent abuser des outils pour épuiser les ressources. |
| Elevation of Privilege (Élévation de privilèges) | Oui (PRIMAIRE) | Pas d’auth = accès total immédiat. Pas besoin de progression d’attaque. |
Impact potentiel
| Impact | Niveau | Description de l'impact |
|---|---|---|
| Confidentialité | Critique | Tous les outils MCP deviennent accessibles. Si le serveur donne accès à une base de données, c'est un accès lecture complet sans restriction. |
| Intégrité | Critique | Tout outil en écriture est exploitable : modifier des enregistrements, altérer des configurations, envoyer des emails au nom de l'organisation. |
| Disponibilité | Élevé | Abus des outils pour provoquer des dénis de service. Sans auth, impossible de rate-limiter par identité. |
| Réputation | Élevé | Un endpoint MCP ouvert sans auth est embarrassant. Expliquer à un régulateur que le serveur n'était "pas encore sécurisé" n'est pas une défense recevable. |
Recommandations de mitigation
JWT avec signature asymétrique + RBAC
Utiliser des tokens JWT signés avec RS256 pour authentifier les agents. Chaque token doit être émis par une autorité de confiance et inclure des claims spécifiques à l’agent. Implémenter un contrôle d’accès basé sur les rôles (RBAC) pour limiter les permissions de chaque agent aux outils nécessaires.
mTLS pour les environnements sensibles
Pour les déploiements en production, surtout dans des environnements sensibles, ajouter une couche de sécurité avec mTLS. Cela garantit que seuls les agents avec des certificats valides peuvent communiquer avec le serveur MCP, ajoutant une vérification cryptographique forte.
Rotation des clés et tokens éphémères
Mettre en place une politique de rotation des clés d’authentification tous les 90 jours maximum. Utiliser des tokens éphémères avec une durée de vie courte (15 minutes max) pour limiter les risques en cas d’interception.
Authentification obligatoire même en développement
Ne jamais désactiver l’authentification, même en environnement de développement. Le scénario classique est de déployer un serveur “de test” sans auth, puis de le pousser en production sans sécuriser. Intégrer des vérifications dans le pipeline CI/CD pour s’assurer que l’authentification est activée avant tout déploiement.
Logs avec identité vérifiée
Enregistrer tous les appels au serveur MCP avec l’identité de l’agent vérifiée. Cela permet de tracer les actions et d’identifier rapidement les agents compromis en cas d’activité suspecte.
RBAC granulaire par outil
Ne pas se contenter d’une authentification globale. Chaque outil MCP doit avoir des permissions spécifiques. Par exemple, un agent qui a besoin d’accéder à query_database ne devrait pas avoir accès à send_email ou execute_command. Cela limite les dégâts en cas de compromission d’un agent.
Tokens éphémères (15 min max)
Utiliser des tokens éphémères avec une durée de vie courte (15 minutes max) pour limiter les risques en cas d’interception.
Quelques références pour aller plus loin
À retenir
