Gouvernance MCP : comment contrôler ce que les agents IA peuvent faire dans vos SaaS

Qu’est-ce que la gouvernance MCP ?

La gouvernance MCP est la pratique consistant à contrôler, autoriser et auditer ce que les agents IA ont le droit de faire lorsqu’ils appellent vos outils via le Model Context Protocol (MCP). Concrètement, cela signifie donner à chaque agent une identité enregistrée, cadrer son accès à des outils précis, confronter chaque appel d’outil à une politique avant qu’il n’atteigne votre SaaS, journaliser l’appel, et pouvoir révoquer cet accès instantanément.

C’est la discipline que vous appliquez déjà à vos collaborateurs, appliquée au logiciel qui agit désormais à leurs côtés. Les humains ont le SSO, des rôles, des journaux d’audit et un processus de départ. Les agents, jusqu’à récemment, avaient une clé d’API collée dans un fichier de configuration, et rien d’autre. La gouvernance MCP comble cet écart.

Pourquoi MCP change le problème d’accès

Le Model Context Protocol, publié par Anthropic fin 2024, s’est imposé comme la façon standard de connecter les agents IA à des outils externes. Plutôt que de livrer une intégration sur mesure pour chaque application SaaS, les agents appellent les outils via des serveurs MCP : un intermédiaire standardisé qui arbitre la connexion. Claude, et une liste croissante d’autres clients, le parlent nativement.

Cette standardisation coupe des deux côtés. Elle rend les agents nettement plus capables, puisqu’un seul protocole débloque tous les outils connectés. Et elle concentre le risque, puisqu’un seul agent mal doté peut désormais lire, écrire et agir sur l’ensemble de votre parc SaaS par un seul canal. La propriété qui rend MCP utile, une couche de connexion unique, est exactement ce qui en fait le bon endroit où poser des contrôles.

Pourquoi une clé d’API n’est pas de la gouvernance

Aujourd’hui, la façon par défaut dont un agent obtient un accès est simple : quelqu’un génère une clé d’API, la colle dans la configuration de l’agent, et l’agent se met à appeler des API. Cette clé est un identifiant brut. Elle hérite en général de tous les droits de son créateur, elle expire rarement, et rien n’enregistre ce que l’agent en a réellement fait.

Le problème n’est pas que les clés d’API soient mauvaises, c’est qu’un identifiant n’est pas un contrôle. La gouvernance, c’est ce que vous enroulez autour de l’identifiant pour qu’il puisse être raisonné, revu et révoqué. Pour comprendre pourquoi l’outillage d’identité traditionnel manque totalement les agents, lisez La faille de gouvernance de l’IA.

Gouvernance ou autorisation

Ces deux termes s’emploient indifféremment, et ils ne devraient pas.

On peut avoir de l’autorisation sans gouvernance : une passerelle qui autorise ou bloque des appels, mais ne garde aucune trace durable et n’est jamais revue. Cela réussit une démonstration et rate un audit. La gouvernance, c’est ce dont un auditeur, un régulateur ou votre vous-même futur a réellement besoin.

Le motif de la passerelle MCP

La façon la plus propre de gouverner les agents est de cesser de leur confier des identifiants. À la place, placez un serveur entre vos agents et vos outils SaaS. Les agents appellent les outils à travers lui ; c’est lui qui détient les identifiants, prend les décisions et garde la trace. C’est la passerelle MCP (parfois appelée proxy MCP), l’équivalent de ce que fait une passerelle d’API pour des services, ou un reverse proxy pour le trafic web.

Une passerelle MCP gouvernante fait cinq choses à chaque requête :

• Elle authentifie l’agent appelant et le rattache à une identité et un rôle enregistrés
• Elle confronte l’appel d’outil à la politique avant de le transmettre au SaaS cible
• Elle transmet les appels autorisés, avec des identifiants que l’agent ne voit jamais
• Elle bloque les appels qui violent la politique, et peut ouvrir une demande d’accès pour revue
• Elle écrit une entrée de journal inaltérable : quel agent, quel outil, quels paramètres, quelle issue

À quoi cette application ressemble en pratique :

Les deux lignes DENY sont tout l’enjeu. Journaliser ce qui s’est passé est le minimum ; la gouvernance consiste à empêcher la mauvaise chose de se produire, et à pouvoir le prouver. Pour une mise en pratique complète du branchement d’un agent à travers une passerelle avec un accès cadré, voyez comment connecter Claude à Slack via MCP avec des contrôles d’accès.

Les cinq contrôles de la gouvernance MCP

Quel que soit l’outil retenu, un modèle complet de gouvernance MCP repose sur cinq contrôles. S’il en manque un, vous avez une faille qu’un auditeur, ou un incident, trouvera.

1. L’identité

Chaque agent est enregistré comme une identité de plein droit : un nom, un propriétaire, une finalité déclarée et une expiration. Pas un compte de service, pas une clé anonyme. Quand un appel d’outil a lieu, vous savez quel agent l’a fait et qui en répond.

2. Une portée en moindre privilège

Un agent reçoit des rattachements explicites aux seuls outils dont il a besoin, et rien de plus. Un résumeur qui lit Slack et publie dans un canal n’obtient pas l’écriture sur votre CRM. Les portées sont étroites par défaut ; les élargir est un acte délibéré et journalisé.

3. Une autorisation fondée sur la politique

Chaque appel d’outil est confronté à la politique en temps réel. Lecture ou écriture, limites de débit, contraintes de paramètres et règles sur les données personnelles sont évaluées avant que l’appel n’atteigne le SaaS. Tout ce qui sort de la politique est bloqué, pas simplement journalisé après coup.

4. Une piste d’audit inaltérable

Chaque appel, autorisé ou refusé, est écrit dans un journal infalsifiable avec tout son contexte : agent, outil, paramètres, réponse, et politique appliquée. Ce journal est exportable comme preuve pour SOC 2, ISO 27001 et les exigences de journalisation du règlement européen sur l’IA.

5. La révocation et la revue

Vous pouvez suspendre un agent globalement en une action, un coupe-circuit qui arrête l’accès sur tous les outils d’un coup, sans partir à la chasse aux identifiants. L’accès est limité dans le temps (l’expiration force une décision périodique de renouvellement), revu selon un calendrier, et signalé automatiquement au départ du propriétaire de l’agent. Un agent dont le créateur est parti ne devrait jamais continuer de tourner en silence ; voyez quand le collaborateur part mais que l’agent reste.

Shadow MCP : la partie que personne ne surveille

Il existe un problème de gouvernance situé un cran au-dessus de la politique : les agents et serveurs MCP dont vous ignorez l’existence. Un développeur monte un connecteur MCP vers un outil SaaS pour un projet annexe. Une équipe branche un agent interne sur votre entrepôt de données. Rien de tout cela ne passe par une revue de sécurité. C’est le shadow MCP, le cousin natif de l’IA du shadow IT : il détient des identifiants vivants vers des systèmes de production tout en restant invisible pour ceux qui en répondent.

On ne gouverne pas ce qu’on ne voit pas. La découverte, c’est-à-dire trouver les serveurs MCP et connecteurs d’agents non gouvernés puis les ramener sous les contrôles ci-dessus, est la condition préalable à tout le reste. C’est le même muscle que la découverte du shadow AI, braqué sur une nouvelle surface. La plupart des outils de gouvernance des accès supposent que les agents arrivent déjà enregistrés ; l’étape la plus difficile, et la plus utile, est de faire remonter ceux qui ne le sont pas.

Une checklist de gouvernance MCP

Un point de départ pratique. Si vous pouvez répondre oui à chaque point, vous avez de la gouvernance, pas seulement de la connectivité :

• Chaque agent est-il enregistré avec un propriétaire nommé, une finalité et une date d’expiration ?
• Chaque agent dispose-t-il de rattachements explicites en moindre privilège plutôt que d’une clé large ?
• Chaque appel d’outil est-il autorisé par la politique avant d’atteindre le SaaS ?
• Les agents appellent-ils les outils via une passerelle, plutôt que de détenir des identifiants bruts ?
• Existe-t-il un journal inaltérable et exportable de chaque appel, avec tout son contexte ?
• Pouvez-vous suspendre n’importe quel agent sur tous les outils en une seule action ?
• Les droits d’accès des agents sont-ils revus selon un calendrier et révoqués au départ de leur propriétaire ?
• Cherchez-vous activement les serveurs et agents MCP non gouvernés (shadow) ?

Les cadres évoqués ici ne sont pas nouveaux : nous avons passé vingt ans à les mettre au point pour les humains. Ce qui est nouveau, c’est l’urgence de les appliquer aux agents avant que les déploiements ne dépassent le point où l’on peut encore greffer des contrôles. Le point de contrôle existe déjà : c’est la couche MCP. La question est de savoir ce que vous y faites respecter.

Questions fréquentes

Qu’est-ce que la gouvernance MCP ?

La gouvernance MCP est la pratique consistant à contrôler, autoriser et auditer ce que les agents IA peuvent faire lorsqu’ils appellent des outils via le Model Context Protocol. Elle donne à chaque agent une identité enregistrée, cadre son accès à des outils précis, confronte chaque appel d’outil à une politique avant qu’il n’atteigne votre SaaS, journalise l’appel, et vous permet de révoquer l’accès instantanément.

Quelle différence entre autorisation MCP et gouvernance MCP ?

L’autorisation MCP est la décision, prise appel par appel, de savoir si un agent donné peut invoquer un outil donné. La gouvernance MCP est le programme plus large qui l’entoure : enregistrer les agents comme des identités, leur attribuer rôles et portées, journaliser chaque appel, revoir périodiquement les accès, et les révoquer au départ. L’autorisation est un contrôle à l’intérieur de la gouvernance.

Pourquoi une clé d’API ne suffit-elle pas à gouverner les agents IA ?

Une clé d’API est un identifiant brut, sans identité, sans politique par appel, sans expiration par défaut, et sans piste d’audit de ce que l’agent a réellement fait. Elle hérite en général de tous les droits de son créateur, survit à son départ, et ne peut pas être révoquée sans retrouver et faire tourner la clé partout où elle a été collée.

Qu’est-ce qu’une passerelle MCP ?

Une passerelle MCP est un serveur placé entre vos agents IA et vos outils SaaS. Les agents appellent les outils à travers elle plutôt que de détenir directement des identifiants. Elle authentifie l’agent, confronte chaque appel d’outil à la politique, transmet les appels autorisés, bloque les autres, et écrit un journal d’audit inaltérable. C’est le point d’application naturel de la gouvernance MCP.

Qu’est-ce que le shadow MCP ?

Le shadow MCP désigne les serveurs MCP et connecteurs d’agents IA déployés sans revue de sécurité ni gouvernance centrale, souvent par des développeurs ou des équipes isolées. Comme le shadow IT, ils détiennent des identifiants vivants vers des SaaS de production et restent invisibles pour l’équipe sécurité jusqu’à ce qu’ils soient découverts et ramenés sous gouvernance.