Gouvernance et risque MCP OWASP : ce serveur, on l'autorise ?

Les agents IA sont raccordés à des systèmes réels à toute vitesse, et le connecteur qui fait ce câblage est le Model Context Protocol (MCP). Un serveur MCP peut laisser un agent lire vos wikis, ouvrir des pull requests, publier sur Slack et déclencher des flux de production, souvent sans qu'un humain voie chaque étape. Le projet OWASP MCP Governance & Risk existe pour répondre à la seule question qui compte avant d'en connecter un : ce serveur doit-il être autorisé dans notre environnement, et sous quels contrôles ?

Quatre portes avant tout score

L'idée la plus tranchante du cadre est que certaines choses ne se négocient pas. Avant de pondérer le moindre facteur de risque, quatre portes doivent passer, et l'échec de l'une d'elles bloque à lui seul l'approbation. Vous pouvez dérouler cette même logique de portes avec l'outil de gouvernance des serveurs MCP avant de valider quoi que ce soit.

• Pas de propriétaire, pas d'approbation. Chaque serveur a un responsable nommé et redevable, sinon il ne part pas en service.
• Pas de journalisation, pas de production. Une piste d'audit de chaque action est obligatoire en production.
• Pas de périmètre défini, pas d'accès. Les données qu'il peut lire et les actions qu'il peut mener sont documentées.
• Pas de revue, pas de déploiement en entreprise. L'approbation n'est pas un événement unique : une revue périodique du niveau de risque est planifiée.

Classer : du Niveau 0 au Niveau 4

Tous les serveurs MCP ne présentent pas le même risque, aussi le cadre classe chacun dans l'un des cinq niveaux, et l'exigence monte à mesure que l'on grimpe : le Niveau 0 est la lecture de données publiques ; le Niveau 1, la lecture interne non sensible ; le Niveau 2, la lecture sensible ; le Niveau 3, la capacité d'écriture ; et le Niveau 4, le privilégié ou critique. Un serveur de recherche documentaire de Niveau 0 et un serveur de Niveau 4 capable de déployer en production suivent les mêmes règles, mais avec des seuils très différents. Le niveau est l'endroit où la question « sous quels contrôles ? » trouve sa réponse.

Le risque principal : le chaînage d'outils

De toutes les façons dont un déploiement MCP dérape, le cadre désigne le chaînage d'outils comme le risque principal : un serveur capable d'invoquer d'autres outils ou de déclencher des flux en aval transforme une seule action approuvée en une chaîne que l'utilisateur n'a jamais vue. Autour se rangent les préoccupations habituelles : autorisation et périmètre d'accès, exposition d'identifiants et fuite de données, lacunes dans la piste d'audit, confiance dans la chaîne d'approvisionnement et déploiements clandestins. Le modèle à huit facteurs note exactement cela, si bien que deux serveurs d'un même niveau peuvent aboutir à des risques résiduels très différents. Si vous exposez aussi un modèle, complétez l'analyse avec le scanner de risque de modèles.

Il s'emboîte dans ce que vos auditeurs attendent déjà

Ce n'est pas une norme isolée. Le cadre s'aligne sur l'OWASP MCP Top 10, l'OWASP LLM Top 10, le NIST AI RMF, l'ISO/IEC 42001 et SOC 2, si bien qu'une décision de gouvernance consignée ici s'insère directement dans les preuves de conformité que vous produisez déjà. L'objectif final est simple : rendre le chemin approuvé plus rapide que le déploiement clandestin, car une gouvernance plus lente que « lance-le toi-même » n'est pas suivie, elle est contournée.