Qu'est-ce qu'un serveur MCP, et pourquoi l'auditer en production ?
Un agent IA devient utile quand il peut agir sur des systèmes réels : lire un CRM, écrire dans une base, interroger un outil interne. Le Model Context Protocol est un standard ouvert conçu pour établir ces connexions, et c'est pourquoi il appelle un audit propre dès qu'il quitte l'environnement de test.
Le Model Context Protocol (MCP) est un standard ouvert publié par Anthropic en novembre 2024, qui définit comment un agent découvre et appelle les outils exposés par un serveur relié à un système tiers. Auditer un serveur MCP en production revient à vérifier ce que son accès autorise réellement, qui l'a fourni et quelle trace il laisse.
Depuis décembre 2025, le protocole est confié à l'Agentic AI Foundation, un fonds de la Linux Foundation cofondé par Anthropic, Block et OpenAI. La spécification en vigueur, datée du 28 juillet 2026, pose elle-même un cadre de sécurité : les outils représentent une exécution de code arbitraire, les descriptions de leur comportement doivent être tenues pour non fiables sauf si elles viennent d'un serveur de confiance, et l'application hôte doit obtenir le consentement explicite de l'utilisateur avant d'invoquer un outil. La spécification reconnaît qu'elle ne peut imposer ces principes au niveau du protocole. Leur application dépend des implémentations, application hôte, client et serveur, et de la façon dont l'entreprise qui les déploie les configure.
Dresser l'inventaire avant d'auditer
Un audit commence par une question simple : quels serveurs MCP sont branchés sur vos agents en production, et par qui ? Les connecteurs s'ajoutent projet par projet, et l'inventaire est rarement tenu au même endroit que les agents qui les utilisent.
Ce que l'inventaire doit contenir
Pour chaque serveur, l'inventaire note les agents qui l'appellent, le système qu'il atteint, les outils qu'il expose, le compte ou le jeton avec lequel il agit, son mode de transport (local ou distant), son origine et la date de sa dernière revue. Ce tableau révèle vite les premiers écarts entre les droits accordés et l'usage réel. Nous conseillons de le tenir dans le registre des agents lui-même, pour qu'aucun connecteur ne passe en production sans y figurer.
Serveur interne ou serveur tiers
Un serveur développé en interne, dont le code reste lisible par vos équipes, porte un risque différent d'un serveur tiers publié par un éditeur externe et exécuté sans revue. Avec le second, une partie de la sécurité de votre agent repose sur la rigueur d'une équipe que vous ne contrôlez pas. Le Top 10 de l'OWASP pour les applications agentiques, publié en décembre 2025, range ce risque sous l'entrée ASI04, consacrée aux vulnérabilités de la chaîne d'approvisionnement des agents, qui couvre les outils, frameworks et registres tiers. Pour un serveur interne, la revue porte sur le code. Pour un serveur tiers, elle porte sur l'éditeur, l'historique de ses mises à jour et sa façon de traiter les vulnérabilités signalées.
Autorisations : ce que la spécification MCP exige
Pour les serveurs distants, joints en HTTP, la spécification fonde l'autorisation sur OAuth 2.1. L'autorisation reste optionnelle dans le protocole, et c'est le premier point à contrôler : un serveur distant sans autorisation qui touche un système de production est un écart à corriger. Pour les serveurs locaux, qui dialoguent par l'entrée et la sortie standard, la spécification recommande de récupérer les identifiants depuis l'environnement d'exécution.
Des jetons émis pour un seul serveur
La spécification impose au client d'indiquer, à chaque demande de jeton, le serveur auquel ce jeton est destiné (indicateurs de ressource, RFC 8707), et au serveur de vérifier qu'un jeton lui a bien été émis. Elle interdit aussi le relais de jetons, le « token passthrough » : un serveur MCP n'accepte aucun jeton émis pour un autre service et ne le transmet jamais tel quel à une API en aval. Le guide de sécurité du protocole en donne la raison : un serveur qui relaie des jetons brouille la traçabilité et peut servir de relais à un attaquant muni d'un jeton volé.
Des scopes minimaux, élargis au besoin
Le même guide consacre une section à la minimisation des scopes. Il recommande un jeu de départ limité aux opérations de lecture et de découverte, puis une élévation ciblée quand une opération privilégiée est tentée pour la première fois. Il liste aussi les erreurs courantes, comme publier tous les scopes possibles, utiliser des scopes génériques du type « * » ou « full-access », ou regrouper des privilèges sans rapport pour éviter de futures demandes. Un jeton trop large, une fois volé, ouvre tout ce qu'il couvre, et sa révocation interrompt tous les usages à la fois.
La surface d'attaque propre aux serveurs MCP
Un serveur MCP mal configuré élargit la surface d'attaque de tout le système auquel il est relié, souvent sans que les équipes qui observent l'agent examinent la couche de connexion qui le porte.
Des descriptions d'outils à traiter comme non fiables
Un agent choisit l'outil à appeler à partir de son nom et de sa description. Une description rédigée, ou modifiée après coup, pour orienter l'agent vers une action qu'un opérateur aurait refusée devient un vecteur d'injection. D'où la consigne de la spécification de tenir ces descriptions pour non fiables, sauf si elles proviennent d'un serveur de confiance. Le Top 10 agentique de l'OWASP range l'empoisonnement de descriptions d'outils et les serveurs MCP malveillants parmi les vulnérabilités de la chaîne d'approvisionnement (ASI04). L'audit vérifie donc qui peut modifier les descriptions d'un serveur, et si un changement de description déclenche une nouvelle revue. Pour un serveur installé depuis un paquet, épingler la version fige aussi ses descriptions. Un serveur distant peut en revanche modifier ses outils sans changer de version, et nous recommandons alors de contrôler ses descriptions à chaque connexion.
La compromission d'un serveur local
Un serveur local est un programme exécuté sur la machine, avec les droits de l'utilisateur ou du processus qui le lance. Le guide de sécurité du protocole traite sa compromission comme un risque distinct : commande de démarrage malveillante glissée dans une configuration, charge malveillante dans le serveur lui-même, serveur local laissé accessible à d'autres processus. Il recommande d'afficher la commande exacte avant exécution, d'exiger une approbation explicite et d'exécuter ces serveurs dans un environnement cloisonné aux privilèges minimaux. Un serveur local installé sans relecture présente les risques de n'importe quel paquet logiciel non vérifié.
Les données qui transitent par un serveur tiers
Chaque appel d'outil fait transiter des données, en entrée comme en sortie, par le serveur qui l'exécute. Quand ce serveur est hébergé par un tiers, ces données quittent votre périmètre, même si le résultat final reste chez vous. Pour une organisation en secteur régulé, la question se pose avant le déploiement : quelles données passent par ce serveur, où elles sont traitées et combien de temps l'hébergeur les conserve. La réponse conditionne la conformité RGPD du traitement, et si l'hébergeur traite des données hors de l'Espace économique européen, les règles du RGPD sur les transferts internationaux s'appliquent aussi.
Isolation et journalisation
Réduire les permissions ne suffit pas si le serveur tourne dans le même environnement que les systèmes qu'il connecte. L'isolation borne ce qu'un serveur compromis peut atteindre, et la journalisation permet de reconstituer ce qu'il a fait.
Cloisonner chaque serveur
L'isolation consiste à exécuter chaque serveur dans un environnement séparé, avec ses propres identifiants, un accès réseau et un système de fichiers restreints. Un serveur compromis dans un environnement isolé reste un incident circonscrit, alors que le même serveur exécuté avec les droits du reste de l'infrastructure ouvre la voie à une compromission plus large. L'isolation vaut aussi entre serveurs : quand un agent combine un connecteur CRM, un connecteur de messagerie et un outil métier, aucun ne doit pouvoir lire les identifiants d'un autre. En pratique, cela signifie un conteneur ou un environnement d'exécution dédié par serveur, avec un accès réseau sortant limité au système qu'il dessert.
Journaliser chaque appel d'outil
Un audit sans journal des appels d'outils se résume à une photographie de la configuration à un instant donné. Le journal conserve, pour chaque appel, l'outil sollicité, les paramètres transmis, l'identité au nom de laquelle l'agent agissait et le résultat renvoyé. Le guide de sécurité du protocole recommande aussi de journaliser les élévations de scope. Pour les systèmes à haut risque, l'article 12 de l'AI Act exige qu'ils permettent techniquement l'enregistrement automatique des événements, une obligation que l'Omnibus IA, le règlement (UE) 2026/1744, a reportée au 2 décembre 2027 pour les usages de l'annexe III. Un journal des appels MCP tenu dès maintenant alimente cette preuve, comme celle attendue dans un audit ISO 42001. Notre page sur la conformité AI Act en entreprise détaille le calendrier.
La checklist d'audit MCP
La liste qui suit se déroule serveur par serveur, pour chaque agent en production.
- Inventaire : serveur recensé, agents qui l'appellent, système atteint, propriétaire désigné.
- Provenance : éditeur identifiable, code relu ou politique de sécurité publiée, version épinglée pour un serveur installé en paquet, descriptions contrôlées à chaque connexion pour un serveur distant.
- Autorisation : OAuth 2.1 pour tout serveur distant relié à un système de production, jetons émis pour ce seul serveur, aucun relais de jeton.
- Scopes : jeu minimal au départ, élévations journalisées, aucun scope générique.
- Outils exposés : chaque outil correspond à une tâche documentée, les outils inutilisés sont retirés.
- Descriptions d'outils : origine connue, toute modification déclenche une revue.
- Isolation : environnement séparé, identifiants dédiés, accès réseau et fichiers restreints.
- Données : flux cartographiés, localisation et durée de conservation connues pour tout serveur tiers.
- Journalisation : chaque appel tracé, journal hors de portée de l'agent et consulté régulièrement.
- Revue : date de la dernière revue, déclencheurs de revue hors calendrier définis.
Une revue périodique complète cette liste. Nous recommandons un rythme plus serré pour les serveurs reliés à des systèmes financiers, RH ou de santé, et une revue immédiate à chaque changement de périmètre de l'agent, qui prime sur le calendrier.
Où situer l'audit MCP dans la gouvernance LOOP™
La gouvernance LOOP™ classe chaque action possible d'un agent dans une zone de confiance : verte pour l'exécution autonome, orange pour une validation humaine avant exécution, rouge pour une escalade obligatoire vers un responsable désigné, noire pour un blocage immédiat avec alerte RSSI. La zone se définit action par action, y compris pour les actions qu'ouvre un même serveur. Un connecteur qui ouvre une écriture sur un système sensible oblige à classer chacune des actions qu'il rend possibles, sans les laisser hériter par défaut du classement de l'agent.
Le registre vivant de LOOP™ documente pour chaque agent les données accédées et leur classification, le périmètre des actions autorisées et interdites, validé par le RSSI, ainsi que l'historique des audits. Un audit MCP alimente directement ces rubriques. Notre article sur les zones de confiance pour classifier ses agents IA détaille la méthode de classement.
Par où commencer pour auditer vos serveurs MCP
Selon Deloitte (State of AI in the Enterprise, édition 2026), seules 21 % des organisations disposent d'un modèle de gouvernance mature pour leurs agents autonomes. MCP multiplie les connecteurs vers des systèmes tiers et élargit d'autant la surface que cette gouvernance doit couvrir. Le premier geste utile reste l'inventaire décrit plus haut, suivi de la revue des autorisations des serveurs qui écrivent dans un système de référence, là où une erreur a le plus d'impact.
Aller plus loin
L'audit MCP forme un chapitre de notre guide pour sécuriser un agent Claude en production. Une fois les accès audités, il reste à tester leur résistance réelle, ce que couvre notre article sur le red teaming des agents IA Claude. Pour les équipes qui utilisent Claude Code, notre guide pour connecter Claude Code au SI avec MCP détaille le catalogue de serveurs approuvés, les permissions outil par outil et les réglages gérés par l'administrateur.
Mesurer votre maturité
Notre diagnostic de maturité IA mesure en trois minutes où en est la gouvernance de vos agents, l'un des 6 axes du référentiel Koneetiv (édition 2026). Pour un suivi dans la durée, Claude Cockpit inscrit chacun de vos agents au registre vivant LOOP™, maintenu par les équipes Koneetiv et auditable à tout moment.