Les serveurs MCP permettent aux modèles d’IA d’agir au sein de vos systèmes, ce qui transforme l’empoisonnement d’outils, l’injection de prompts et les tokens divulgués en risques réels. Découvrez les sept menaces qui comptent, une checklist de 20 points sur l’accès, le durcissement et les flux de données, ainsi qu’une routine d’audit réalisable en un après-midi.
Un serveur MCP est une porte sur vos systèmes, qu’un modèle d’IA ouvre de lui-même. Dès qu’un client, comme un assistant conversationnel ou un éditeur de code, se connecte, le modèle peut lire des fichiers, interroger des bases de données, appeler des API internes et envoyer des messages, généralement avec les droits de la personne qui a installé le serveur. C’est pourquoi les bonnes pratiques de sécurité MCP doivent figurer dans le premier sprint, et non dans le rapport post-incident. Cet article recense les risques qui se manifestent réellement en production, propose une checklist de 20 points que vous pouvez coller dans un ticket, et détaille un audit que votre équipe peut terminer en un après-midi.
En bref, si vous êtes pressé : traitez chaque description d’outil comme une entrée non fiable, accordez à chaque serveur le plus petit jeu de permissions qui fonctionne, gardez les secrets hors de portée du modèle et journalisez chaque appel d’outil pour pouvoir rejouer ce qui s’est passé.
La sécurité d’API classique suppose qu’un développeur a écrit le code qui appelle votre point d’accès. MCP remet cette hypothèse en cause. Le Model Context Protocol permet à un modèle de langage de choisir ses outils à l’exécution, en se fondant sur le texte qu’il lit. Or un texte peut être falsifié, et le modèle ne peut pas toujours distinguer une instruction légitime d’une instruction malveillante glissée dans le contenu. Voilà pourquoi la sécurité des serveurs MCP est un problème différent du verrouillage d’une API REST.
Dans une intégration classique, un humain relit le chemin du code avant sa mise en production. Avec MCP, l’appelant est un système probabiliste qui lit les noms, descriptions et résultats des outils comme une partie de son prompt. Une phrase cachée dans une description d’outil a presque le même poids qu’une phrase de votre propre prompt système. Ce seul fait explique la plupart des incidents MCP.
Cela change aussi la définition de l’attaquant. Vous n’avez pas besoin d’accéder au serveur. Quiconque peut placer du texte devant le modèle peut tenter de le manipuler : l’auteur d’une page web, un client qui ouvre un ticket de support, un inconnu qui signale un problème sur un dépôt public. Une bonne sécurité des agents d’IA commence par admettre que le canal d’entrée est ouvert à tous.
Tracez quatre frontières avant d’écrire la moindre ligne de configuration :
| Frontière | Ce qui la traverse | En qui vous avez confiance |
|---|---|---|
| Utilisateur vers client | Prompts et validations | L’utilisateur connecté |
| Client vers serveur | Appels d’outils et résultats | Uniquement les serveurs que vous avez évalués |
| Serveur vers backend | Requêtes, fichiers, appels d’API | Une identité de service limitée |
| Serveur vers internet | Pages récupérées, webhooks | Personne |
Le transport compte aussi. Un serveur local lancé via stdio est un processus qui tourne sur la machine de l’utilisateur avec ses droits, si bien qu’un paquet malveillant équivaut à une exécution de code arbitraire. Un serveur distant en HTTP ajoute une exposition réseau, une authentification et une gestion de session. Chaque transport a son propre modèle de menace, et un serveur qui propose les deux demande deux revues.
💡 Astuce : La configuration la plus risquée est celle d’un agent qui peut lire des données privées, lire du contenu non fiable et envoyer des données vers l’extérieur. Les chercheurs en sécurité appellent cette combinaison la « trifecta létale ». Supprimez au moins un de ces trois éléments et la plupart des voies d’exfiltration se referment.
Toutes les menaces ne méritent pas la même attention. Ces sept-là reviennent sans cesse dans les recherches publiques sur MCP et dans les rapports d’incidents, et chacun correspond à des éléments de la checklist plus bas.
| N° | Risque | Ce qui se passe | Impact typique |
|---|---|---|---|
| 1 | Injection de prompt | Le modèle suit des instructions cachées dans une page, un ticket ou un fichier | Fuite de données, actions non voulues |
| 2 | Empoisonnement d’outils | Des instructions malveillantes sont insérées dans les descriptions d’outils | Vol de données silencieux |
| 3 | Rug pull | Un serveur modifie ses outils après que vous les avez approuvés | Approuvé ne veut pas dire actuel |
| 4 | Identifiants divulgués | Des jetons se retrouvent dans des configurations, des journaux ou le contexte du modèle | Prise de contrôle de compte |
| 5 | Permissions excessives | Un serveur fonctionne avec un périmètre administrateur | Une seule erreur devient une faille de sécurité |
| 6 | Transmission de jetons | Un serveur retransmet des jetons qui ne lui ont pas été délivrés | Accès au-delà de l’intention |
| 7 | Chaîne d’approvisionnement | Des paquets de serveurs usurpés ou piégés | Du code s’exécute sur votre machine |
L’injection de prompt est le risque principal, car elle ne nécessite aucun code d’exploitation. En 2025, des chercheurs ont montré qu’une intégration GitHub pouvait être orientée, par une issue malveillante publiée sur un dépôt public, vers la lecture de dépôts privés puis la publication de leur contenu. Le modèle a fait exactement ce qu’on lui demandait. La requête venait simplement d’un attaquant.
Défenses efficaces :
L’empoisonnement d’outils dissimule des instructions dans la description ou le schéma d’un outil. Vous voyez un outil anodin qui « additionne deux nombres ». Le modèle voit un paragraphe supplémentaire lui demandant de lire un fichier d’identifiants et de transmettre son contenu en paramètre. Le rug pull est la version lente : le serveur se comporte correctement pendant la revue, puis modifie discrètement ses définitions d’outils après votre approbation.
La solution est simple et efficace. Calculez un hash du manifeste complet des outils (noms, descriptions et schémas) au moment de l’approbation, comparez-le à chaque connexion et refusez de fonctionner si le hash change. Montrez aux utilisateurs la description complète, pas un résumé raccourci.
La chaîne d’approvisionnement mérite sa propre ligne. En 2025, un serveur de messagerie usurpé publié sur npm aurait copié les messages sortants vers une adresse extérieure après une mise à jour de routine. L’épinglage des versions et une liste d’autorisation (éléments 9 et 10 de la checklist) constituent la défense.
Les secrets fuient de façons peu spectaculaires : un jeton collé dans un fichier de configuration qui finit dans un commit, une variable d’environnement affichée dans un journal de débogage, un mot de passe de base de données renvoyé dans un résultat d’outil et désormais présent dans le contexte du modèle pour le reste de la session. Dès qu’un secret entre dans le contexte, toute injection ultérieure peut demander au modèle de le répéter.
Stockez les secrets dans un coffre-fort ou dans le gestionnaire d’identifiants de votre système d’exploitation, transmettez-les au processus du serveur au démarrage et ne les renvoyez jamais dans une sortie. Privilégiez des jetons à courte durée de vie, qui expirent en quelques minutes : un jeton volé qui meurt à l’heure du déjeuner ne pose qu’un petit problème.
Un serveur qui « a seulement besoin de lire les tickets » est souvent livré avec un jeton administrateur, parce que c’était le chemin le plus rapide pour une démonstration. Une seule instruction injectée peut alors fermer des tickets, exporter des listes de clients ou modifier des paramètres. Les permissions déterminent le rayon d’impact, et vous en fixez la taille dès le premier jour.
Appliquez le moindre privilège au verbe le plus restreint : lecture plutôt qu’écriture, un projet plutôt que tout l’espace de travail, une table plutôt que la base entière. Lorsqu’un éditeur ne propose qu’un jeton du type tout ou rien, placez devant lui un serveur proxy léger qui n’expose que les appels que vous acceptez.
Collez-la dans votre outil de suivi et notez chaque serveur selon cette grille. Tout point que vous ne pouvez pas cocher aujourd’hui devient un ticket avec un responsable et une échéance.
💡 Astuce : Les éléments 5, 11 et 17 sont les moins coûteux à mettre en œuvre et ferment les voies les plus dangereuses : actions non approuvées, modifications silencieuses des outils et données qui quittent le réseau. Si votre semaine est courte, commencez par là.
Un audit répond à une seule question : que peut faire le modèle actuellement, et qui l’a approuvé ? Réservez un après-midi, invitez un ingénieur et un responsable de la sécurité, et travaillez en trois passes. Avant la première passe, rédigez une modélisation des menaces d’une page avec quatre réponses : à quelles données l’agent peut-il accéder, quel contenu non fiable lit-il, où peut-il envoyer des données et quelles actions sont irréversibles.
On ne protège pas ce que l’on ne peut pas lister. Recensez les serveurs à partir des fichiers de configuration des clients, des paramètres des IDE, des dépôts partagés de l’équipe, des pipelines CI et des installations « temporaires » qui n’ont jamais été supprimées. Notez pour chacun :
| Champ | Exemple |
|---|---|
| Nom et source | Paquet d’un éditeur, dépôt interne ou projet communautaire |
| Transport | stdio local ou HTTP distant |
| Identité utilisée | Compte de service, jeton personnel ou aucune |
| Périmètres accordés | Lire les tickets, écrire des fichiers, administrateur |
| Données accessibles | Fiches clients, code source, web public |
| Responsable | Une personne nommée, pas un alias d’équipe |
Attendez-vous à des surprises. Les équipes trouvent régulièrement des serveurs que personne ne se souvient avoir installés, fonctionnant avec un jeton administrateur personnel.
Extrayez trente jours d’appels d’outils et recherchez les schémas qui ne devraient pas exister : appels à des heures inhabituelles, résultats anormalement volumineux, outils invoqués juste après la lecture d’une page externe, et arguments contenant des chemins de fichiers ou des URL que l’utilisateur n’a jamais mentionnés. Pour un tri à grande échelle, un modèle comme Claude Sonnet 5 peut regrouper des milliers d’appels en une courte liste d’anomalies, à condition de caviarder les secrets et les données personnelles avant d’envoyer quoi que ce soit.
Attribuez à chaque constat une gravité et une échéance. Gardez une échelle réduite pour que les équipes l’utilisent vraiment :
| Gravité | Exemple de constat | Délai de correction |
|---|---|---|
| Critique | Jeton administrateur dans un fichier de configuration partagé | 24 heures |
| Élevée | Aucune étape de validation pour les e-mails sortants | 1 semaine |
| Moyenne | Version de serveur non épinglée | 30 jours |
| Faible | Aucun responsable sur un serveur de test | Prochaine revue |
Relancez l’audit après chaque changement majeur et au moins une fois par trimestre. Une liste de serveurs propre en janvier est rarement propre en juin.
La prévention finit par échouer un jour, il faut donc prévoir le jour où cela arrivera. L’objectif est de détecter en quelques minutes et de contenir en moins d’une heure.
Journalisez assez pour reconstituer une session sans stocker de secrets. Capturez l’utilisateur, le client, le serveur, le nom de l’outil, un hash des arguments, la taille du résultat, la latence et la décision de validation. Commencez par alerter sur trois signaux : une rafale d’appels vers un même outil, tout appel vers un outil jamais utilisé auparavant, et de gros résultats peu après que l’agent a récupéré un contenu externe.
Chaque serveur doit disposer d’un interrupteur d’arrêt qu’une seule personne peut actionner sans déploiement. Révoquez ses jetons, retirez-le de la liste d’autorisation et renouvelez tout secret qu’il a touché. Restaurez ensuite le dernier hash de manifeste connu comme fiable. Pratiquez cette opération une fois par trimestre, afin que la première tentative réelle ne soit pas aussi la première répétition.
💡 Un plafond côté plateforme est également utile. PicassoIA, par exemple, limite chaque compte à 5 prédictions simultanées sur l’ensemble des connexions, ce qui empêche un agent incontrôlé de saturer la file d’attente. Demandez à vos propres fournisseurs quels sont leurs plafonds.
Un classificateur de sécurité ne remplace ni les permissions ni les validations, mais il ajoute un filtre utile. Llama Guard 4 12B lit du texte ou des images et renvoie un verdict sûr ou non sûr, accompagné de la catégorie de risque correspondante, couvrant des domaines comme la violence, la haine et les instructions dangereuses. Ce n’est pas un détecteur dédié à l’injection de prompt : utilisez-le donc comme une couche parmi les contrôles ci-dessus, par exemple pour filtrer ce que soumettent les utilisateurs et ce que votre agent s’apprête à renvoyer.
| Paramètre | Valeur suggérée | Pourquoi |
|---|---|---|
| Temperature | 0 | Même entrée, même verdict |
| Max Completion Tokens | 64 à 128 | Un verdict est court |
| System Prompt | Politique et format de sortie strict | Facile à analyser dans le code |
| Top P | 1 (par défaut) | À laisser tel quel lorsque la temperature vaut 0 |
| Image Input | Captures d’écran à vérifier | Facultatif |
Le travail de sécurité reste largement invisible, ce qui le rend difficile à expliquer. De bons visuels aident : une image d’en-tête pour un runbook, une illustration de scénario pour une diapositive de formation, une allée de centre de données pour le wiki interne. PicassoIA transforme un prompt textuel en images photoréalistes et en courtes vidéos, sans logiciel de design et sans licence de photos de banques d’images à suivre.
Essayez avec le sujet que vous venez de lire. Décrivez une scène comme « un ingénieur en sécurité examinant une checklist imprimée dans une salle de serveurs silencieuse, lumière douce d’une fenêtre, objectif 35 mm », lancez la génération, puis ajustez l’angle, l’éclairage et l’objectif jusqu’à ce que l’image convienne à votre document. Ouvrez PicassoIA, parcourez la liste complète des modèles et testez dès aujourd’hui vos propres prompts.
Choisissez votre langue
