Intégration MCP et sécurité
Comprenez l’architecture MCP, ses transports et les limites d’autorisation pour connecter un serveur tiers ou votre propre serveur en toute sécurité.
Model Context Protocol (MCP) est un protocole ouvert qui relie les applications d’IA aux systèmes externes. Les clients compatibles peuvent obtenir du contexte, appeler des outils ou utiliser des prompts prédéfinis via un MCP Server, sans concevoir un protocole d’intégration spécifique à chaque source de données.
MCP et les API de modèles sont des couches d’intégration différentes
L’API AGTCloud sert à appeler les modèles ; un MCP Server expose des outils et du contexte aux clients compatibles. Pour connecter MCP, utilisez les commandes d’installation, les URL et l’authentification fournies par l’éditeur ou l’administrateur du serveur. Une adresse d’API de modèle AGTCloud ne peut pas servir d’Endpoint MCP Server.
Fonctionnement de MCP
Un MCP Host peut se connecter à plusieurs MCP Server et créer un MCP Client distinct pour chacun.
| Participant | Responsabilité principale | Formes courantes |
|---|---|---|
| MCP Host | Héberger l’application d’IA, gérer les connexions, les autorisations et les confirmations utilisateur | Agents de programmation, IDE, assistants de bureau |
| MCP Client | Établir une connexion dédiée à un MCP Server et fournir ses capacités au Host | Généralement intégré au Host |
| MCP Server | Exposer des outils, des données ou des modèles de prompts spécifiques | Sous-processus local, service distant |
MCP comporte une couche de données et une couche de transport : la première définit les messages JSON-RPC, la découverte des capacités et les Primitives ; la seconde détermine comment les messages circulent entre processus locaux ou sur le réseau. Les clients encapsulent généralement ces détails. Privilégiez leur interface de configuration MCP pour l’intégration.
Capacités proposées par un serveur
Un MCP Server expose principalement trois types de Primitives :
| Primitive | Contrôle | Rôle | Points à vérifier lors de l’intégration |
|---|---|---|---|
| Tools | Le modèle peut choisir de les appeler ; le Host gère l’exécution et l’autorisation | Effectuer des actions ou des recherches : appeler une API, écrire un fichier, interroger une base de données | Schema d’entrée, écritures, effets externes, nécessité d’une approbation humaine |
| Resources | Sélectionnées et gérées par l’application | Fournir au modèle du contexte : fichiers, enregistrements, réponses d’API | Périmètre des données, informations sensibles, fréquence de mise à jour, fiabilité du contenu |
| Prompts | Généralement sélectionnés par l’utilisateur | Fournir des modèles d’interaction et des paramètres réutilisables | Origine du modèle, sens des paramètres, présence éventuelle d’instructions externes |
Le serveur déclare les capacités qu’il prend en charge, puis le client découvre les Tools, Resources et Prompts disponibles. Une capacité proposée n’est pas nécessairement activée par le client : le comportement dépend aussi de la version du Host, de sa politique d’autorisation et des choix de l’utilisateur.
Traitez le contenu du serveur comme une entrée externe
Les Resource, résultats de Tool et Prompt peuvent contenir des éléments non fiables. Leur transmission via MCP ne justifie pas d’autoriser automatiquement leurs instructions à accéder à d’autres fichiers, identifiants ou services système.
Choisir le transport
La spécification MCP actuelle définit deux transports standard : stdio et Streamable HTTP.
| Transport | Fonctionnement | Cas d’utilisation privilégié | Principaux risques |
|---|---|---|---|
stdio | Le client démarre un sous-processus serveur local et échange des messages JSON-RPC ligne par ligne via l’entrée et la sortie standard | Outils locaux, répertoires contrôlés, serveurs sans déploiement réseau | La commande de démarrage exécute un programme local ; le serveur hérite des autorisations du processus et d’une partie de son environnement |
| Streamable HTTP | Le client envoie un HTTP POST à un unique Endpoint MCP ; le serveur renvoie du JSON ou un flux SSE limité à la requête en cours | Services distants, capacités partagées en équipe, serveurs avec authentification réseau | Identité du service, OAuth ou Token, limites réseau, export de données et effets distants |
Avec stdio, le stdout du serveur doit contenir uniquement des messages MCP ; les journaux doivent aller sur stderr. En cas d’échec de connexion, examinez les journaux stderr capturés par le client, mais ne transmettez pas à un tiers des journaux complets contenant des identifiants.
Streamable HTTP utilise actuellement un unique Endpoint POST ; il n’est pas nécessaire de configurer une adresse GET distincte ou une ancienne adresse HTTP+SSE. Le serveur détermine l’authentification. S’il propose OAuth, suivez de préférence sa page d’autorisation plutôt que d’inscrire des identifiants durables dans une configuration partagée.
Comprendre la configuration
Les noms des champs et l’emplacement de la configuration varient selon les clients. Les exemples ci-dessous montrent uniquement des structures courantes et ne sont pas directement exécutables. Remplacez tous les paramètres fictifs par les commandes, arguments, URL et méthodes d’authentification réels fournis par l’éditeur du serveur.
{
"mcpServers": {
"replace-with-server-name": {
"command": "/absolute/path/to/server-command",
"args": [
"--replace-with-required-argument"
],
"env": {
"SERVICE_API_KEY": "replace-with-client-supported-secret-reference"
}
}
}
}commandest le programme réellement exécuté par le client ; vérifiez son chemin complet et son origine avant la connexion ;argspeut contenir des répertoires autorisés, des fichiers de configuration ou des paramètres du serveur ;envne transmet que les variables d’environnement indispensables au serveur. La syntaxe des références aux secrets dépend du client.
Ne copiez pas directement des commandes de démarrage inconnues
Les command et args de la configuration MCP locale sont exécutés sur votre ordinateur. N’exécutez pas de commande d’installation automatique d’origine inconnue et n’accordez pas par défaut l’accès à l’ensemble du répertoire personnel, du répertoire SSH ou des répertoires système.
Étapes d’intégration sécurisée
1. Vérifier le support du client
Vérifiez que le client prend en charge MCP et lesquels des transports stdio et Streamable HTTP il accepte. Utilisez le format de configuration correspondant à sa version actuelle, sans déduire les champs d’exemples d’autres clients.
2. Vérifier l’identité du serveur
Obtenez les instructions d’installation depuis le dépôt officiel, la console du fournisseur ou l’administrateur de votre organisation. Vérifiez l’éditeur, la version, les modifications, les dépendances et la désinstallation. Pour un serveur distant, vérifiez aussi le domaine, HTTPS et l’authentification.
3. Recenser les capacités et les autorisations
Avant l’activation, examinez les Tools, Resources et Prompts exposés. Consignez pour chaque Tool les entrées, le périmètre de lecture, les écritures et les effets externes ; désactivez les capacités sans rapport avec la tâche.
4. Limiter le périmètre
Pour un serveur local, autorisez seulement les répertoires et les variables d’environnement nécessaires ; pour un serveur distant, utilisez un compte ou un Scope aux privilèges minimaux. Ne transmettez pas une API Key de modèle à un serveur inconnu comme identifiant MCP générique.
5. Recharger et vérifier
Rechargez la configuration selon les instructions du client, vérifiez la connexion et confirmez que la liste des capacités affichée correspond aux attentes. Une connexion réussie ne signifie pas que tous les Tool doivent être activés.
6. Commencer en lecture seule
Commencez par lister les capacités, lire une Resource non sensible ou appeler un Tool sans effet de bord. Après avoir vérifié les entrées, les sorties et les journaux, autorisez progressivement l’écriture de fichiers, les modifications de données ou les appels à des systèmes externes.
Liste de vérification des autorisations
| Périmètre | Vérifications avant l’intégration |
|---|---|
| Fichiers locaux | Répertoires accessibles en lecture et en écriture, suivi des liens symboliques et accès aux fichiers hors du périmètre |
| Exécution de commandes | Programmes exécutés par le Tool et contrôle direct éventuel des arguments par le modèle ou du contenu externe |
| Accès réseau | Domaines, services internes et API tierces contactés par le serveur |
| Identifiants | Emplacement des Key ou Token, processus ou domaine destinataire, possibilité de révocation individuelle |
| Traitement des données | Transmission éventuelle des entrées et des résultats hors de la machine, conservation des journaux et des données d’appel par le fournisseur |
| Écritures | Confirmation explicite avant modification, suppression, soumission, paiement ou envoi de messages |
| Mises à jour | Nouvelle présentation des autorisations au client lorsque le package du serveur ou ses capacités distantes changent |
Pour un serveur distant, connectez uniquement des adresses HTTPS fiables et suivez leur procédure d’autorisation. Pour un serveur local, privilégiez un chemin de commande absolu, des répertoires isolés et les droits d’un utilisateur standard, plutôt que des privilèges administrateur par commodité.
Problèmes fréquents
| Symptôme | Vérifier en priorité | Solution |
|---|---|---|
| Le serveur ne démarre pas | Chemin de commande, runtime, arguments et répertoire de travail | Vérifiez dans un terminal ordinaire que le programme existe, sans contourner le client pour exécuter une commande inconnue |
| Le client indique une connexion, mais aucun Tool | Capacités du serveur, autorisations et version du client | Rechargez la liste des capacités et vérifiez que le client prend en charge la Primitive |
La connexion stdio se ferme immédiatement | Présence de journaux ordinaires sur stdout | Écrivez les journaux sur stderr et réservez stdout aux messages MCP |
L’Endpoint distant renvoie 401 ou 403 | Authentification du serveur, Token et Scope | Autorisez de nouveau la connexion selon sa documentation, sans utiliser le Token d’un autre service |
L’Endpoint distant renvoie 404 | Présence du chemin MCP complet dans l’URL | Utilisez l’Endpoint fourni par l’éditeur, sans ajouter vous-même un chemin d’API de modèle |
| Le Tool peut lire, mais pas écrire | Autorisations, répertoires et confirmation humaine | Élargissez les droits seulement si nécessaire, puis effectuez un nouveau test réversible |
| Le comportement du Tool ne correspond pas à sa description | Version du serveur, Schema du Tool et entrées externes | Désactivez immédiatement le Tool, conservez des éléments de preuve expurgés et contactez l’éditeur |
| Des requêtes externes inattendues surviennent après la connexion | Autorisations réseau du serveur et destinations des données | Déconnectez le serveur, révoquez les identifiants et examinez les journaux ainsi que l’activité réseau de l’hôte |
Recommandations pour une utilisation durable
- Réexaminez régulièrement les serveurs connectés, leurs versions, leurs Tool et leurs autorisations ;
- Utilisez des identifiants distincts, révocables et aux privilèges minimaux pour chaque serveur ;
- Conservez la confirmation humaine, notamment pour les suppressions, écritures, paiements, messages et opérations de production ;
- Ne considérez pas les instructions de Resource inconnues ou de résultats de Tool comme des instructions système fiables ;
- Retirez des journaux, captures d’écran et rapports d’erreur les Key, Token, données clients et chemins sensibles ;
- Lorsque vous cessez d’utiliser un serveur, retirez sa configuration du client et révoquez les identifiants associés.
Pour configurer AGTCloud dans un client de modèle, commencez par le tutoriel d’intégration CC-Switch ou choisissez un outil dans « Intégrations tierces » à gauche. Pour les endpoints et les champs de requêtes, consultez la Référence API. La documentation officielle MCP fait référence pour les détails du protocole et ses évolutions.