MCP est-il sûr à utiliser ? Cela dépend des serveurs que vous installez, des autorisations que vous accordez et du contenu que votre agent lit. Cet article présente de véritables incidents liés à MCP, un tableau des risques, une liste de contrôle de sécurité imprimable et une méthode pratique pour filtrer les textes et repérer les contenus dangereux.
Réponse courte : oui, à condition de traiter chaque serveur comme un logiciel capable d’agir en votre nom. Alors, MCP est-il sûr à utiliser ? Le Model Context Protocol est un simple standard de messagerie. Il transporte les requêtes entre une application d’IA et un outil, mais il ne décide pas de ce que cet outil a le droit de toucher. Le risque se situe à trois endroits : les serveurs que vous installez, les autorisations que vous leur accordez et le contenu que votre agent lit en chemin. Si vous maîtrisez ces trois points, MCP est un moyen raisonnable de connecter un modèle à des fichiers, à des bases de données et à des services web. Si vous les négligez, une seule description d’outil empoisonnée peut envoyer un dépôt privé à un inconnu.
Cet article présente les véritables risques liés aux serveurs MCP, nomme les incidents qui se sont réellement produits et se termine par une vérification de sécurité que vous pouvez effectuer en une dizaine de minutes. Pas de catastrophisme ni de battage médiatique, seulement les modes de défaillance et les solutions.
MCP est un standard ouvert présenté par Anthropic fin 2024 pour que les applications d’IA dialoguent avec des outils externes de manière cohérente. Auparavant, chaque intégration reposait sur du code de liaison sur mesure. Désormais, une application parle un seul protocole, et un serveur expose des outils (actions, comme l’exécution d’une requête), des ressources (données, comme un fichier) et des prompts (modèles réutilisables). Les messages circulent en JSON-RPC, soit par un canal local (stdio), soit en HTTP.
Cette simplicité est à la fois une bonne et une mauvaise nouvelle. Un standard facilite l’intégration, mais il facilite aussi le branchement de quelque chose que vous n’avez jamais vérifié. Le protocole lui-même ne se prononce pas sur la confiance qu’un serveur mérite. Ce jugement vous revient.
Trois rôles apparaissent dans toutes les configurations :
Le modèle ne parle jamais directement à votre base de données. Il demande à l’hôte d’appeler un outil, le client transmet la requête, et le serveur fait le travail avec l’accès qui lui a été donné. Cette dernière partie est la plus importante. Un serveur n’est aussi sûr que l’accès qui se trouve derrière lui.
L’emplacement d’un serveur modifie fortement le modèle de menace. Un serveur local est un processus sur votre propre machine, lancé par votre hôte. Un serveur distant est un service hébergé auquel vous accédez via Internet.
| Serveur local (stdio) | Serveur distant (HTTP) | |
|---|---|---|
| Fonctionne sur | Votre propre machine | L’infrastructure de quelqu’un d’autre |
| Le code s’exécute avec | Vos autorisations d’utilisateur | Les autorisations de l’éditeur |
| Risque principal | Un paquet malveillant s’exécute sur votre ordinateur portable | Vos données et vos jetons transitent vers un tiers |
| Question de confiance | Qui l’a écrit, et la version est-elle figée ? | Qui l’exploite, et que journalise-t-il ? |
| Meilleure défense | Bac à sable, versions figées, accès en lecture seule | Jetons OAuth limités et vérification de l’éditeur |
💡 Règle empirique : un serveur local est un programme que vous exécutez, traitez-le donc comme n’importe quel téléchargement. Un serveur distant est un service à qui vous confiez des données, traitez-le donc comme n’importe quel prestataire.
La plupart des incidents liés à MCP n’ont rien d’exotique. Ils suivent quelques schémas récurrents, et chacun d’eux s’est déjà produit dans la nature. À la base de tous ces schémas se trouve un fait gênant : un modèle de langage lit les instructions et les données comme un même flux de texte : il ne peut donc pas distinguer de façon fiable une commande d’un commentaire.
Chaque outil est livré avec une description, et le modèle lit ce texte comme une consigne. Les utilisateurs la voient rarement. En 2025, des chercheurs d’Invariant Labs ont démontré qu’une description malveillante pouvait contenir des commandes cachées, par exemple demander à l’agent de lire un fichier d’identifiants local et de transmettre son contenu dans un appel d’apparence banale.
L’enveloppe ci-dessus illustre bien le propos : le colis paraît anodin, mais la note à l’intérieur change la suite des événements. Lire la définition complète de l’outil, et pas seulement son nom, constitue la première défense.
Votre agent ne suit pas seulement vos instructions. Il lit aussi des tickets, des courriels, des pages web et des documents, et chacun peut contenir des instructions destinées au modèle. Dans l’incident GitHub MCP, des attaquants ont placé des prompts malveillants dans des Issues et des pull requests publiques. Un agent ayant accès à des dépôts privés a été trompé et a divulgué du code privé dans une pull request publique.
💡 Le trio à risque : le chercheur en sécurité Simon Willison décrit une combinaison à éviter : l’accès à des données privées, l’exposition à du contenu non fiable et un moyen d’envoyer des données vers l’extérieur. Lorsqu’un même agent réunit les trois, une seule phrase injectée suffit. Retirez l’un d’eux et l’attaque ne tient plus.
Trois autres schémas proviennent des problèmes classiques de la chaîne d’approvisionnement logicielle :
| Risque | Fonctionnement | Exemple réel | Première défense |
|---|---|---|---|
| Empoisonnement d’outils | Instructions cachées dans une description d’outil | Démonstrations d’Invariant Labs, 2025 | Lire les définitions complètes, figer les versions |
| Injection de prompt | Instructions cachées dans le contenu lu par l’agent | Fuite de dépôt privé via GitHub MCP | Séparer les données privées des entrées non fiables |
| Serveur malveillant | Porte dérobée dans un paquet installé | postmark-mcp, septembre 2025 | Privilégier des serveurs audités et maintenus |
| Rug pull | Définitions modifiées après approbation | Schéma signalé par des chercheurs | Figer les versions, réexaminer à chaque mise à jour |
| Bogue client | Injection de commandes via un serveur hostile | CVE-2025-6514 dans mcp-remote | Corriger rapidement, ne se connecter qu’à des serveurs de confiance |
Quand quelque chose tourne mal, ce sont les autorisations qui fixent l’ampleur de la perte. Une description empoisonnée n’est qu’une gêne lorsque l’agent ne peut lire qu’un dossier. Elle devient un désastre lorsque l’agent dispose d’un jeton administrateur.
Accordez à chaque serveur la plus petite part d’accès qui lui permet de faire son travail :
💡 Posez-vous une question pour chaque outil : « Si cet appel était malveillant, quel est le pire qu’il pourrait faire ? » Si la réponse vous fait grimacer, réduisez l’autorisation.
Les identifiants n’ont pas leur place dans les messages de discussion, les arguments d’outils ou les fichiers de configuration versionnés dans Git. Chargez-les depuis des variables d’environnement ou un gestionnaire de secrets, privilégiez les jetons à courte durée de vie et renouvelez tout ce qui a déjà figuré dans un journal. Vérifiez vos fichiers de configuration MCP avant chaque commit, car ils sont une cachette favorite des jetons collés lors d’un test rapide.
Un serveur MCP distant conserve vos données sur la machine de quelqu’un d’autre. Les contrôles d’identité comptent donc bien davantage que pour un processus local.
La spécification d’autorisation MCP de juin 2025 classe les serveurs MCP comme des serveurs de ressources OAuth 2.0. Les clients incluent un paramètre resource (RFC 8707) lorsqu’ils demandent des jetons, ce qui lie chaque jeton d’accès à un serveur précis. Un jeton émis pour le serveur A ne devrait pas servir sur le serveur B, et un serveur doit rejeter tout jeton qui ne lui a pas été émis.
Les mêmes documents mettent en garde contre le passage de jeton (token passthrough), par lequel un serveur transmet le jeton reçu à une API en aval. Cela casse les pistes d’audit, brouille les responsabilités et favorise le problème du « député confus », où un serveur de confiance est amené à utiliser son autorité au profit d’un attaquant.
La spécification des outils ajoute une règle qui mérite d’être répétée : un humain doit toujours rester dans la boucle et avoir la possibilité de refuser les appels d’outils. La plupart des hôtes l’implémentent sous forme de demande d’approbation. Ne cliquez pas dessus en pilote automatique.
Parcourez cette liste avant d’ajouter un serveur à votre configuration.
Journalisez chaque appel d’outil avec ses arguments, l’heure et l’identité qui le porte. Quand quelque chose semble anormal, vous voudrez reconstituer ce que l’agent a lu et ce qu’il a envoyé. Examinez le journal chaque semaine, à la manière dont une équipe passe en revue les rapports d’accès.
Surveillez quatre signaux d’alerte :
Partez du principe qu’un serveur finira par mal se comporter, puis limitez ce que cela peut vous coûter.
Une boîte à gants permet à un technicien de manipuler un échantillon dangereux sans le toucher. Les conteneurs remplissent le même rôle pour les logiciels. Exécutez les serveurs locaux dans un conteneur ou un compte utilisateur restreint, montez uniquement les dossiers dont ils ont besoin, bloquez l’accès réseau sortant lorsque l’outil ne l’exige pas, et gardez les secrets hors de l’image. Si un serveur devient hostile, il brise une vitre de boîte à gants au lieu de votre ordinateur portable.
Les demandes d’approbation ne fonctionnent que si les gens les lisent. Les équipes qui approuvent tout par réflexe ne disposent d’aucune protection. Répartissez les outils selon leur risque :
| Type d’outil | Exemple | Politique d’approbation |
|---|---|---|
| Lecture seule, risque faible | Rechercher sur un site de documentation, lire un fichier de projet | Autoriser automatiquement |
| Écriture de données | Modifier un fichier, créer un ticket | Demander une fois par session |
| Envoi de données vers l’extérieur | Courriel, publication sur un webhook, import | Demander à chaque fois |
| Destructif ou coûteux | Supprimer, déployer, dépenser de l’argent | Demander à chaque fois, avec un aperçu |
Gardez la liste des approbations automatiques courte et réexaminez-la chaque fois qu’un serveur est mis à jour.
Le filtrage de contenu constitue une couche supplémentaire, et non un substitut aux autorisations. Llama Guard 4 12B est un modèle de sécurité multimodal disponible sur PicassoIA. Il classe les textes et les images comme sûrs ou dangereux et indique la catégorie de préjudice lorsqu’il signale un contenu. Vous pouvez l’utiliser pour vérifier une page web, un courriel ou le résultat d’un outil avant que votre agent n’agisse, ou pour tester si le brouillon de réponse d’un agent serait signalé avant d’atteindre un utilisateur.
💡 Soyez réaliste quant à ses limites. Llama Guard 4 12B est un classifieur de sécurité du contenu qui vérifie des catégories de préjudice comme la violence, les discours haineux et les instructions dangereuses. Ce n’est pas un pare-feu dédié à l’injection de prompt. Utilisez-le avec les contrôles ci-dessus, et jamais à leur place.
Vous obtenez une étiquette sûr ou dangereux, ainsi que la catégorie correspondante lorsque le contenu est dangereux. Considérez « dangereux » comme un panneau stop : retenez le contenu et montrez-le à une personne. Considérez « sûr » comme un indice parmi d’autres, et non comme un blanc-seing. Si vous constatez de fausses alertes, précisez le system prompt avec des exemples de ce que votre équipe juge acceptable.
Pour le tri, associez le verdict à un modèle de raisonnement performant comme Claude Sonnet 5 ou GPT 5.6 Sol afin de résumer les éléments signalés. Exécutez-les sans aucun accès aux outils, pour qu’un extrait hostile n’ait rien sur quoi agir.
Les bonnes habitudes sont plus faciles à conserver lorsqu’on s’entraîne sur des projets où rien de sensible n’est en jeu. La génération d’images et de vidéos constitue un bon terrain d’entraînement. PicassoIA Image transforme un prompt en langage courant en image finie en quelques secondes, et Picasso IA Video génère des clips de 5 secondes à une fréquence d’images de 24 fps avec un son synchronisé, à partir d’un texte ou d’une image de départ, en 480p ou en 720p.
PicassoIA propose aussi une API pour développeurs et une connexion MCP pour la génération d’images et de vidéos, et les mêmes règles s’appliquent : créez un identifiant pour un seul projet, conservez-le comme un secret et surveillez votre consommation. Chaque compte est limité à 5 prédictions simultanées, partagées entre les identifiants API et les connexions MCP, ce qui sert aussi de frein si un agent se retrouve bloqué dans une boucle.
Ouvrez PicassoIA, rédigez un prompt et appliquez la liste de contrôle sur un projet sans grand enjeu pour commencer. Générez quelques images, animez votre préférée en un court clip et passez un paragraphe dans Llama Guard 4 12B pour voir à quoi ressemble un verdict. Ensuite, appliquez ces mêmes habitudes aux serveurs qui comptent vraiment.
Choisissez votre langue
