Dès qu’un agent reçoit un accès à la production, la connexion MCP devient un sujet de sécurité à part entière. Avant la première requête, l’équipe doit vérifier les permissions, les données exposées, les actions autorisées, les journaux et la procédure de révocation.
En 1999, au Jet Propulsion Laboratory de Pasadena, les équipes de la NASA attendaient un signal de Mars Climate Orbiter après son passage derrière Mars. La sonde devait se placer en orbite. Le signal n’est jamais revenu.
L’enquête a établi qu’une équipe avait produit des données d’impulsion en unités anglo-saxonnes, tandis qu’un logiciel en aval les attendait dans le système métrique. Chaque composant pouvait sembler fonctionner correctement de son côté. Leur interface portait pourtant une divergence suffisante pour contribuer à la perte de la mission.
Le rapport de la NASA sur l’accident décrit un problème d’interface, de vérification et de communication entre équipes. C’est précisément la catégorie de risque qui apparaît lorsqu’un agent quitte un environnement de démonstration pour appeler un outil de production via MCP.
Le lundi matin où la démo change de nature
La demande paraît banale: connecter l’agent au CRM, à l’entrepôt de données ou au système de tickets. Le serveur MCP répond déjà en local. Les outils sont visibles. Une requête de test renvoie le bon résultat.
Puis arrivent les identifiants de production.
À cet instant, la question technique change. L’enjeu n’est plus de savoir si l’agent peut appeler l’outil. Il faut déterminer ce qu’il peut lire, modifier, déclencher ou divulguer lorsqu’une instruction ambiguë, une donnée malveillante ou une erreur de raisonnement traverse la connexion.
Une permission de lecture peut exposer des coordonnées clients, des notes commerciales ou des documents internes. Une permission d’écriture peut modifier un dossier. Un outil présenté comme une simple recherche peut accepter des paramètres qui élargissent fortement son périmètre. Une chaîne d’outils peut transformer plusieurs actions anodines en opération sensible.
Le premier contrôle utile consiste donc à établir un inventaire concret. Pour chaque outil, notez les ressources accessibles, les opérations possibles, l’identité utilisée et les conséquences d’un appel incorrect. « Accès au CRM » ne suffit pas. « Lecture des comptes attribués à cette équipe, sans export global ni modification » peut être examiné et testé.
Traiter la connexion comme une frontière de confiance
MCP standardise la manière dont un agent découvre et appelle des outils. Cette commodité réduit le travail d’intégration, mais elle ne décide pas du niveau de confiance à accorder à chaque appel.
Commencez avec une identité dédiée et des droits minimaux. Évitez les jetons personnels empruntés à un administrateur pour accélérer le branchement. Leur périmètre reflète les besoins d’une personne, rarement ceux d’un agent.
Séparez ensuite les actions selon leur impact. Une consultation limitée peut être automatique. Une modification réversible peut demander une confirmation. Un paiement, une suppression, un envoi externe ou un changement de droits exige un contrôle plus strict, voire une validation humaine systématique.
Les entrées méritent la même attention. Un agent peut recevoir des instructions depuis une conversation, mais aussi depuis le contenu qu’il consulte: page web, ticket, document ou champ libre. Ce contenu ne doit pas pouvoir élargir les permissions accordées par le système. L’autorisation doit être imposée au niveau de l’outil et de l’identité, pas confiée au jugement du modèle.
Cette distinction rappelle aussi une leçon familière du logiciel mobile: une validation dans un environnement contrôlé ne prouve pas le comportement dans les conditions réelles. Ce qui se passe quand un build validé sur émulateur arrive sur un vrai téléphone relève du même écart entre test rassurant et système vivant.
Les preuves à exiger avant l’ouverture
Une revue sérieuse doit produire des éléments vérifiables.
Les journaux doivent indiquer quel agent a appelé quel outil, avec quelle identité, à quel moment et pour quelle opération. Les secrets doivent rester hors des invites, des réponses du modèle et des traces destinées aux équipes produit. La révocation doit pouvoir être exécutée rapidement, sans redéployer toute la plateforme.
Testez aussi les refus. Demandez une ressource hors périmètre. Essayez une action interdite. Injectez dans un document une instruction qui tente de détourner l’agent. Vérifiez que l’outil bloque l’opération même si le modèle la demande avec assurance.
Enfin, préparez l’incident avant l’activation. Qui coupe l’accès? Quels journaux seront consultés? Comment repérer les données touchées? Qui décide de remettre la connexion en service? Une procédure courte, testée et attribuée vaut davantage qu’une politique générale rangée dans un dossier.
L’acquisition de Virtue AI par Fortinet illustre d’ailleurs la direction prise par le marché: tests automatisés, protection à l’exécution et surveillance des agents, des modèles et des outils MCP. Cette évolution confirme que la sécurité des agents se joue pendant leur fonctionnement autant qu’avant leur déploiement.
Le contrat d’interface est le vrai produit
Mars Climate Orbiter n’a pas été perdu parce que les interfaces étaient inutiles. Il a été perdu dans un système où une hypothèse critique n’a pas été correctement alignée, vérifiée et détectée à temps.
Pour une connexion MCP, le contrat doit préciser davantage que le nom des outils. Il doit couvrir les unités de confiance du système: identité, portée, données, effets, confirmations, traces et arrêt d’urgence.
Le lundi matin, une connexion réussie peut donner l’impression que le travail est terminé. En production, elle marque le début de la revue qui compte. Le bon critère n’est pas « l’agent a réussi son appel », mais « l’appel incorrect est contenu, visible et révocable ».
Commentaires
Pas encore de commentaires.