Alors, j’ai demandé à mon agent à la place…

Evo sait déjà quels actifs d’IA vos équipes ont intégrés à vos dépôts, quels serveurs MCP et quelles compétences sont présents sur les machines de vos développeurs, lesquels présentent un risque et quelles politiques ils enfreignent. Pour accéder à ces informations, il fallait jusqu’ici surmonter des frictions : quitter l’outil dans lequel vous travaillez, filtrer une interface, exporter un fichier CSV et recréer le graphique conçu au trimestre dernier, chaque fois que nécessaire.

Aujourd’hui, nous annonçons le serveur MCP Evo, qui met chacune de ces réponses à portée d’une question, directement dans l’agent que vous utilisez déjà. J’ai donc posé la question à mon agent.

Play Video: So I asked my agent instead… - video 1

À quoi le serveur MCP Evo se connecte-t-il ?

Le serveur MCP Evo vous permet de découvrir les actifs d’IA présents dans vos dépôts et sur les machines de vos développeurs, les données de risque associées, ainsi que vos politiques et les violations ouvertes. Pour commencer, suivez les instructions de notre documentation.

Se connecter depuis Cursor :

1{
2  "mcpServers": {
3    "Evo MCP": {
4      "url": "https://evo.snyk.io/mcp"
5    }
6  }
7}

Se connecter depuis Claude Code :

1claude mcp add --scope user --transport http evo https://evo.snyk.io/mcp/

C’est l’installation. Il s’agit d’un serveur distant : rien n’est installé sur votre machine et il n’a aucun accès à votre système de fichiers.

Le serveur MCP prend en charge les éléments suivants :

• Inventaire. Les actifs d’IA découverts dans votre environnement, avec leur niveau de risque évalué.

• Politiques et problèmes. Les règles qui encadrent l’utilisation de l’IA et les problèmes signalés lorsque des actifs les enfreignent.

• Informations. L’évolution de votre posture de sécurité liée à l’IA au fil du temps.

Créer un rapport sur les actifs d’IA avec le serveur MCP Evo

Pour utiliser Evo MCP, j’ai commencé par définir le périmètre. J’ai demandé : « Combien d’actifs d’IA avons-nous, ventilés par type et par source ? » J’ai reçu en retour l’ensemble de notre parc : des modèles, des agents, des serveurs MCP, des compétences, des dépôts et des machines de développeurs.

La source est particulièrement intéressante. Evo distingue ce qui est référencé dans un dépôt de ce qui est configuré sur une machine de développeur, et indique sur quelle machine. La question n’est donc pas seulement de savoir quels serveurs MCP et quelles compétences existent dans votre organisation, mais aussi sur l’ordinateur portable de qui chacun d’eux se trouve. Cette vue par machine est difficile à obtenir à partir d’un export de tableau de bord, et c’est elle qui transforme un serveur risqué d’une simple entrée de liste en une machine identifiée appartenant à quelqu’un.

J’ai ensuite affiné la demande : « Je veux que les modèles soient regroupés par fournisseur et par pays d’origine, ventilés par type de licence et selon qu’ils peuvent être hébergés en propre, et que les violations ouvertes soient regroupées par politique et par niveau de gravité ».

Enfin est arrivée la partie à laquelle j’aurais normalement consacré tout un après-midi : « Crée-moi un tableau de bord à partir de ces données, avec un graphique pour chaque section. » Il a été assemblé à partir des quatre résultats déjà présents dans la session, sans effectuer de nouvelle requête. Je peux donc le régénérer chaque fois que je le demande.

Rédiger une politique Evo basée sur votre inventaire réel

Vous pouvez utiliser le serveur MCP pour créer une politique à partir de votre inventaire, en commençant par une question que je pouvais vérifier : Combien de compétences de notre parc obtiennent un score de 500 ou plus pour la gestion non sécurisée des identifiants ?

J’ai ensuite demandé à voir ces compétences classées par score. À partir de là, j’ai demandé à Evo de créer une politique pour identifier dans mon parc les compétences qui obtiennent un score de 500 ou plus pour la gestion non sécurisée des identifiants avec des notes de correction appropriées. Les mêmes violations que celles interrogées précédemment sont apparues. La prédiction et le résultat correspondaient, ce qui est précisément l’intérêt d’interroger le parc avant de rédiger la règle.

Transformer les violations Evo en tickets, un par équipe

J’ai récupéré les violations ouvertes pour une politique, chacune indiquant l’actif concerné, l’emplacement de cet actif et les notes de correction de la politique. J’ai ensuite demandé à les regrouper par dépôt, car un ticket par violation est la meilleure façon de voir le travail de sécurité ignoré, tandis qu’un ticket par équipe responsable permet de le faire avancer. Une fois regroupées, j’ai demandé la création des tickets, avec la liste des actifs et les notes de correction déjà incluses dans chaque description.

Cette dernière étape s’est déroulée via un serveur MCP de gestion des tickets déjà configuré dans mon client, aux côtés du serveur MCP Evo. Snyk ne fournit ni ne prend en charge ces serveurs, et ce que le flux peut faire dépend des autorisations que vous avez accordées à votre serveur MCP de gestion des tickets, comme Jira ou ServiceNow. Les problèmes détectés par Evo sont désormais devenus des actions dans vos systèmes, sans qu’il soit nécessaire de créer une intégration pour les traiter.

Comment le serveur MCP Evo est sécurisé

Tout ce qui précède repose sur le fait qu’un agent est autorisé à interroger et à modifier vos données de sécurité, ce qui correspond exactement au type d’accès qu’Evo est conçu pour examiner. Le mode de défaillance que j’attendais d’un modèle de langage placé devant un inventaire était l’obtention d’un chiffre erroné, énoncé avec assurance. Trois contraintes l’en empêchent.

1. Il s’exécute en votre nom

Via OAuth, avec votre identité et vos autorisations. Ce que vous pouvez faire via le serveur correspond exactement à ce que vous pouvez faire dans l’interface Evo. Parmi les huit outils, six permettent de lire et deux d’écrire ; si votre rôle ne vous autorise pas à modifier les politiques, les deux outils d’écriture ne vous sont pas proposés.

2. Une écriture nécessite une véritable approbation.

Lorsqu’un agent tente de créer ou de mettre à jour une politique, Evo prévisualise la modification et envoie une demande d’approbation à votre client.

3. L’agent ne peut pas deviner votre schéma

Chaque outil de requête fonctionne à partir d’un schéma de requête, qui renvoie les champs exacts auxquels vous avez accès ainsi que leur signification. Les champs que vous n’êtes pas autorisé à interroger ne sont pas renvoyés et ne figurent pas dans le schéma d’entrée de l’outil.

Posez-lui une question

Vous vous demandez à quoi ressemble votre propre parc depuis le client que vous utilisez déjà ? Configurez le vôtre sur https://evo.snyk.io/mcp et posez-lui une question.