Dites oui au MCP, en toute sécurité : guide pour gouverner les agents de codage IA avec Evo ADS

Lorsque nous avons annoncé la disponibilité générale de la gouvernance MCP dans Evo Agentic Development Security (ADS), la question pratique qui revenait le plus souvent était : « Très bien. Par où commencer lundi matin ? »

C’est une question légitime : sur 10 000 environnements de développement, Snyk a recensé 4 524 serveurs MCP uniques en cours d’utilisation, et 1 développeur sur 12 ayant installé un serveur MCP présentait une vulnérabilité confirmée de gravité élevée ou critique. La plupart de ces serveurs avaient été ajoutés en quelques secondes par un développeur qui voulait simplement que son agent fasse quelque chose d’utile, sans aucune vérification préalable.

Voici notre réponse : quatre étapes vous permettent de passer d’un premier inventaire à des règles qui ne bloquent que les serveurs à risque. Evo ADS attribue désormais un score de risque aux serveurs MCP, pour vous permettre de les gouverner selon leur risque, avec ou sans liste d’autorisation, au lieu d’examiner chaque serveur manuellement ou de tout bloquer au risque de ralentir les développeurs. Tout fonctionne sur le terminal où les agents sont déjà utilisés, grâce à des hooks légers et sans proxy intermédiaire. Découvrez ce qui est en place, définissez ce qui est acceptable, observez ce que vos règles détectent et appliquez-les en toute confiance.

Étape 1 : découvrez ce qui est déjà en cours d’exécution

Les serveurs MCP ne passent ni par l’intégration continue ni par les vérifications des dépendances. Un développeur modifie un fichier de configuration et son agent dispose de nouveaux outils. La première étape consiste donc à découvrir ce qui est déjà en place. Impossible de gouverner ce que l’on ne voit pas : Evo ADS vous offre donc deux vues :

• Serveurs MCP sur les machines des développeurs : déployez le programme d’installation Evo ADS sur l’ensemble de votre parc. Il révèle les serveurs MCP auxquels les agents se connectent réellement, y compris les installations locales ponctuelles qui n’ont jamais touché un dépôt.

• Serveurs MCP dans les dépôts de code : Evo AI-SPM, configuré via l’intégration SCM de Snyk, repère les serveurs MCP référencés dans votre code.

Ensemble, ces vues répondent à deux questions différentes : qu’est-ce qui est configuré dans le code, et qu’est-ce qui s’exécute sur les ordinateurs portables ? Les deux sont accessibles dans l’interface Evo, sous Inventaire → Serveurs MCP.

Vous pouvez également utiliser Evo MCP Server pour accéder à ces données dans votre propre workflow agentique. Vous disposez ainsi d’une vue d’ensemble de votre parc MCP, sans blocage ni perturbation pour les développeurs. Cette première étape vous permet de répondre à une question à laquelle la plupart des équipes de sécurité ne savent pas répondre : à quoi nos agents sont-ils connectés ?

Étape 2 : définissez ce qui est « acceptable »

Décider si le serveur numéro 47 est acceptable ne devrait pas nécessiter un fil de discussion Slack et une recherche sur le Web. Evo ADS met les éléments nécessaires à côté de chaque serveur, pour vous permettre de l’approuver ou de le rejeter plus rapidement et en toute confiance.

Consultez l’inventaire

Un serveur non officiel à haut risque, installé à grande échelle, pose un tout autre problème qu’un serveur à haut risque présent sur une seule machine. Chaque ligne répond aux questions que vous devriez autrement chercher à résoudre manuellement : qui a développé ce serveur, où il est installé, s’il a été approuvé et quel est son niveau de risque :

• Serveur : nom, origine (par exemple, NPM), transport (SSE ou STDIO) et caractère local.

• Origine du fournisseur : indique si le serveur est officiel. Une origine inconnue est également un signal.

• Source : nombre d’occurrences dans le code, sur les machines et à l’exécution.

• Statut de la liste d’autorisation : autorisé ou non.

• Score de risque : un score unifié par serveur, avec des options de tri et de filtrage.

• Problèmes par niveau de gravité : nombres de problèmes critiques, élevés, moyens et faibles.

Triez par score de risque, puis parcourez les résultats.

Ouvrez le profil de risque

Cliquez sur un serveur pour afficher les détails. L’en-tête indique les méthodes d’authentification, et trois cartes montrent où il se trouve : déclaré dans le code, nombre de machines sur lesquelles il est installé et date de la dernière analyse, et fréquence à laquelle les agents l’ont appelé au cours des sept derniers jours.

Ouvrez ensuite l’onglet Profil de risque. C’est là que vous trouverez les réponses qui vous évitent le fil de discussion Slack et la recherche sur le Web.

Sur l’un des serveurs que nous avons examinés, Evo a détecté dans 8 descriptions d’outils sur 12 la formule « ignore les instructions précédentes ». Il s’agit d’une injection de prompt que vous ne pourriez repérer qu’en lisant vous-même la description de chaque outil.

Les scores vont de 0 à 1 000 :

• Faible (0 à 249)

• Moyen (250 à 499)

• Élevé (500 à 749)

• Critique (750 à 1 000)

L’onglet décompose le score en attributs, comme l’injection de prompt dans la description d’un outil, les capacités destructrices et le contenu non fiable, chacun noté sur 1 000. Développez un attribut pour consulter sa description et une explication « Pourquoi ce risque ? » accompagnée d’éléments de preuve.

Ce serveur figurait déjà sur la liste d’autorisation. Quelqu’un l’avait approuvé, mais son score était toujours de 931, soit un niveau critique. Une liste d’autorisation consigne une décision prise à un moment donné ; le score de risque vous indique quand cette décision mérite d’être réexaminée. Vous pouvez le faire passer à « Non autorisé » depuis cette page, ou le bloquer à l’exécution.

Comment les serveurs sont notés

Le score de risque MCP combine trois signaux : le comportement du serveur (les instructions et descriptions d’outils qu’il envoie aux agents), la confiance (la réputation de ses URL et l’identité de ses responsables) et, pour les serveurs locaux dont le code source est disponible, l’implémentation, la maintenance et les dépendances. Une limite : Evo ne peut pas identifier avec certitude les serveurs sans signature. Ils représentent moins de 20 % des serveurs et ne reçoivent pas de score. Prévoyez de les prendre en compte dans votre processus de vérification.

Définissez votre base de référence

La liste d’autorisation consigne les serveurs MCP que vous avez approuvés. Chaque serveur possède un bouton qui indique s’il est approuvé ou non. Activez-le ou désactivez-le : la décision apparaît dans la colonne « Statut de la liste d’autorisation » de l’inventaire (« Autorisé » ou « Non autorisé »), afin que tous ceux qui consultent l’inventaire voient le même état. Consultez la liste d’autorisation dans la vue détaillée d’un serveur pour afficher la liste complète.

Commencez par ce en quoi vous avez déjà confiance ; inutile de tout créer de zéro. Alimentez la liste à partir d’un inventaire existant, d’une liste sélectionnée ou des serveurs déjà détectés par Evo ADS. Activez ou désactivez les serveurs manuellement dans l’inventaire, ou demandez simplement à Evo dans le chat.

Pour chaque serveur candidat, vérifiez les éléments recueillis précédemment : la tranche de score, le caractère officiel ou non du fournisseur, la méthode d’authentification et, pour tout serveur à risque élevé ou critique, les éléments de preuve associés à « Pourquoi ce risque ? ». Un serveur officiel, authentifié et à faible score est facile à approuver. Pour un serveur critique, demandez-vous pourquoi avant de l’approuver ; le rejeter est une réponse tout à fait valable.

N’oubliez pas que la liste d’autorisation consigne les décisions. À elle seule, elle ne bloque rien. Ce sont les règles qui appliquent ces décisions : c’est l’objet des étapes suivantes.

Étape 3 : observez avant de bloquer

Activer le blocage dès le premier jour perturbe des workflows de développement que vous n’avez pas encore observés. Le mode surveillance vous montre exactement ce que vos règles bloqueraient, avant qu’elles ne bloquent quoi que ce soit. Créez votre première règle à partir du modèle Surveiller les serveurs MCP non autorisés sur la page des règles (Règles → Problèmes → Créer une règle). Elle signale chaque serveur à risque pour examen, sans rien bloquer. Les développeurs et les agents peuvent ainsi continuer à travailler, tandis que vous obtenez une liste actualisée de tout ce que vos règles détecteraient.

Examinez ensuite cette liste sous Inventaire → Serveurs MCP, en vous appuyant sur les informations des lignes et le profil de risque découverts à l’étape 2. Pour chaque serveur signalé, vérifiez son score, son caractère officiel ou non, sa méthode d’authentification et les attributs qui déterminent son score. Décidez ensuite de l’ajouter à la liste d’autorisation ou de le rejeter. Faites cela pendant une ou deux semaines et recherchez les tendances. Un serveur qui apparaît une seule fois est une curiosité ; un serveur présent sur cinquante machines nécessite une décision mûrement réfléchie.

À la fin de la deuxième semaine, vous disposez d’une règle qui reflète votre tolérance au risque et a été testée sur votre parc réel, après que vos équipes de sécurité et vos développeurs l’ont vue en action, avant qu’elle ne les bloque.

Étape 4 : appliquez les règles, en commençant par les éléments à risque

Lorsque vous êtes satisfait de ce que les règles détectent, activez leur application. Le modèle de règle Bloquer les serveurs MCP non autorisés (Règles → Règles → Créer une règle) empêche les agents de codage d’appeler, à l’exécution sur le terminal, les serveurs qui ne figurent pas sur votre liste d’autorisation et présentent un risque élevé ou critique. Si le modèle ne correspond pas à votre tolérance au risque, choisissez Partir de zéro et créez une règle personnalisée selon vos propres critères.

La règle bloque un serveur uniquement s’il ne figure pas sur votre liste d’autorisation et que son niveau de risque est élevé ou critique. Tous les autres restent en mode journalisation : un serveur à faible risque que personne n’a encore approuvé n’interrompra donc pas le travail d’un développeur, et vous conserverez une piste d’audit. De plus, l’application des règles se fait localement, à l’exécution sur la machine du développeur, par l’intermédiaire de hooks légers qui fonctionnent aux côtés de l’agent, et non d’un proxy ou d’une passerelle placés sur son chemin. Vous définissez la règle une seule fois, de manière centralisée. Les hooks l’appliquent sur chaque machine au moment où l’agent appelle le serveur, qu’il s’agisse de Claude Code, Cursor, Codex ou GitHub Copilot.

Dites oui au MCP, en gardant le contrôle

En pratique, vous déployez le programme d’installation et connectez votre SCM le lundi ; le vendredi, vous disposez d’un inventaire et d’une liste d’autorisation préremplie. Avec Evo ADS, vous pouvez adopter MCP tout en sachant à quoi vos agents se connectent, en prenant rapidement des décisions et en bloquant ce qui présente un risque. Il s’agit du premier cas d’usage de Gouverner le comportement des agents, et ce n’est qu’un début : au cours de l’année, le même modèle de découverte, de classification et d’application des règles s’étendra aux compétences des agents, à l’accès aux données sensibles, à la protection contre les injections de prompt et à l’exposition des secrets.

Vous souhaitez savoir à quoi vos agents sont connectés ? Planifiez une démo ou découvrez Evo Agentic Development Security.