AGTCloud API Docs
GuidesRéférence APIIntégrations et ressourcesMises à jour et aide

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.

ParticipantResponsabilité principaleFormes courantes
MCP HostHéberger l’application d’IA, gérer les connexions, les autorisations et les confirmations utilisateurAgents de programmation, IDE, assistants de bureau
MCP ClientÉtablir une connexion dédiée à un MCP Server et fournir ses capacités au HostGénéralement intégré au Host
MCP ServerExposer des outils, des données ou des modèles de prompts spécifiquesSous-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 :

PrimitiveContrôleRôlePoints à vérifier lors de l’intégration
ToolsLe modèle peut choisir de les appeler ; le Host gère l’exécution et l’autorisationEffectuer des actions ou des recherches : appeler une API, écrire un fichier, interroger une base de donnéesSchema d’entrée, écritures, effets externes, nécessité d’une approbation humaine
ResourcesSélectionnées et gérées par l’applicationFournir au modèle du contexte : fichiers, enregistrements, réponses d’APIPérimètre des données, informations sensibles, fréquence de mise à jour, fiabilité du contenu
PromptsGénéralement sélectionnés par l’utilisateurFournir des modèles d’interaction et des paramètres réutilisablesOrigine 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.

TransportFonctionnementCas d’utilisation privilégiéPrincipaux risques
stdioLe client démarre un sous-processus serveur local et échange des messages JSON-RPC ligne par ligne via l’entrée et la sortie standardOutils locaux, répertoires contrôlés, serveurs sans déploiement réseauLa 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 HTTPLe client envoie un HTTP POST à un unique Endpoint MCP ; le serveur renvoie du JSON ou un flux SSE limité à la requête en coursServices distants, capacités partagées en équipe, serveurs avec authentification réseauIdentité 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"
      }
    }
  }
}
  • command est le programme réellement exécuté par le client ; vérifiez son chemin complet et son origine avant la connexion ;
  • args peut contenir des répertoires autorisés, des fichiers de configuration ou des paramètres du serveur ;
  • env ne 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ètreVérifications avant l’intégration
Fichiers locauxRépertoires accessibles en lecture et en écriture, suivi des liens symboliques et accès aux fichiers hors du périmètre
Exécution de commandesProgrammes exécutés par le Tool et contrôle direct éventuel des arguments par le modèle ou du contenu externe
Accès réseauDomaines, services internes et API tierces contactés par le serveur
IdentifiantsEmplacement des Key ou Token, processus ou domaine destinataire, possibilité de révocation individuelle
Traitement des donnéesTransmission éventuelle des entrées et des résultats hors de la machine, conservation des journaux et des données d’appel par le fournisseur
ÉcrituresConfirmation explicite avant modification, suppression, soumission, paiement ou envoi de messages
Mises à jourNouvelle 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ômeVérifier en prioritéSolution
Le serveur ne démarre pasChemin de commande, runtime, arguments et répertoire de travailVé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 ToolCapacités du serveur, autorisations et version du clientRechargez la liste des capacités et vérifiez que le client prend en charge la Primitive
La connexion stdio se ferme immédiatementPrésence de journaux ordinaires sur stdoutÉcrivez les journaux sur stderr et réservez stdout aux messages MCP
L’Endpoint distant renvoie 401 ou 403Authentification du serveur, Token et ScopeAutorisez de nouveau la connexion selon sa documentation, sans utiliser le Token d’un autre service
L’Endpoint distant renvoie 404Présence du chemin MCP complet dans l’URLUtilisez l’Endpoint fourni par l’éditeur, sans ajouter vous-même un chemin d’API de modèle
Le Tool peut lire, mais pas écrireAutorisations, 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 descriptionVersion du serveur, Schema du Tool et entrées externesDé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 connexionAutorisations réseau du serveur et destinations des donnéesDé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.

Sur cette page