53 % des serveurs MCP sont des nids à hackers

MCP s'est imposé en moins de 18 mois comme le standard d'interconnexion de l'IA d'entreprise. Le principe est séduisant : un protocole unique pour brancher vos agents IA sur votre ERP, votre CRM, vos bases documentaires, sans développement sur mesure. La promesse tient. Mais ce que la plupart des guides de déploiement ne disent pas, c'est que MCP a été conçu pour la fonctionnalité, pas pour la sécurité. Et cette différence, elle se paie cash.

Quand l'outil de productivité devient une fenêtre ouverte sur vos données

Le 1er mai 2025, Asana lance son serveur MCP en version bêta. Le pitch : permettre à vos assistants IA (ChatGPT, Copilot) d'interroger vos projets, tâches et documents en langage naturel. Des centaines d'équipes activent l'intégration dans la semaine.

Le 4 juin, un bug est découvert. Un défaut d'isolation logique dans le serveur MCP permettait à des utilisateurs d'accéder aux données d'autres organisations : tâches, commentaires, fichiers, métadonnées de projets. La fuite avait duré un mois sans être détectée. Environ 1 000 clients ont été notifiés. Asana a mis son serveur MCP hors ligne du 5 au 17 juin pour corriger le problème (sources : BleepingComputer, The Register, UpGuard, juin 2025).

Ce qui est instructif ici, ce n'est pas qu'Asana ait subi une cyberattaque. Il n'y en a pas eu. C'est qu'un simple bug de configuration a suffi à rendre visibles les données de clients tiers, pendant trente jours, sur un outil que tout le monde venait de brancher avec confiance. Aucune entreprise ayant activé cette intégration ne disposait d'un moyen de détecter l'anomalie côté client.

Ce scénario n'a rien d'exceptionnel. Il illustre une réalité documentée à grande échelle : une étude de la société Astrix Security publiée début 2026 ayant analysé plus de 5 000 serveurs MCP open source révèle que 53 % d'entre eux utilisent des credentials codés en dur dans les fichiers de configuration, et que 492 serveurs exposés publiquement ne disposent d'aucune authentification ni chiffrement. L'écosystème MCP grossit plus vite que ses standards de sécurité.

Ce que vous devez mettre en place avant d'activer le premier connecteur

MCP n'est pas un outil dangereux par nature. C'est un outil puissant, mal encadré par défaut. Voici les règles non négociables, issues de l'expérience terrain et de la recherche récente.

Traitez MCP comme une porte, pas comme un tuyau

Un serveur MCP expose des capacités à un agent IA : lire des fichiers, interroger une base, déclencher une action dans un système tiers. Cela signifie qu'un agent mal configuré, ou compromis, peut faire tout ce que vous lui avez autorisé.

La règle de base : n'accordez jamais à un serveur MCP plus de droits que ce dont il a strictement besoin. Si votre connecteur ERP n'a besoin que de lire les commandes en cours, il n'a aucune raison d'avoir accès aux fiches RH ou aux données financières. Le principe du moindre privilège, appliqué aux agents IA, n'est pas optionnel. C'est le premier mécanisme que vérifiera votre assureur cyber en cas d'incident.

Cartographiez ce que vous ouvrez, pas seulement ce que vous connectez

La bonne question n'est pas "quel outil MCP est-ce que je branche ?" mais "si cet agent était compromis demain, à quoi aurait-il accès ?". Posez cette question pour chaque connecteur envisagé.

Commencez par un inventaire de vos données sensibles : données RH, données clients, propriété intellectuelle, données de production. Décidez lesquelles ne doivent jamais être accessibles à un agent externe, quoi qu'il arrive. Un DSI qui ne peut pas répondre à cette question en cinq minutes n'est pas prêt pour un déploiement MCP en production. C'est un exercice qui se fait en une demi-journée avec les bonnes personnes dans la pièce : responsable IT, responsable métier, et si possible votre RSSI.

Méfiez-vous du Shadow MCP : il arrive plus vite que le Shadow IT

L'OWASP, qui vient de publier son MCP Top 10, identifie les "Shadow MCP Servers" comme l'une des menaces les plus sous-estimées. Des développeurs ou des équipes data activent un serveur MCP en local ou dans un environnement cloud, sans passer par la DSI, pour accélérer un projet. Le résultat est exactement le même que le Shadow IT, avec une surface d'attaque supplémentaire : l'agent tourne, accède à des données, et personne ne sait qu'il existe.

Une première étape réaliste pour une PME sans budget exceptionnel : un audit des tokens d'API actifs dans votre environnement et une liste des processus en cours sur vos machines de développement. Ce n'est pas de la sophistication, c'est de l'hygiène de base. Et c'est souvent là que les surprises apparaissent.

Logez les actions de vos agents, pas seulement leurs résultats

C'est le conseil le moins spectaculaire, et le plus souvent ignoré. Dans l'incident Asana, la fuite a duré un mois précisément parce qu'aucun mécanisme côté client ne permettait de détecter des accès anormaux. Enregistrez chaque requête de vos agents MCP : quelle donnée a été demandée, par quel agent, à quelle heure, avec quel résultat.

Ce n'est pas de la surveillance excessive. C'est le minimum pour répondre à la question "qu'est-ce qui s'est passé ?" en cas d'incident. C'est aussi ce que NIS2 désigne par traçabilité des accès aux systèmes d'information critiques, un point de contrôle explicite pour les ETI industrielles concernées par la directive.

Pilotez sur un périmètre restreint avant de déployer

Une entreprise n'a pas besoin de connecter douze systèmes à son premier agent MCP. Commencez par un seul connecteur, sur un périmètre de données non critiques, avec des critères de succès précis : taux d'adoption, qualité des réponses, zéro anomalie de sécurité détectée sur 30 jours. Ce pilote vous donnera les preuves pour convaincre votre direction, et surtout l'expérience pour éviter les erreurs coûteuses au passage à l'échelle. Impliquez vos équipes métier dès cette phase : elles connaissent les données utiles et les limites à ne pas franchir. Séparer IT et métier pendant le cadrage, c'est garantir un outil cohérent et inutile.

Comment akawan aborde ce sujet avec ses clients

Déployer MCP dans un environnement industriel ou multi-sites, c'est rarement un problème technique seul. C'est un problème d'architecture, de gouvernance et d'arbitrage : quelles données, avec quels droits, pour quels agents, dans quelles conditions.

C'est en amont de tout connecteur qu'akawan intervient. Nous aidons nos clients à cartographier leurs données sensibles, à définir les périmètres d'accès adaptés à leur SI existant, et à concevoir une architecture d'agent IA qui tient la route en production, pas seulement en pilote. Quand la protection des données est au coeur du projet, Bosl.ai peut s'intégrer dans la chaîne pour garantir que les données sensibles ne transitent jamais en clair vers un LLM externe, y compris dans des flux MCP.

L'outil seul ne suffit pas. Ce qui fait la différence, c'est le travail d'analyse amont : l'inventaire, les arbitrages, la gouvernance. C'est ça, la valeur d'une approche de service outillé.

Ce que vous devriez faire cette semaine

MCP va s'imposer dans votre SI. Ce n'est pas une tendance, c'est déjà une réalité pour vos concurrents et vos éditeurs logiciels. La question n'est pas si vous allez l'adopter, mais dans quelles conditions.

Le cas Asana n'est pas une exception. C'est un avertissement. L'incident n'a pas été causé par une attaque sophistiquée, mais par une intégration activée trop vite, sur un outil en bêta, sans gouvernance préalable.

Prenez trente minutes cette semaine pour répondre à une question simple : si votre agent IA était compromis demain, à quoi aurait-il accès ? Si vous n'avez pas la réponse immédiatement, c'est par là que tout commence.