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.

Le travail se découpe en quatre couches, chacune traitée plus bas : les serveurs MCP que votre organisation autorise, les jetons et identifiants qu’ils utilisent, les outils individuels qu’un agent peut appeler et avec quels paramètres, et les agents eux-mêmes, en tant qu’identités dotées d’un propriétaire. Un programme qui ne couvre qu’une couche laisse les trois autres ouvertes.

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.

Gouvernance des serveurs MCP : quels serveurs, quelles versions, qui s’y connecte

Chaque capacité d’un agent arrive par un serveur MCP. Avant d’écrire une politique sur les appels d’outils, il faut savoir quels serveurs existent dans votre organisation, qui les a approuvés, et quels agents et quelles personnes se connectent à chacun. La gouvernance des serveurs MCP, c’est cet inventaire et le processus d’approbation qui l’entoure.

Inventorier les serveurs réellement en service

Les serveurs MCP viennent de trois sources, et chacune porte un risque différent :

• Les serveurs officiels des éditeurs. Des serveurs distants publiés et hébergés par l’éditeur SaaS, comme le serveur MCP hébergé de Notion. L’éditeur maintient le code, mais le serveur expose toujours des outils de lecture et d’écriture côte à côte, et agit avec l’autorisation OAuth que l’utilisateur lui a accordée.
• Les serveurs communautaires. Des serveurs open source écrits par des tiers, souvent installés comme processus local sur la machine d’un développeur. Ils s’exécutent avec les droits de cette machine et les identifiants placés dans leur configuration, et leur code change à chaque nouvelle version publiée par le mainteneur.
• Les serveurs internes. Des serveurs que vos propres équipes construisent pour exposer une base de données, une API interne ou un entrepôt de données. Ils sont rarement revus comme des services de production, même lorsqu’ils atteignent des données de production.

Pour chaque serveur, l’inventaire consigne qui le publie, où il s’exécute (processus local ou point de terminaison distant), quels outils il expose, quel identifiant il utilise pour atteindre le système qui se trouve derrière, qui en est propriétaire en interne, et quels agents s’y connectent. Cette fiche répond à la première question d’un auditeur : que peuvent atteindre vos agents ?

Approuver les serveurs avant que les agents s’y connectent

Une liste d’autorisation transforme l’inventaire en contrôle. Chaque serveur est revu une fois, sur son éditeur, ses outils, l’identifiant dont il a besoin et la destination de ses données, et seuls les serveurs approuvés peuvent être connectés. Tout le reste est bloqué ou remonté pour revue. Sans liste d’autorisation, l’ensemble des serveurs en service correspond à ce que chaque développeur a bien voulu installer, et c’est ainsi que commence le shadow MCP.

Figer les versions et revoir les changements d’outils

Un serveur approuvé ne l’est pas pour toujours. Une nouvelle version peut ajouter des outils, changer ce que fait un outil existant ou réécrire sa description, et les descriptions d’outils sont transmises au modèle, qui les lit pour décider quoi appeler. Figez la version que vous avez revue, comparez la liste d’outils à chaque nouvelle version, et traitez un nouvel outil d’écriture ou de suppression comme une nouvelle approbation plutôt que comme une mise à jour de routine. Dans Lutril, le proxy applique cette règle aux serveurs d’éditeurs qu’il relaie, comme celui de Notion : les outils d’une liste de lecture connue passent avec un rattachement en lecture, et tout outil hors de cette liste est traité comme une écriture qui exige une attribution approuvée, si bien qu’un outil ajouté plus tard par l’éditeur n’est pas appelable par défaut.

Décider qui peut connecter quoi

Reste la question de l’appariement : quel agent, ou quelle personne, peut utiliser quel serveur, et à quel niveau. Un agent de support peut avoir besoin de lire des tickets ; il n’a aucun besoin du serveur du CRM. Consigner chaque appariement comme un rattachement explicite, en lecture ou en écriture, le rend révisable. Dans Lutril, les rattachements d’un agent décident de ce qu’il voit : seuls les outils des intégrations auxquelles il est rattaché sont enregistrés pour lui, si bien qu’un agent rattaché à Slack seul ne voit que des outils Slack.

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.

Gouvernance des jetons et identifiants MCP

Un déploiement MCP met en jeu deux jeux d’identifiants, et les deux doivent être gouvernés. Le premier est ce que l’agent présente au serveur MCP. Le second est ce que le serveur utilise pour atteindre le SaaS qui se trouve derrière : un jeton d’accès OAuth ou une clé d’API. Pour les serveurs distants, la spécification MCP fonde l’autorisation sur OAuth 2.1 et impose aux serveurs de rejeter les jetons qui n’ont pas été émis pour eux. Elle ne décide pas où votre organisation conserve ces jetons, combien de temps ils vivent, ni qui peut les révoquer. Cette partie-là relève de la gouvernance.

Où vivent les jetons

Le point de départ habituel est un fichier de configuration JSON sur un ordinateur portable, avec une clé d’API ou un jeton d’accès personnel dans une variable d’environnement pour chaque serveur. Ces identifiants sont copiés d’une machine à l’autre, poussés par erreur dans des dépôts de code, et survivent aux projets pour lesquels ils ont été créés. Personne ne peut les lister, donc personne ne peut tous les révoquer.

L’alternative gouvernée conserve les jetons en amont à un seul endroit, côté serveur et chiffrés, et donne à l’agent un unique identifiant qui l’identifie auprès de la passerelle, et rien d’autre. L’agent ne détient jamais le jeton Slack ou HubSpot ; la passerelle l’ajoute quand un appel est autorisé. Dans Lutril, l’enregistrement d’un agent émet un jeton MCP propre à cet agent. Les identifiants SaaS restent dans le proxy, les identifiants des agents sont stockés chiffrés, et seule une empreinte du secret de l’agent est conservée pour la vérification.

Des identifiants courts et cadrés plutôt que des clés statiques

Une clé d’API statique accorde tout ce que son créateur pouvait faire, aussi longtemps qu’elle existe. Un identifiant de courte durée, cadré sur un agent et un ensemble d’outils, limite les deux dimensions : un jeton divulgué cesse vite de fonctionner, et tant qu’il est valide il n’atteint que ce à quoi l’agent était rattaché. Quand un éditeur prend en charge OAuth, préférez des jetons aux portées étroites plutôt que des clés valables pour tout le compte, et un identifiant par agent plutôt qu’un identifiant partagé entre plusieurs, pour que révoquer un agent ne casse pas les autres.

Rotation et révocation

La rotation est un calendrier, pas une réponse à incident. Les identifiants tournent à cadence fixe, avec un court chevauchement pour qu’un agent en cours d’exécution n’échoue pas au milieu d’une tâche pendant qu’il récupère le nouveau. La révocation se fait en un seul point et prend effet partout : quand un agent est retiré, quand son propriétaire part, ou quand un jeton a pu fuiter. Le registre d’agents de Lutril fait tourner ou expirer les clés d’un agent selon un calendrier, garde l’identifiant précédent valide pendant une période de grâce jusqu’à confirmation de la rotation, et suspend un agent au niveau du proxy en une action, ce qui arrête ses appels sans toucher à aucun jeton SaaS en amont.

Gouvernance des outils MCP et gestion des permissions

Approuver un serveur est trop grossier à lui seul. Un même serveur expose couramment des outils de recherche, de lecture, de création, de modification et de suppression, et un agent qui résume des pages n’a aucune raison de les supprimer. La gouvernance des outils MCP fixe les permissions au niveau de chaque appel d’outil.

Une politique par outil et par paramètre

Une politique utile nomme l’outil et contraint ses arguments. Ces règles sont difficiles à exprimer avec une clé et simples à exprimer au niveau d’une passerelle :

• Autoriser search et get_page, refuser delete_page
• N’autoriser la publication de messages que dans une liste nommée de canaux
• Autoriser la lecture des affaires, refuser les exports de contacts en masse
• Plafonner le nombre d’appels qu’un agent peut faire par minute
• Détecter et masquer les données personnelles et les secrets avant que le modèle ne les voie

Le proxy MCP de Lutril confronte chaque appel au rôle de l’agent, à l’outil, à ses paramètres et aux limites de débit avant que la requête ne quitte votre périmètre. Son DLP s’exécute sur la même couche, si bien que les mêmes règles de masquage s’appliquent au chat, aux copilotes et aux appels d’outils MCP.

Séparer la lecture de l’écriture

L’essentiel du risque lié aux accès d’un agent se trouve dans ses outils d’écriture et de suppression. Une lecture peut faire fuiter des données ; une écriture peut les modifier ou les détruire, envoyer des messages en votre nom ou déclencher des processus en aval. Un bon réglage par défaut accorde la lecture avec le rattachement et traite chaque écriture comme une décision distincte et explicite. C’est la passerelle qui fait respecter cette distinction, pas l’agent : si la seule chose qui empêche une écriture est que l’agent choisit de ne pas la faire, il n’y a pas de contrôle.

Une approbation humaine pour les appels sensibles

Certains appels doivent rester possibles, mais pas sans surveillance : une écriture dans un système de production, un export en masse, une suppression, un message à un client. Pour ceux-là, la passerelle retient l’appel et interroge une personne. La demande porte son contexte (quel agent, quel outil, quels paramètres, pour le compte de qui), part vers un réviseur capable de juger si l’action a du sens, et a une validité limitée, pour qu’une approbation ne devienne pas une attribution permanente. Dans Lutril, les appels en lecture peuvent être autorisés tandis que les écritures exigent une approbation humaine dans Slack, Teams ou l’interface de l’application. La décision est journalisée avec l’appel, et une attribution peut être limitée dans le temps ou à usage unique.

Un cadre et une checklist de gouvernance MCP

Les cinq contrôles décrivent ce que possède un déploiement gouverné. Un cadre décrit l’ordre dans lequel on le construit, parce que chaque étape dépend de la précédente.

Les six étapes

• Découvrir. Inventorier chaque serveur MCP, chaque agent et chaque identifiant en service, y compris ceux que personne n’a enregistrés.
• Approuver. Placer les serveurs sur une liste d’autorisation et enregistrer chaque agent avec un propriétaire nommé, une finalité et une expiration.
• Cadrer. Rattacher chaque agent aux serveurs et outils dont il a besoin, en lecture par défaut, l’écriture faisant l’objet d’une décision distincte.
• Appliquer. Faire passer chaque appel par une passerelle qui détient les identifiants, applique une politique par outil et par paramètre, masque les données sensibles et demande une approbation lorsque c’est requis.
• Consigner. Écrire chaque appel, autorisé ou refusé, dans un journal inaltérable exportable comme preuve d’audit.
• Revoir et révoquer. Faire tourner les identifiants, revoir les accès des agents selon un calendrier, revoir les serveurs quand leurs outils changent, et garder un coupe-circuit pour chaque agent.

Sauter une étape ne fait pas gagner de temps. Une application sans découverte ne gouverne que les agents déjà connus, et un journal sans revue enregistre la dérive sans la corriger.

La checklist

Si vous pouvez répondre oui à chaque question, vous avez de la gouvernance, pas seulement de la connectivité :

• Existe-t-il un inventaire de chaque serveur MCP en service, avec son éditeur, son propriétaire et les agents qui s’y connectent ?
• Seuls les serveurs MCP approuvés peuvent-ils être connectés, avec des versions figées et une nouvelle revue pour chaque nouvel outil ?
• 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 ?
• Les jetons OAuth et clés d’API en amont sont-ils tenus à l’écart des fichiers de configuration des agents et des ordinateurs portables ?
• Les identifiants des agents tournent-ils selon un calendrier, et peut-on en révoquer un sans casser les autres ?
• Chaque appel d’outil est-il autorisé par la politique avant d’atteindre le SaaS ?
• Les outils d’écriture, de suppression et d’export sont-ils contrôlés séparément de la lecture, avec une approbation humaine pour les plus sensibles ?
• 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.

Comment choisir ses outils de gouvernance MCP

Quatre catégories de produits peuvent faire respecter des politiques de gouvernance sur des déploiements de serveurs MCP. Elles se recoupent, mais chacune part d’un problème différent, et le bon choix dépend de ce que vous devez gouverner par ailleurs. Les exemples ci-dessous sont les produits comparés en détail dans le comparatif des passerelles MCP.

Les passerelles MCP dédiées

Une passerelle dédiée se place entre les clients IA et les serveurs MCP, et prend en charge l’authentification, la politique et la journalisation des appels d’outils. MintMCP en est un exemple, avec un middleware programmable capable de bloquer sur le nom de l’outil, la valeur des arguments ou le contenu du prompt, des enregistrements d’audit signés en ajout seul et un coupe-circuit à l’échelle de l’organisation. Son périmètre s’arrête aux droits sur les outils MCP : elle convient quand la gouvernance des accès des personnes derrière les agents est assurée ailleurs.

Les points de décision d’autorisation

Un point de décision évalue une politique et rend une décision ; il ne relaie pas lui-même le trafic. Cerbos en est un exemple : un point de décision de politique open source qu’une passerelle comme agentgateway appelle avant l’exécution d’un outil, avec une politique écrite sous forme de code. Il convient aux équipes qui exploitent déjà une passerelle et veulent un seul langage de politique pour leurs applications et leurs agents.

Les proxys sensibles à l’identité

Un proxy sensible à l’identité applique la politique en ligne, devant les applications comme devant les agents. Datawiza en est un exemple : une Agent Gateway placée entre les agents et les outils, API, serveurs MCP et systèmes SaaS qu’ils atteignent, qui fait office d’intermédiaire pour les identifiants afin que les agents ne détiennent aucun secret et applique la politique avant les appels d’outils, à côté d’un Access Proxy pour les applications historiques et sur site.

Les plateformes de gouvernance des accès dotées d’un proxy MCP

Dans cette catégorie, le proxy MCP est une partie d’une plateforme qui gouverne aussi les collaborateurs. Lutril en est un exemple : les agents sont enregistrés avec un propriétaire et des portées, chaque appel est confronté à la même politique fondée sur les rôles que celle des collaborateurs, les prompts passent par le DLP, les appels atterrissent dans un journal WORM, un seul coupe-circuit met en pause n’importe quel agent, et le même produit gère la découverte du shadow AI, les revues d’accès, l’arrivée et le départ des collaborateurs, avec des approbations dans Slack, Teams ou l’interface de l’application. C’est un SaaS hébergé en France, sans option auto-hébergée.

Choisir quand on fait tourner de nombreux agents

Avec un ou deux agents, la plupart de ces produits font l’affaire. Les différences apparaissent quand des dizaines d’agents appartiennent à des équipes différentes. À ce stade, ces questions départagent les options :

• Le produit relaie-t-il lui-même les appels, ou décide-t-il seulement sur des appels qu’un autre composant achemine ?
• Chaque agent a-t-il sa propre identité et un propriétaire nommé, ou les agents partagent-ils des identifiants ?
• La politique peut-elle contraindre les paramètres, et pas seulement les noms d’outils ?
• Le journal d’audit est-il infalsifiable, et enregistre-t-il les appels refusés autant que les appels autorisés ?
• Pouvez-vous mettre en pause un agent, et tous les agents, depuis un seul endroit ?
• Où ont lieu les approbations humaines, et sont-elles journalisées avec l’appel ?
• Trouve-t-il les agents et serveurs que personne n’a enregistrés ?
• Les agents passent-ils par les mêmes revues d’accès et le même processus de départ que les collaborateurs qui en sont propriétaires ?
• Peut-il s’exécuter là où vos données doivent rester : en auto-hébergement, ou dans une région précise ?

Le comparatif des passerelles MCP répond à ces questions pour MintMCP, Cerbos, Datawiza et Lutril, en citant la documentation publique de chaque éditeur.