Qu'est-ce qu'un serveur MCP ?
Un serveur MCP est un service léger qui implémente le Model Context Protocol (MCP) pour exposer un ensemble défini d'outils, de données ou d'actions à un agent IA ou une application LLM. Chaque serveur MCP fait le pont entre l'agent IA (le client MCP) et un système externe — par exemple, un serveur MCP GitHub peut exposer des fonctions de lecture de dépôts et d'ouverture de pull requests, tandis qu'un serveur MCP Slack peut exposer des fonctions d'envoi de messages ou de recherche dans les canaux. Les serveurs MCP peuvent tourner en local sur la machine d'un utilisateur ou être hébergés à distance, et s'authentifient auprès des systèmes qu'ils encapsulent avec leurs propres identifiants — clé API, token OAuth ou compte de service. Les organisations peuvent développer leurs propres serveurs MCP ou en installer des versions communautaires ou éditeurs, souvent avec peu de contrôle centralisé.
Pourquoi c'est important
Chaque serveur MCP est un identifiant permanent avec son propre rayon d'impact. Comme les serveurs MCP sont faciles à installer — souvent en une ligne de configuration — collaborateurs et développeurs les connectent fréquemment à des systèmes de production sans jamais déclarer l'identifiant quelque part où l'équipe sécurité pourrait le voir. Un seul serveur MCP sur-privilégié peut donner à un agent IA un accès en lecture/écriture à un dépôt de code, une base de données client ou un compte cloud, et si cet agent est manipulé via une injection de prompt ou que l'identifiant du serveur fuite, le rayon d'impact s'étend à tout ce que le serveur peut atteindre. Dans la plupart des organisations, les identités machine sont bien plus nombreuses que les collaborateurs — et la plupart n'ont ni propriétaire, ni privilèges ajustés, ni date d'expiration. Contrairement à un compte de service classique provisionné via l'IAM, les identifiants d'un serveur MCP contournent souvent toute revue d'onboarding, ce qui fait des identifiants MCP orphelins ou jamais tournés un angle mort grandissant à mesure que l'adoption de l'IA agentique s'accélère dans les équipes d'ingénierie, IT et métiers.
Comment Cydenti vous aide
Cydenti traite chaque identifiant de serveur MCP comme une identité non humaine à part entière : découverte des serveurs MCP déployés, des identifiants qu'ils détiennent, des permissions associées, et des agents IA qui en dépendent. Plutôt que de laisser la prolifération des serveurs MCP se disperser dans des tableurs ou des fichiers de configuration éparpillés sur les postes des développeurs et les environnements cloud, Cydenti fait remonter les identifiants MCP sur-privilégiés, jamais tournés ou orphelins dans un seul graphe d'identité, aux côtés de vos autres comptes de service et clés API, pour permettre aux équipes sécurité d'appliquer le moindre privilège et de repérer les connexions à risque avant qu'elles ne soient exploitées.
Explorer →Questions fréquentes
Où s'exécutent les serveurs MCP ?
Un serveur MCP peut tourner en local sur la machine d'un développeur, au sein de l'infrastructure de l'entreprise, ou comme service hébergé par un éditeur. Les serveurs locaux utilisent généralement STDIO pour communiquer, tandis que les serveurs distants passent par un transport HTTP. Dans tous les cas, le serveur détient des identifiants vers les systèmes auxquels il se connecte, d'où l'importance de son lieu de déploiement pour la revue de sécurité.
Un serveur MCP peut-il être un risque même si l'agent IA est fiable ?
Oui. Le risque réside souvent dans les identifiants et permissions du serveur, pas dans les intentions de l'agent. Un serveur MCP configuré avec des accès larges et jamais revus — ou exécutant du code obsolète et vulnérable — peut être exploité indépendamment de l'agent IA, exposant tous les systèmes et données auxquels il est connecté.
Découvrez les identités machines que vous ignoriez posséder
— le premier inventaire arrive en général sous une semaine.
L’Audit Flash connecte jusqu’à trois applications SaaS en lecture seule et liste les comptes de service, identifiants orphelins, autorisations OAuth et agents IA qu’il voit. Le premier inventaire des identités arrive en général sous une semaine. Un scan complet des partages, sur un grand tenant, peut prendre plus longtemps. Sans engagement.
Sans engagement · Données hébergées en Europe · Réponse sous 24h