Evo ADS : la gouvernance des comportements des agents est disponible : maîtrisez l’utilisation de MCP

Aujourd’hui, nous annonçons la disponibilité générale de Govern Agent Behavior, la fonctionnalité d’Evo Agentic Development Security (ADS) qui contrôle ce que les agents de codage IA sont autorisés à faire à l’exécution, avec le lancement de MCP Governance.

Depuis le lancement d’Evo ADS en juin, nous avançons autour d’une idée simple : le développement agentique introduit des risques sur trois fronts, et chacun exige une forme de contrôle qui lui est propre :

1. Ce que les agents utilisent : les serveurs MCP, les compétences et les outils qu’ils intègrent, qui doivent être détectés et évalués.

2. Ce que les agents génèrent, qui doit être validé au moment de sa création.

3. Et ce que les agents font : les actions qu’ils entreprennent une fois leur décision prise, qui doivent être contrôlées en temps réel.

Govern Agent Behavior est la réponse d’Evo ADS à cette troisième question, et MCP Governance est le premier cas d’usage proposé dans ce cadre.

Concrètement, MCP Governance permet aux équipes de sécurité et de plateforme de détecter tous les serveurs MCP présents dans leur environnement, de définir lesquels sont autorisés, de repérer lorsqu’un agent s’écarte de cette politique et de consigner ou bloquer l’utilisation des MCP au moment de l’exécution, en temps réel, dans Claude Code, Cursor, Codex et GitHub Copilot.

Contrôler les outils qu’un agent autonome peut appeler est fondamental : la plupart des équipes de sécurité pensaient déjà disposer de ce type de contrôle, jusqu’à ce qu’elles cherchent et ne trouvent rien. MCP Governance comble cette lacune nativement, dans le même workflow où la chaîne d’approvisionnement des agents est détectée et le code généré par l’IA validé, plutôt qu’au moyen d’un outil distinct ajouté en parallèle.

Pourquoi le contrôle des MCP est important aujourd’hui

Le Model Context Protocol (MCP) est la norme qui permet aux agents de codage IA de se connecter à des outils, des sources de données et des systèmes externes — notamment des dépôts, des bases de données, une infrastructure cloud et des API internes — par l’intermédiaire d’une interface commune. C’est en grande partie pour cette raison que les agents ressemblent de plus en plus à des collègues et de moins en moins à une fonction de saisie semi-automatique : un agent doté d’un accès MCP ne se contente pas de suggérer une ligne de code. Au cours d’une même session, il peut interroger un système de gestion des tickets, extraire des données d’une base de production ou appeler un service interne.

C’est aussi là que réside le problème. MCP normalise la façon dont les agents se connectent aux outils, mais ne précise pas quels outils doivent être considérés comme fiables, ni ce qu’un agent est autorisé à faire avec ceux auxquels il peut accéder. Chaque serveur MCP auquel un agent se connecte devient, dans les faits, un nouvel élément de votre chaîne d’approvisionnement logicielle. Mais contrairement à une dépendance figée dans un manifeste, il est souvent ajouté de façon dynamique, lorsqu’un développeur l’installe en quelques secondes, sans aucun processus de vérification.

Cette exposition n’est pas hypothétique, ni nouvelle : c’est le même problème des paquets malveillants, qui passe simplement par une autre porte. Un serveur MCP compromis peut lire des fichiers locaux, exfiltrer des identifiants ou accéder à des systèmes internes dès son lancement, avant même que l’équipe de sécurité sache qu’il existe, et encore moins qu’elle ait pu l’examiner. Le risque se concrétise sur la machine du développeur, au moment où le serveur est appelé : c’est donc là qu’il faut le détecter.

L’ampleur du phénomène dépasse ce qu’imaginent la plupart des équipes de sécurité. Les données d’analyse de Snyk, issues de près de 10 000 environnements de développement, ont révélé 4 524 serveurs MCP distincts en cours d’utilisation, les machines les plus instrumentées en exécutant 13 ou plus simultanément. Plus de la moitié des développeurs disposent déjà de connexions MCP actives à des outils et systèmes de production. Et en examinant la posture de sécurité de ces connexions, nous avons constaté qu’à ce jour, 1 développeur sur 12 ayant installé un serveur MCP présentait une vulnérabilité confirmée de gravité élevée ou critique.

Rien de tout cela n’apparaît dans un pipeline AppSec traditionnel, car les serveurs MCP ne sont ni des artefacts analysés en CI ni des dépendances examinées avant la fusion. Ils sont plutôt ajoutés en direct, à l’exécution, souvent en dehors de tout processus surveillé par les équipes de sécurité. Sans moyen de déterminer quels serveurs MCP sont acceptables et de faire respecter cette règle lorsqu’un agent tente d’en utiliser un, « adopter des agents IA » et « élargir votre surface d’attaque non maîtrisée » reviennent à dire la même chose.

Fonctionnement de MCP Governance dans Evo ADS

MCP Governance est la réponse d’Evo ADS à cette lacune et prolonge directement la visibilité qu’Evo ADS offre déjà sur la chaîne d’approvisionnement des agents. La solution remplit trois fonctions :

1. Fournir votre liste à Snyk

Les équipes de sécurité et de plateforme définissent les serveurs MCP approuvés à partir d’un inventaire existant, d’une liste constituée manuellement ou des serveurs déjà détectés par Evo ADS. Cette liste devient la politique de référence à laquelle est comparé chaque agent de l’environnement. Vous pouvez la créer manuellement ou simplement demander à Evo de le faire dans le chat !

2. Repérer les utilisations non conformes à la politique

Une fois la politique définie, Evo ADS surveille en continu l’activité MCP sur les machines des développeurs et signale chaque fois qu’un agent tente d’accéder à un serveur absent de la liste approuvée, qu’il s’agisse d’une installation locale ponctuelle ou d’un phénomène observé dans tout l’environnement. Il n’est pas nécessaire de bloquer quoi que ce soit pour que cette visibilité soit utile : pour de nombreuses équipes, savoir simplement à quoi les agents se connectent réellement constitue leur premier véritable inventaire.

3. Contrôler l’utilisation à l’exécution

C’est là que la visibilité devient un moyen de contrôle. Evo ADS peut consigner à des fins d’audit toute utilisation non autorisée de MCP, ou la bloquer directement sur le terminal, au moment où un agent tente de se connecter — et non après coup, ni en comptant sur l’agent pour respecter la consigne.

MCP Governance fonctionne partout où vos agents sont déjà utilisés. La solution est disponible dès aujourd’hui dans Claude Code, Cursor, Codex et GitHub Copilot. L’application des règles s’effectue au moyen de hooks légers qui fonctionnent aux côtés de l’agent, sans acheminer son trafic par un proxy ou une passerelle distincte. C’est la même approche qu’Evo ADS utilise pour analyser le code de façon sécurisée dès sa création. Les équipes n’ont donc pas besoin de modifier la façon dont les agents se connectent aux outils, de mettre en place une nouvelle infrastructure ni d’accepter un nouveau point de défaillance dans le chemin d’exécution de l’agent. La politique est gérée de façon centralisée ; son application est locale, là où la décision d’utiliser un serveur MCP est réellement prise.

La suite du contrôle du comportement des agents

Nous parlons délibérément d’un premier cas d’usage, et non d’une histoire achevée. MCP Governance répond à la question : « Cet agent est-il autorisé à accéder à cet outil ? » C’est une question indispensable, mais pas la seule. Même s’il opère entièrement au sein d’un serveur MCP approuvé, un agent peut exécuter une commande shell destructive ou déplacer des données sensibles vers un endroit où elles ne devraient pas se trouver. MCP Governance, à elle seule, ne détectera pas ces actions.

C’est là qu’intervient la prochaine étape d’Evo ADS. Dans les semaines à venir, nous étendrons le contrôle au-delà de la liste d’autorisation MCP afin de couvrir et de bloquer les agents qui effectuent. Nous allons également remplacer la liste statique de la politique MCP par une méthode permettant aux équipes de l’alimenter directement à partir d’un dépôt Git ou d’une page Confluence, à l’aide d’Evo MCP, et évoluer vers un contrôle fondé sur les risques, afin que la politique reflète le niveau de risque réel d’un serveur plutôt qu’une simple décision d’autorisation ou de refus.

D’ici la fin de l’année, nous étendrons également la couverture d’ADS afin de contrôler les accès non autorisés aux données sensibles, de renforcer la protection contre les injections de prompt et de prévenir l’exposition de secrets par les agents. Nous étendrons aussi le modèle détection-classification-contrôle introduit par MCP Governance aux Agent Skills.

Contrôler ce que les agents utilisent est indispensable. Contrôler ce qu’ils font au moment où ils le font, c’est donner une portée réelle à cette gouvernance. MCP Governance en est la première démonstration, disponible dès aujourd’hui.

Vous souhaitez voir MCP Governance en action ? Planifiez une démo ou découvrez Evo Agentic Development Security pour savoir comment Evo ADS sécurise ce que les agents utilisent, font et génèrent tout au long du cycle de développement piloté par l’IA.