Sécuriser MCP en production : le guide avant de connecter un agent à vos outils

Un agent IA qui consulte un document ne présente pas le même risque qu'un agent qui peut envoyer un email, modifier un ticket ou déclencher un déploiement.

Le Model Context Protocol, ou MCP, simplifie précisément cette connexion entre un modèle, des sources de contexte et des outils. C'est utile pour éviter de développer une intégration différente pour chaque assistant. Mais une intégration MCP n'est pas un simple branchement technique : elle agrandit la surface d'action du système et introduit une nouvelle frontière de confiance.

La question n'est donc pas seulement : "ce serveur MCP fonctionne-t-il ?" Il faut aussi demander : "que peut-il faire, pour qui, avec quelles données, après quelle validation, et comment le prouver ensuite ?"

Voici la grille que j'utiliserais avant de connecter un serveur MCP à un workflow métier en production.

MCP n'est pas une permission en soi

MCP standardise les échanges entre une application hôte, un client et un serveur qui expose des ressources ou des outils. Le protocole décrit comment découvrir et appeler ces capacités. Il ne décide pas à votre place si un agent peut lire tous les emails, modifier une base de données ou lancer une commande.

Cette distinction est importante : la présence d'un outil dans le catalogue MCP ne doit jamais être interprétée comme une autorisation d'exécution.

La sécurité dépend de plusieurs couches :

• l'identité de l'utilisateur ou du service qui demande l'action ;
• les permissions accordées au client MCP ;
• les contrôles du serveur MCP ;
• les droits du compte utilisé auprès du système cible ;
• l'environnement dans lequel le serveur s'exécute ;
• la validation humaine avant une action irréversible ;
• les journaux permettant de reconstituer ce qui s'est passé.

Un modèle peut être correctement configuré et rester dangereux si le serveur auquel il parle possède trop de droits. À l'inverse, une réponse imparfaite aura un impact limité si l'agent ne peut que lire un jeu de données non sensible et si toute écriture exige une confirmation.

Le risque commence avant le premier appel d'outil

La découverte d'un serveur MCP et de ses capacités mérite autant d'attention que l'appel lui-même. Un nom d'outil rassurant ne suffit pas. Sa description, ses paramètres, ses annotations et son comportement réel doivent être considérés comme des éléments à vérifier.

Les risques les plus fréquents sont liés à la confiance excessive :

• une description d'outil contient une instruction destinée au modèle plutôt qu'une description de son usage ;
• un outil apparemment en lecture possède en réalité un effet de bord ;
• le schéma des paramètres ne correspond pas au comportement du serveur ;
• un serveur distant change après avoir été approuvé ;
• une réponse d'outil contient une instruction qui détourne l'agent de sa tâche ;
• un serveur local exécute une commande avec les mêmes privilèges que le client.

Le guide de sécurité MCP recommande notamment de traiter les outils comme des capacités potentiellement dangereuses, d'obtenir un consentement explicite avant leur invocation et de ne pas faire confiance aux annotations ou descriptions lorsqu'elles proviennent d'une source non fiable. ^1

Avant d'autoriser un serveur, je vérifie donc son origine, son code ou son fournisseur, sa chaîne de mise à jour, les outils exposés, les données accessibles et la manière dont les changements sont détectés.

Séparer lecture, écriture et action irréversible

La première décision d'architecture consiste à découper les capacités par niveau de risque. Un agent qui recherche une facture n'a pas besoin du même accès qu'un agent qui la rembourse.

Je distingue au minimum :

1. Lecture, récupérer une information sans modifier le système.
2. Préparation, calculer ou proposer une action sans l'exécuter.
3. Écriture réversible, créer ou modifier une donnée avec une possibilité d'annulation.
4. Action sensible, envoyer, supprimer, publier, payer ou déployer.

Ces catégories doivent se traduire en permissions techniques et en règles d'approbation. Une simple consigne dans le prompt, comme "demander confirmation avant d'envoyer", ne remplace pas un contrôle appliqué par le serveur ou par la couche d'orchestration.

Pour chaque outil, documentez :

• les données qu'il peut lire ;
• les systèmes qu'il peut modifier ;
• les effets de bord possibles ;
• les erreurs qu'il peut retourner ;
• la personne ou le service au nom duquel il agit ;
• le niveau de confirmation requis ;
• la procédure de désactivation.

La règle du moindre privilège reste valable avec un agent. Donnez-lui uniquement les outils et l'étendue de données nécessaires au workflow courant, pas l'ensemble des capacités disponibles dans votre organisation.

Le consentement doit porter sur une action compréhensible

Demander à un utilisateur d'approuver "l'accès au serveur MCP" est trop vague. Il doit comprendre ce qui sera lu ou modifié, dans quel système, avec quel compte et avec quel résultat attendu.

Une demande de consentement utile précise par exemple :

• l'outil appelé ;
• l'opération réalisée ;
• les ressources concernées ;
• les données envoyées au service ;
• le caractère réversible ou non de l'action ;
• le moment où l'action sera exécutée.

Pour un workflow long, une validation du plan peut être plus lisible qu'une succession de confirmations identiques. Mais le plan doit rester contrôlable : l'utilisateur doit pouvoir le modifier, l'annuler et être sollicité à nouveau si une étape change de nature.

Le consentement n'est pas un bouton décoratif. Il ne protège pas un utilisateur qui ne sait pas ce qu'il autorise, et il ne doit pas être contourné parce qu'une description d'outil affirme que l'action est urgente.

Ne confondez pas authentification et autorisation

Savoir quel client appelle un serveur MCP ne suffit pas. Il faut aussi vérifier ce que ce client a le droit de faire et pour quelles ressources.

Pour un serveur distant, l'autorisation MCP s'appuie sur des mécanismes de l'écosystème OAuth. En pratique, cela implique notamment de protéger la communication en production, de limiter les scopes, de vérifier l'audience des jetons et de ne pas inscrire de secret dans les journaux. La documentation MCP recommande de ne pas utiliser de scopes génériques lorsqu'un découpage par outil ou capacité est possible. ^2

Un anti-pattern particulièrement dangereux consiste à accepter le jeton reçu du client puis à le transmettre tel quel à une API tierce. Le serveur MCP doit vérifier que le jeton lui est destiné et utiliser, lorsque c'est nécessaire, des credentials adaptés à l'appel vers le système aval. Sinon, il devient un proxy qui brouille les responsabilités et peut contourner les contrôles du service cible. ^1

Pour un serveur local, le modèle de menace est différent, mais la question reste la même : quel processus peut le lancer, quelles commandes peut-il exécuter et quelles ressources locales peut-il atteindre ? Le fait qu'il écoute sur localhost ne le rend pas automatiquement sûr.

Traitez les contenus récupérés comme des données non fiables

Un agent qui lit un email, une page web, un ticket ou un document peut rencontrer du contenu qui lui demande d'ignorer sa mission. Cette instruction n'a aucune autorité métier simplement parce qu'elle a été renvoyée par un outil de confiance.

C'est le cas classique de l'injection indirecte : le contenu consulté contient une consigne cachée qui tente de faire exfiltrer une donnée, d'appeler un autre outil ou de modifier la décision de l'agent.

Quelques contrôles réduisent le risque :

• distinguer explicitement les instructions système, les demandes utilisateur et les données récupérées ;
• présenter les contenus externes comme des données à analyser, jamais comme des consignes prioritaires ;
• interdire les enchaînements d'outils qui ne sont pas nécessaires au workflow ;
• bloquer les sorties sensibles vers une destination non approuvée ;
• exiger une validation humaine lorsqu'une donnée externe conduit à une action importante ;
• tester des documents et messages contenant des tentatives d'injection.

Aucune de ces mesures ne transforme un agent en système parfaitement résistant. Elles réduisent surtout le nombre d'actions qu'une erreur de raisonnement ou une injection peut déclencher.

Isolez l'environnement, surtout pour les serveurs locaux

Un serveur MCP local peut avoir accès au système de fichiers, au réseau, aux variables d'environnement et aux commandes disponibles sous le compte qui le lance. Une dépendance compromise ou une configuration malveillante peut alors transformer une intégration d'agent en exécution de code.

Le lancement doit donc être considéré comme une opération sensible :

• affichez la commande complète et ses arguments avant l'installation ;
• utilisez une source et une version vérifiables ;
• exécutez le serveur avec un compte sans privilèges inutiles ;
• limitez les répertoires accessibles ;
• limitez le réseau sortant lorsque le cas d'usage le permet ;
• stockez les secrets hors du contexte du modèle et hors des logs ;
• utilisez un bac à sable ou un conteneur lorsque la plateforme le permet ;
• surveillez les changements de configuration et les mises à jour.

La documentation MCP recommande notamment le consentement explicite avant l'exécution d'une commande de configuration, l'affichage non tronqué de cette commande et des restrictions sur le système de fichiers, le réseau et les privilèges. ^1

Vérifiez l'identité des ressources et des états

Les workflows MCP utilisent parfois des identifiants d'état, par exemple un identifiant de panier, de tâche ou de session longue. Posséder cet identifiant ne doit jamais suffire pour accéder à l'état correspondant.

Le serveur doit relier l'état à l'identité authentifiée, vérifier cette relation à chaque requête et refuser toute utilisation par un autre principal. Les identifiants doivent être difficiles à deviner et expirer lorsque leur durée de vie n'est plus justifiée. ^1

Cette règle s'applique aussi aux ressources métier : un agent autorisé à lire les tickets d'une équipe ne doit pas pouvoir changer l'identifiant reçu dans un paramètre pour consulter ceux d'une autre équipe.

Ne faites jamais confiance à un identifiant fourni par le modèle pour décider de l'utilisateur, du tenant ou du périmètre de données. Ces éléments doivent être dérivés de l'identité vérifiée et des règles côté serveur.

Rendez chaque exécution vérifiable

La traçabilité ne consiste pas à conserver le prompt complet et tous les documents sans limite. Cela créerait un nouveau risque de fuite. Il faut plutôt enregistrer les éléments nécessaires à l'audit, avec une politique de minimisation et de rétention.

Pour une action d'outil, je veux pouvoir retrouver :

• l'identité technique et le périmètre autorisé ;
• le serveur et la version utilisés ;
• le nom de l'outil ;
• les ressources ciblées ;
• les paramètres utiles, avec les secrets et données sensibles masqués ;
• la décision d'approbation ;
• le résultat, le statut et la durée ;
• les erreurs et les relais vers un humain.

Les logs ne doivent pas contenir de jetons, de clés, de codes d'autorisation ni de données sensibles en clair. Ils doivent eux-mêmes être protégés contre une lecture ou une modification non autorisée.

Une trace exploitable sert à trois moments : diagnostiquer un échec, enquêter après un incident et améliorer le jeu de tests. Sans elle, l'équipe ne sait pas si un agent a pris une mauvaise décision, utilisé le mauvais outil ou reçu une donnée compromise.

Un registre d'outils vaut mieux qu'une liste installée au hasard

Pour chaque serveur MCP connecté à l'organisation, maintenez un inventaire qui indique :

• le propriétaire et le responsable de la revue ;
• la source du serveur et sa version approuvée ;
• les outils et ressources exposés ;
• les scopes et comptes utilisés ;
• les environnements autorisés ;
• les données accessibles ;
• la date de dernière vérification ;
• les conditions de retrait ou de rotation des credentials.

Ce registre transforme une intégration invisible en dépendance gouvernée. Il permet aussi de détecter un serveur qui expose progressivement plus de capacités que prévu, ou un outil dont la description a changé après l'approbation initiale.

Une mise à jour d'un serveur ou d'un schéma d'outil doit déclencher une revue proportionnée au risque. L'approbation d'origine ne doit pas être éternelle si le comportement ou les permissions ont changé.

Tester les scénarios qui font peur, pas seulement le chemin nominal

Avant la production, je construis une matrice de tests qui couvre le résultat, la trajectoire et les contrôles de sécurité :

• un utilisateur sans permission tente une lecture ;
• un agent reçoit une demande ambiguë et doit demander une précision ;
• un contenu externe tente une injection ;
• un outil en lecture renvoie une erreur ou une donnée périmée ;
• un appel propose une action sensible sans confirmation ;
• un identifiant d'état appartient à un autre utilisateur ;
• un scope est insuffisant ;
• un jeton possède une mauvaise audience ;
• un serveur ou une ressource devient indisponible ;
• un outil est modifié après son approbation ;
• les logs reçoivent un paramètre contenant un secret.

Pour chaque scénario, définissez le comportement attendu, le signal d'alerte et la personne qui doit intervenir. Un test qui vérifie uniquement que l'agent répond correctement ne couvre pas le risque principal d'un agent outillé.

La checklist avant mise en production

Je ne valide pas une intégration MCP sans pouvoir répondre clairement aux questions suivantes :

• Le serveur est-il identifié, versionné et attribué à un responsable ?
• Les outils nécessaires sont-ils séparés des outils dangereux ou inutiles ?
• Les permissions sont-elles limitées au workflow et aux ressources concernés ?
• Les opérations d'écriture et les actions irréversibles exigent-elles une confirmation adaptée ?
• Les contenus externes sont-ils traités comme non fiables ?
• Les jetons sont-ils destinés au bon service et absents des logs ?
• Le serveur local est-il isolé et exécuté avec peu de privilèges ?
• Les états et identifiants sont-ils liés à l'identité authentifiée ?
• Les appels, décisions et résultats sont-ils auditables sans conserver inutilement des données sensibles ?
• Les tests couvrent-ils les injections, les erreurs de permission, les changements d'outil et les actions interdites ?
• Existe-t-il un bouton d'arrêt, une procédure de révocation et un responsable joignable ?

Si plusieurs réponses sont "non" ou "on ne sait pas", le problème n'est pas qu'il manque une ligne dans le prompt. L'intégration n'a pas encore les garanties nécessaires pour recevoir une vraie responsabilité métier.

FAQ : sécurité d'une intégration MCP

MCP est-il sécurisé par défaut ?

Non. MCP définit un protocole d'échange, mais la sécurité dépend de l'authentification, des permissions, du serveur, de l'environnement d'exécution, des contrôles d'approbation et du système cible. Une intégration doit être conçue et vérifiée selon son niveau de risque.

Peut-on faire confiance à la description d'un outil MCP ?

Pas sans vérifier sa source et son comportement. Une description peut être incomplète, trompeuse ou contenir des instructions destinées au modèle. Les capacités réelles, les effets de bord et les permissions doivent être confirmés côté serveur et dans l'environnement d'exécution.

Faut-il demander une confirmation pour chaque appel d'outil ?

Pas nécessairement. La lecture à faible risque peut être automatisée, tandis que l'écriture sensible, la suppression, l'envoi, le paiement ou le déploiement doivent exiger une validation adaptée. La décision doit dépendre de l'impact de l'action, pas du seul nom de l'outil.

Un serveur MCP local est-il moins risqué qu'un serveur distant ?

Pas automatiquement. Un serveur local peut exécuter du code avec les privilèges du client et accéder aux fichiers ou au réseau de la machine. Un serveur distant introduit d'autres risques, notamment l'authentification, la chaîne de confiance et l'exposition réseau. Les deux nécessitent une isolation et des permissions minimales.

Comment réduire le risque d'injection indirecte ?

Traitez les emails, documents, pages et réponses d'outils comme des données non fiables. Séparez-les des instructions prioritaires, limitez les outils disponibles, bloquez les sorties sensibles et demandez une validation humaine avant les actions à fort impact. Testez ensuite des contenus conçus pour détourner l'agent.

Ce que je recommande, en tant que CTO hands-on

MCP peut accélérer l'intégration d'un agent à un système existant, mais il ne supprime pas les décisions d'architecture. Il les rend plus urgentes, car une capacité découverte par un modèle peut désormais conduire à une action dans un outil réel.

Dans une mission de structuration d'un projet IA et automatisation, je commence par cartographier les outils, les données et les conséquences avant de choisir le protocole ou le framework. Un audit technique permet ensuite de vérifier les permissions, l'isolation, les traces et les points de coupure sur une intégration déjà en place.

Un agent n'est pas prêt pour la production parce qu'il sait appeler un outil. Il l'est lorsque ses capacités sont limitées, ses actions compréhensibles, ses erreurs observables et sa révocation immédiate.

Sources et références

• Model Context Protocol, Security Best Practices
• Model Context Protocol, Understanding Authorization in MCP
• OWASP GenAI Security Project, A Practical Guide for Securely Using Third-Party MCP Servers
• Anthropic, Trustworthy agents in practice