Dans certaines entreprises qui utilisent le Model Context Protocol (MCP), j’ai relevé certains aspects qui méritent une attention accrue et que je souhaite partager ici.
De manière générale, la quasi-totalité des discussions avec elles se concentre sur la facilité d’intégrer les systèmes et de mettre à disposition des outils pour les LLM. Peu de choses sont dites sur la sécurité, les performances, la gouvernance et l’architecture opérationnelle.
Le MCP représente une avancée majeure dans la standardisation de la communication entre les applications basées sur les LLM et les outils externes. Tout comme des protocoles tels que HTTP ont standardisé l’accès aux ressources sur le Web, le MCP cherche à standardiser la manière dont les modèles découvrent et utilisent les outils, les API, les bases de données et d’autres services. Cela réduit de manière significative la complexité des intégrations. Mais cela élargit aussi l’ensemble des capacités désormais accessibles aux agents.
Il est important de préciser que le MCP n’est qu’un protocole de communication. Les risques ne proviennent pas du protocole en lui-même, mais des architectures qui se bâtissent autour de lui.
Dans des architectures axées sur des agents, par exemple, le modèle peut décider quelles outils utiliser, dans quel ordre les exécuter, quels paramètres envoyer et comment combiner les résultats obtenus. Le LLM ne se contente plus de produire du texte; il participe à l’orchestration des processus opérationnels de l’entreprise.
Chaque outil ajouté à un serveur MCP représente une nouvelle capacité opérationnelle. Consulter un ERP, mettre à jour un CRM, accéder à des documents internes ou lancer une opération financière ne se limitent plus à des fonctionnalités accessibles aux utilisateurs et s’intègrent désormais à l’ensemble des actions utilisables par les agents.
Le premier risque que je rencontre fréquemment concerne l’identité et l’autorisation. Lorsque l’identité de l’utilisateur n’est pas propagée tout au long de la chaîne d’exécution, le serveur MCP peut utiliser des identifiants propres pour accéder aux systèmes d’entreprise. Si ces identifiants disposent de privilèges supérieurs à ceux de l’utilisateur qui a initié la demande, survient un problème de sécurité classique appelé le Confused Deputy: l’architecture exécute des opérations que cet utilisateur n’aurait jamais pu réaliser directement. Le principe du moindre privilège reste fondamental. Dès que possible, l’identité, les rôles et les autorisations de l’utilisateur doivent être préservés durant toute l’exécution.
Un autre aspect important est l’Indirect Prompt Injection. Ce risque apparaît déjà dans la documentation de divers fournisseurs et ne se limite pas à amener le modèle à générer une réponse inappropriée. Un document, un e-mail ou une page Web apparemment légitimes peuvent contenir des instructions capables d’influencer la planification de l’agent lors de l’utilisation des outils. Le problème ne réside plus seulement dans une réponse incorrecte: il peut conduire à une sélection inappropriée d’outils, à l’exécution d’opérations inutiles ou à l’envoi de paramètres incorrects. Plus l’autonomie de l’agent est grande, plus l’impact potentiel est élevé.
J’ai également constaté un excès de contexte partagé entre les outils. Des documents complets, des historiques entiers de conversations et des données personnelles étaient envoyés alors que seules quelques valeurs auraient suffi. Outre les risques relatifs à la vie privée et à la LGPD, cela augmente la consommation de tokens, la latence et les coûts. Le principe de minimisation des données demeure aussi important dans les architectures d’IA que dans les applications traditionnelles.
Un autre point peu discuté est l’explosion des capacités. À mesure que davantage d’outils deviennent disponibles pour l’agent, l’espace de décision quant à l’outil à utiliser s’élargit. Cela peut accroître la complexité de la planification, augmenter les coûts, rallonger la latence et accroître la probabilité de choix inappropriés.
On remarque aussi le comportement en cascade des appels. Un seul prompt peut amener un agent à interroger un serveur MCP, qui déclenche diverses APIs, bases de données et autres services internes. Pour l’utilisateur, cela ne se traduit que par une réponse légèrement plus lente. Dans les coulisses, des dizaines d’opérations ont pu être exécutées. Chaque nouvelle dépendance augmente la latence, accroît le risque de pannes et rend bien plus difficile l’identification de l’origine d’un incident.
Par conséquent, l’observabilité doit aller bien au-delà de l’enregistrement des prompts et des réponses. Il est crucial d’enregistrer quels outils ont été utilisés, pourquoi ils ont été choisis, quels paramètres ont été reçus, combien de temps ils ont consommé, quels modèles ont participé à l’exécution, quelle a été la consommation de jetons, quelles permissions étaient associées à l’utilisateur et de corréler l’ensemble de la séquence d’appels à l’aide d’identifiants de traçage. Sans ce niveau de traçabilité, les audits et les enquêtes deviennent extrêmement complexes.
Autre point notable est la difficulté à maîtriser les coûts. De petits changements dans le contexte, dans la stratégie de planification de l’agent ou dans le nombre d’outils disponibles peuvent modifier complètement la charge informatique. Les retries automatiques, les appels parallèles et les chaînes d’exécution longues rendent le coût bien moins prévisible que dans les architectures traditionnelles. Des limites d’exécution, du cache, de la surveillance et des politiques d’utilisation deviennent essentiels.
Un autre risque peu discuté est la manipulation des réponses des outils, souvent appelée Tool Poisoning. En général, l’agent suppose que les informations retournées sont fiables. Mais un serveur MCP compromis, une API vulnérable ou un service qui renvoie des données manipulées peuvent influencer les décisions ultérieures. La sortie des outils doit également être traitée comme une entrée non fiable.
Il faut aussi porter attention aux architectures multi-agents. Un agent peut en déclencher un autre, qui consulte de nouveaux outils, qui à leur tour démarrent de nouvelles exécutions. Sans limites de profondeur, sans mécanismes de confinement et de contrôle des boucles, ce comportement peut provoquer une explosion des coûts, une augmentation marquée de la latence et des cycles difficiles à interrompre.
Un autre aspect souvent négligé est l’idempotence, un principe fondamental des systèmes distribués. En termes simples, une opération idempotente peut être exécutée plusieurs fois sans produire d’effets en double. Imaginez qu’un agent demande un transfert bancaire. L’opération est terminée, mais un timeout survient avant le retour de la réponse. Sans savoir si le transfert a été effectué, l’agent peut réessayer. S’il n’existe pas de mécanisme d’idempotence, le paiement pourrait être effectué deux fois. Le même risque existe pour la création de commandes, les validations, les mises à jour de données ou toute autre opération ayant des effets permanents. Plus l’autonomie des agents est grande, plus il devient crucial de s’assurer qu’une nouvelle tentative n’entraîne pas une seconde exécution de la même action.
En fin de compte, nous relions des modèles probabilistes à des systèmes déterministes. Un ERP, un système financier ou une base de données attendent des commandes précises et prévisibles. Un LLM produit la séquence de jetons statistiquement la plus probable compte tenu du contexte disponible. Alors que l’erreur d’un chatbot se termine généralement par une réponse incorrecte, l’erreur d’une architecture fondée sur le MCP peut entraîner de réelles modifications opérationnelles.
Ainsi, j’ai l’impression que de nombreuses organisations perçoivent encore le MCP uniquement comme un standard d’intégration. En pratique, il devient une couche d’orchestration entre les modèles et les systèmes d’entreprise. Et toute couche d’orchestration doit être conçue dès le départ avec authentification, autorisation, observabilité, audit, isolation, limitation des privilèges, mécanismes de confinement des défaillances et gouvernance.
La facilité de connexion des outils est justement ce qui rend le MCP si puissant. Et c’est aussi ce qui rend son adoption bien plus complexe qu’il n’y paraît au premier abord.
