Le Model Context Protocol (MCP) normalise la façon dont les applications et les agents d'IA découvrent et utilisent des ressources, des prompts et des outils externes. Il réduit le besoin d'intégrations sur mesure, mais ne crée pas de confiance automatique. Un serveur MCP peut exposer la messagerie, des fichiers, des bases de données ou des actions critiques pour l'entreprise ; il doit donc être traité comme une API à privilèges, avec identité, autorisation, permissions minimales, validation, journalisation et approbation humaine.
Qu'est-ce que MCP
MCP définit une architecture client-serveur pour connecter les applications d'IA aux données et aux capacités. Ses éléments habituels sont :
- Host : l'application qui exécute l'expérience d'IA.
- Client MCP : maintient la connexion avec un serveur.
- Serveur MCP : expose les capacités.
- Resources : contenu interrogeable.
- Tools : opérations exécutables.
- Prompts : modèles ou flux réutilisables.
Le protocole normalise la communication, mais l'organisation reste responsable du serveur qu'elle installe, des données qu'elle expose et des actions qu'elle autorise.
MCP face à une API classique
| Critère | MCP | API directe |
|---|---|---|
| Découverte | Capacités décrites au client | Documentation et intégration spécifiques |
| Cible | Applications et agents d'IA | N'importe quel logiciel |
| Contexte | Ressources, outils et prompts | Endpoints et données |
| Risque | Sélection dynamique par le modèle | Flux plus déterministe |
| Contrôle | Nécessite une politique supplémentaire | Peut être intégré à l'application |
MCP ne remplace pas l'API sous-jacente : il l'enveloppe généralement et ajoute une couche qui doit elle aussi être gouvernée.
Inventaire des serveurs
Chaque serveur MCP doit disposer de sa propre fiche, comprenant au moins :
- Propriétaire et dépôt.
- Version et éditeur.
- Transport et emplacement.
- Ressources, outils et prompts exposés.
- Systèmes cibles.
- Données et leur classification.
- Identifiants et scopes.
- Utilisateurs et agents autorisés.
- Journaux et durée de conservation.
- Mise à jour et retrait.
Les serveurs locaux installés par les utilisateurs comptent eux aussi dans cet inventaire. La connexion aux serveurs non approuvés doit être bloquée lorsque le risque le justifie.
Modèle de confiance
Un serveur n'est pas fiable simplement parce qu'il figure dans un registre, pas plus qu'un client ne l'est simplement parce qu'il est d'origine professionnelle. Les parties doivent s'authentifier, la version doit être validée et la capacité exposée doit être limitée.
Une menace peut compromettre n'importe quel maillon de la chaîne :
- Le serveur MCP.
- Le paquet ou la dépendance.
- Le client ou l'hôte.
- Le modèle qui décide quels outils utiliser.
- Le contenu récupéré.
- Le système final.
- Les identifiants délégués.
Le modèle de menaces doit couvrir toute la chaîne, pas seulement le serveur.
Autorisation
La documentation officielle de MCP définit l'autorisation pour les transports HTTP en suivant les conventions d'OAuth 2.1. L'implémentation doit éviter les tokens statiques à large portée.
Les principes de base sont :
- Authentification de l'utilisateur et du service.
- Tokens avec la bonne audience.
- Scopes minimaux.
- Durée de vie courte et rotation.
- Consentement clair.
- Révocation et désactivation.
- Séparation des environnements.
- Ne jamais retransmettre les tokens vers des destinations non autorisées.
En transport STDIO, les identifiants proviennent généralement de l'environnement. Ils doivent être isolés et ne jamais être exposés dans des prompts, des journaux ou des fichiers de configuration non sécurisés.
Permissions par outil
Un serveur ayant accès à la messagerie ne devrait pas exposer « gérer la messagerie » comme une permission unique. Il convient de séparer, au minimum :
- Rechercher.
- Lire.
- Créer un brouillon.
- Envoyer.
- Supprimer.
- Gérer les règles.
Chaque outil doit définir ses arguments, ses limites, ses destinataires, son volume et le besoin d'approbation. Les opérations de lecture n'impliquent pas de permission d'écriture.
Validation déterministe
Le modèle peut proposer un appel, mais c'est du code déterministe qui doit valider, entre autres :
- Schéma et types.
- Identité et portée.
- Ressource autorisée.
- Règles métier.
- Limites de quantité.
- Contexte et environnement.
- Idempotence.
- Besoin d'approbation.
Une instruction contenue dans un document ou dans la réponse d'un outil ne peut jamais étendre les permissions par elle-même.
Risques spécifiques
Confused deputy
Un serveur utilise sa propre autorité pour exécuter une demande que l'utilisateur ne pourrait pas réaliser directement. On l'atténue en liant le token, l'utilisateur, la ressource et l'objet de l'appel.
Token passthrough
Réutiliser le token reçu sur des services en aval peut rompre le contrôle de l'audience et de l'accès. Le serveur doit utiliser des flux adaptés et des identifiants propres à chaque destination.
Injection de prompt indirecte
Une ressource contient des instructions malveillantes qui poussent l'agent à appeler des outils qu'il ne devrait pas utiliser. Le contenu récupéré est toujours traité comme une donnée non fiable, et toute action qui en découle nécessite une politique externe.
Tool poisoning
La description ou le comportement d'un outil peuvent tromper le modèle. C'est pourquoi les outils ne doivent être autorisés qu'à partir d'un catalogue signé ou approuvé, et tout changement doit être revu.
SSRF et accès local
Un serveur qui accepte des URL ou des chemins peut finir par accéder au réseau interne ou à des fichiers qu'il ne devrait pas atteindre. On les atténue avec des listes d'autorisation, la normalisation des entrées et l'isolation.
Supply chain
Les implémentations de référence ne sont pas nécessairement adaptées à la production. Il faut revoir le code, les dépendances, la signature, le SBOM, les mises à jour et la sécurité générale du paquet.
Enterprise-managed authorization
L'extension d'autorisation gérée par l'entreprise vise à éviter que chaque personne n'autorise des serveurs de son propre chef, sans politique centrale. Elle permet d'intégrer l'identité de l'entreprise, l'onboarding, l'offboarding et des contrôles cohérents dans toute l'organisation, ce qui s'accorde bien avec une approche de passerelle IA d'entreprise centralisant la gouvernance de ces connexions.
L'organisation devrait centraliser :
- Le catalogue des serveurs.
- Les fournisseurs d'identité.
- Les politiques et les scopes.
- Les approbations.
- La révocation.
- L'observabilité.
- Les exceptions.
Approbation humaine
Tous les outils n'exigent pas une confirmation humaine. La matrice de contrôle doit tenir compte de l'impact et de la réversibilité de chaque action :
| Action | Contrôle |
|---|---|
| Lire une donnée autorisée | Automatique, journalisée |
| Créer un brouillon | Automatique ou revue a posteriori |
| Envoyer un message | Confirmation contextuelle |
| Modifier un enregistrement critique | Approbation préalable |
| Paiement, suppression ou privilège | Double contrôle ou hors périmètre |
L'écran d'approbation doit toujours afficher l'action, les arguments, le système concerné, les conséquences et la source à l'origine de la demande.
Journalisation
La trace de chaque appel doit inclure :
- Utilisateur, agent et serveur.
- Version.
- Outil invoqué.
- Arguments masqués.
- Politique appliquée.
- Approbation.
- Réponse.
- Erreur et nouvelle tentative.
- Latence et coût.
- Identifiant de corrélation.
Les données sensibles doivent être réduites au minimum dans le journal. Le journal doit permettre d'enquêter sur un incident sans devenir une copie indiscriminée de l'information.
Disponibilité et idempotence
Les délais d'expiration et les nouvelles tentatives peuvent dupliquer des actions. C'est pourquoi chaque opération d'écriture doit utiliser une clé d'idempotence, en plus de limites d'appels, de circuit breakers et de mécanismes de compensation.
Si le serveur tombe en panne, l'agent doit se dégrader en toute sécurité : signaler l'incident, ne pas inventer de résultat et ne pas se rabattre sur un autre outil disposant de plus de privilèges.
Cycle de vie
Admission
Revue du propriétaire, du code, de l'éditeur, des données, des outils et des menaces du serveur.
Pilote
Environnement de test, comptes synthétiques et permissions limitées à la lecture.
Production
Version figée, supervision, SLA et plan de retour arrière.
Changement
Revue de tout nouvel outil, scope ou dépendance avant son approbation.
Retrait
Révoquer les tokens, supprimer la configuration, conserver les preuves et confirmer la suppression.
Tests
Avant de valider un serveur MCP, il convient de vérifier au moins :
- Utilisateur sans permission.
- Token avec une mauvaise audience.
- Outil altéré.
- Arguments hors limites.
- Ressource contenant une injection de prompt.
- URL interne ou chemin de traversée.
- Serveur en panne.
- Réponse malformée.
- Appel dupliqué.
- Processus de désactivation (offboarding).
Ce type de tests contradictoires est précisément le terrain d'un exercice de AI Red Teaming appliqué à la couche des agents et des serveurs MCP.
Plan à 60 jours
Jours 1 à 15
Inventaire, cas d'usage circonscrit et modèle de menaces.
Jours 16 à 30
Autorisation, scopes, catalogue et politiques.
Jours 31 à 45
Validation, approbation, journalisation et tests contradictoires.
Jours 46 à 60
Pilote, indicateurs, corrections et mise en production limitée.
Erreurs fréquentes
- Installer des serveurs communautaires sans les revoir.
- Utiliser des tokens personnels à large portée.
- Faire confiance aux descriptions des outils.
- Mélanger permissions de lecture et d'écriture.
- Approuver des actions sans afficher les arguments.
- Retransmettre les tokens vers des systèmes en aval.
- Ne pas valider les URL ni les chemins.
- Consigner des secrets dans les journaux.
- Relancer des appels sans idempotence.
- Ne pas révoquer les accès lors du retrait d'un serveur ou d'un utilisateur.
Checklist
- Catalogue et propriétaire définis.
- Versions et code revus.
- Autorisation et audience correctes.
- Scopes et outils minimaux.
- Validation en dehors du modèle.
- Approbation proportionnée à l'impact.
- Isolation des secrets et du réseau.
- Journaux corrélés et réduits au minimum.
- Idempotence et limites en place.
- Tests d'injection et de supply chain.
- Révocation et retrait prévus.
Questions fréquentes
MCP est-il sécurisé par défaut ?
Non. Il fournit des mécanismes et une spécification, mais la sécurité réelle dépend de l'autorisation, de l'implémentation et des politiques appliquées par chaque organisation.
Remplace-t-il OAuth ?
Non. Pour les transports HTTP, MCP définit un cadre d'autorisation aligné sur OAuth 2.1, et non une alternative à celui-ci.
Peut-on l'utiliser uniquement en lecture ?
Oui, et c'est un bon point de départ. Dans ce cas, le catalogue doit être limité aux ressources et aux outils non destructifs.
Un serveur de référence convient-il pour la production ?
Il ne faut pas le supposer. Le dépôt officiel lui-même avertit que les implémentations de référence sont à visée pédagogique et nécessitent une évaluation de sécurité avant d'être déployées en production.
Chez Summum IA, nous concevons le catalogue, l'autorisation, les politiques et les tests nécessaires pour intégrer MCP sans étendre les privilèges de manière invisible. Si votre entreprise souhaite connecter des agents d'IA à des systèmes internes avec ce niveau de contrôle, notre service d'intégration MCP pour entreprises vous accompagne à chaque étape, de l'inventaire initial jusqu'à la mise en production limitée.