L'illusion de la gouvernance MCP : pourquoi il ne suffit pas de gouverner les outils

Il existe un vieux cliché selon lequel les équipes de sécurité travaillent avec des listes tandis que les attaquants utilisent des modèles de graphes, créant un fossé qui complexifie la sécurité. La communauté de la sécurité en a pris conscience et s'efforce de combler ce vide. Aujourd'hui, les agents capables d'exécuter du code portent ce problème à un niveau supérieur. Par exemple, si je souhaite bloquer totalement la connexion entre ma pile IA et ma base de données Snowflake, l'approche naïve consiste à empêcher mon organisation d'exécuter un serveur MCP Snowflake. Problème résolu. 

Si cette solution de sécurité peut fonctionner pour des agents dépourvus d'outil bash, puisqu'ils ne peuvent pas écrire de code pour les contourner, un agent capable d'exécuter du code (comme Claude Cowork ou Codex) change complètement la donne. Il recherchera 5 solutions pertinentes, comme localiser des identifiants utilisateur, trouver une clé API, exécuter un connecteur Python, se connecter à un autre serveur, lire des journaux, ou tout ce qui lui permettra de résoudre et d'optimiser le problème. 

Ici, un simple programme de gouvernance ne suffit pas ; une solution plus robuste est nécessaire. Dans cet article, nous examinons ce problème en profondeur et suggérons des solutions plus holistiques.

Pourquoi la gouvernance des outils passe à côté de l'essentiel

La gouvernance MCP repose sur une hypothèse héritée de la sécurité logicielle traditionnelle, où l'outil constitue le point de contrôle. Lorsqu'un développeur utilise une API approuvée, les contrôles d'accès, les journaux d'audit et les limites de débit de cette API régissent ce qui se passe. Lorsqu'un utilisateur opère via une application approuvée, celle-ci applique les règles métier. C'est une solution raisonnable pour les humains, car ils utilisent un nombre limité d'outils sur une longue période. Les agents, en revanche, fonctionnent différemment : ils recherchent et découvrent des chemins pour atteindre leur objectif en temps réel. Si un chemin est bloqué, l'agent évalue des alternatives et en sélectionne une jusqu'à ce que l'objectif soit atteint, même si cela implique de contourner les contrôles de sécurité et de mettre l'organisation en péril.

Une restriction, de multiples chemins

Analysons le premier exemple en détail. Imaginons une organisation qui interdit aux agents d'accéder à Snowflake via un serveur MCP. L'équipe de gouvernance examine la restriction, l'approuve et clôt le ticket. Cependant, elle n'a restreint qu'un seul chemin d'exécution. Voici ce que l'agent peut toujours faire :

• Se connecter via le SDK Python de Snowflake
• Exécuter du SQL via un script avec des identifiants extraits d'une variable d'environnement
• Invoquer l'interface en ligne de commande (CLI) de Snowflake
• Récupérer des identifiants depuis un gestionnaire de secrets connecté
• Se connecter à la console Snowflake via l'automatisation de navigateur

Au moins cinq chemins restent ouverts alors que la restriction MCP n'en a supprimé qu'un seul ; l'accès à Snowflake reste donc possible. Pour un utilisateur humain, il est clair qu'il s'agit d'une restriction. Certains renonceront, d'autres discuteront avec l'équipe de gouvernance pour trouver un compromis, et seuls quelques-uns tenteront de contourner la restriction avec des astuces ponctuelles. Cependant, la vitesse et la capacité de recherche, de découverte et d'application d'une solution ne seront jamais comparables à celles d'un agent IA.

La même logique s'applique à chaque catégorie d'action sensible. Bloquez la capacité d'envoi d'e-mails et l'agent lancera un service SMTP, le configurera et enverra des e-mails. Bloquez le MCP Salesforce et l'agent trouvera des identifiants pour l'API Salesforce afin de l'interroger directement. Bloquez un serveur MCP Slack et l'agent utilisera le SDK. Chaque restriction s'arrête à la limite d'un outil, tandis que la portée de l'agent s'étend bien au-delà.

C'est une caractéristique propre aux agents capables d'exécuter du code. Des modèles plus performants trouvent davantage de chemins alternatifs. Dans cet environnement, les restrictions d'outils offrent des rendements décroissants.

‍

Gouverner l'intention, pas les outils

Nous affirmons que la seule question qui compte, lorsqu'il s'agit de gouverner l'IA, est Quel résultat l'agent peut-il atteindre ?

Les résultats qui méritent d'être régis transcendent les limites de chaque outil :

• Exporter des données client en dehors de l'organisation
• Supprimer ou modifier des enregistrements de production
• Envoyer des communications externes au nom de l'organisation
• Modifier les autorisations IAM ou les contrôles d'accès
• Créer ou détruire une infrastructure cloud
• Accéder à des systèmes en dehors du périmètre défini de l'agent

La gouvernance doit autoriser ou refuser chacune de ces actions en fonction de l'intention, évaluée avant l'exécution, quel que soit l'outil sélectionné par l'agent. L'écriture dans une table de production nécessite la même autorisation, qu'elle provienne d'un serveur MCP, d'un ORM Python, d'un script SQL brut ou d'une application Terraform.

Ainsi, si nous revenons à l'exemple initial : l'agent IA tente toujours de se connecter à Snowflake. Si nous identifions le résultat, à savoir un accès interdit à Snowflake, nous pouvons désormais surveiller ce résultat et bloquer toute tentative de l'atteindre, que ce soit via un serveur MCP, les identifiants des développeurs, l'exécution du SDK Snowflake avec Python ou tout autre langage.

En pratique, cela signifie capturer les objectifs de l'agent avant l'exécution, classifier l'impact métier et appliquer les décisions au niveau de l'intention. Les restrictions d'outils deviennent une donnée parmi d'autres dans la prise de décision, et non la décision elle-même.

La gouvernance MCP a sa place dans ce modèle. Elle se situe au plus près de l'outil, là où des vérifications rapides permettent de détecter les violations évidentes avant qu'elles n'atteignent la couche d'évaluation de l'intention, plus coûteuse. Elle ne peut cependant pas constituer l'unique couche de protection.

Cyera a récemment annoncé une solution de sécurité pour les agents qui aidera les entreprises à protéger leur main-d'œuvre agentique, incluant une gouvernance basée sur l'intention pour les MCP. Pour en savoir plus, lisez notre article d'annonce, participez à notre prochain webinaire, ou demandez une démonstration.

‍