Snyk révèle que sur 10 000 environnements de développeurs, 4 524 serveurs de protocole de contexte (MCP) étaient en activité. Pire, un développeur sur douze possédait un tel serveur avec un niveau de risque élevé ou critique. Ces installations, souvent ajoutées en quelques secondes par un développeur cherchant à faire fonctionner son agent, se font sans validation préalable, créant un vrai casse-tête pour les équipes de sécurité.

L’entreprise a généralisé la gouvernance MCP dans Evo Agentic Development Security (ADS). Au lieu de devoir examiner chaque serveur manuellement ou d’appliquer un blocage trop large qui ralentit les développeurs, Evo ADS fournit désormais un score de risque pour chaque serveur. Cela permet de gouverner en fonction du danger perçu, que le serveur soit utilisé ou non dans une liste blanche.

La première étape consiste à faire l’inventaire de ce qui tourne. Les serveurs MCP ne passent pas par les revues habituelles des systèmes d’intégration continue (CI) ou des dépendances. Un simple changement dans un fichier de configuration permet à un agent d’acquérir de nouveaux outils. Pour cela, Evo ADS propose deux vues : celle des serveurs connectés aux machines des développeurs, y compris les installations locales ponctuelles qui n’ont jamais touché un dépôt, et celle des serveurs référencés dans les codes sources via l’intégration SCM de Snyk. Ces deux informations se retrouvent dans l’interface Evo UI, sous Inventaire → serveurs MCP.

Il faut ensuite définir ce qui est acceptable. Au lieu d’une longue discussion sur Slack pour savoir si le serveur numéro 47 est acceptable, Evo ADS présente les preuves à côté de chaque élément. Le système fournit des détails précis : origine du serveur, transport utilisé (SSE ou STDIO), s’il est local, et surtout, un score de risque unifié sur 1 000. Les scores varient de 0 (faible) à 1 000 (critique).

En examinant un serveur, l’outil ne se contente pas de donner un chiffre. Il plonge dans le profil de risque. Dans un cas analysé par Snyk, Evo a trouvé des descriptions d’outils contenant « ignorer les instructions précédentes » dans huit cas sur douze. C’est une forme d’injection de prompt qu’un examen manuel aurait manqué. Ce score combine trois signaux : le comportement du serveur (instructions et descriptions d’outils), sa confiance (réputation des URL et identité des mainteneurs), et pour les serveurs locaux avec code source, leur maintenance.

Le concept de liste blanche conserve son importance, mais il est aujourd’hui affiné par l’évaluation des risques. Une approbation antérieure ne constitue plus une garantie de sécurité. Si un serveur déjà approuvé affiche un score de 931, une réévaluation s’impose. Son statut peut être basculé de « autorisé » à « non autorisé » directement depuis cette page. Il est essentiel de comprendre que la liste blanche enregistre une décision, elle n’opère aucun blocage par elle-même ; ce sont les politiques qui exécutent ces décisions.

D’autres acteurs abordent ce même problème de suivi. Sysdig AI Defense, par exemple, vise à tracer toutes les actions des agents, qu’ils soient sur un poste de travail ou dans le cloud, en gardant un historique hors de portée de l’agent lui-même. AWS propose également des solutions pour offrir un accès sécurisé aux data lakes d’entreprise via des serveurs MCP, sans nécessiter de code d’intégration spécifique pour chaque jeu de données.

Sources

• Say Yes To MCP, Safely A Guide For Governing AI Coding Agents With Evo ADS, Snyk, 9 novembre 2026
• Serverless MCP server for AI agent data lake access on Amazon ECS Fargate, AWS, 6 novembre 2026
• Introducing Sysdig AI Defense: See, stop, and prove what agents do, Sysdig, 4 novembre 2026

Crédits photo

• Image en une : EXA Infrastructure, Data center, Weismüllerstraße, 60314 Frankfurt, Germany 02, par KaiKemmann, CC BY-SA 4.0, via Wikimedia Commons (recadrée)
• Image dans l’article : Server room backup power generator – IMG 0451, par Jemimus, CC BY 2.0, via Wikimedia Commons (recadrée)