Serveurs MCP dans des environnements isolés : compromis entre fichiers, secrets et réseau

Les serveurs MCP doivent s’exécuter avec des montages de systèmes de fichiers limités, des secrets au moindre privilège, une politique réseau explicite, des limites d’espace de travail par agent et des journaux, afin que l’accès aux outils n’élargisse pas silencieusement la limite de confiance de l’agent. Un bac à sable est utile lorsqu’un serveur MCP peut lire des fichiers, lancer des sous-processus, installer des paquets, appeler des API internes ou conserver un état pour une session d’agent de longue durée. La difficulté n’est pas de décider que MCP a besoin d’isolation ; c’est de décider quelle limite entoure chaque outil, quelles données traversent cette limite et quelles actions nécessitent encore une révision humaine.

Pourquoi MCP modifie la limite de confiance de l’agent

Le Model Context Protocol offre aux applications d’intelligence artificielle un moyen commun de connecter les modèles à des outils, des invites et des ressources. Cela rend l’intégration plus propre, mais transforme également chaque serveur MCP en une frontière politique. Si un serveur expose read_file, run_command, query_database ou deploy_preview, l’agent peut désormais demander des actions qui dépassent la fenêtre de contexte du modèle.

La spécification MCP décrit plusieurs attentes de sécurité qui comptent pour la conception du bac à sable : les utilisateurs doivent comprendre et consentir aux outils exposés, les hôtes doivent exiger un consentement avant l’invocation d’outils, les descriptions d’outils ne sont pas fiables sauf vérification, et les données sensibles doivent être protégées par des contrôles d’accès appropriés. Ces règles sont des contrôles au niveau de l’application. Un bac à sable ajoute des contrôles d’exécution en dessous, limitant ce que le processus du serveur MCP peut toucher, même si l’agent, la description de l’outil ou la chaîne d’invocation font une mauvaise demande.

Considérez la limite de confiance en trois couches :

Couche	Ce qu’elle contrôle	Mode de défaillance courant
Hôte ou client MCP	Quels serveurs sont connectés et quels appels d’outils sont approuvés	Un outil large est approuvé une fois et réutilisé dans un contexte plus sensible
Serveur MCP	Implémentation de l’outil, authentification, validation des entrées, accès aux ressources	Un outil lit plus de fichiers, envoie plus de données ou exécute plus de commandes que prévu
Environnement d’exécution du bac à sable	Système de fichiers, processus, réseau, secrets, cycle de vie et journaux	Le processus serveur hérite de l’accès à l’hôte car il s’exécute trop près des ressources de production

L’objectif n’est pas de rendre chaque serveur MCP non fiable de la même manière. Un outil de recherche de calendrier, un outil d’exécution de code local et un outil de déploiement ont des profils de risque différents. L’objectif est de maintenir l’accès d’exécution de chaque serveur au plus étroit à la tâche qu’il effectue.

Ce qu’il faut isoler en premier

Commencez par les serveurs MCP qui peuvent modifier l’état externe, toucher à des données sensibles ou exécuter du code. Ce sont les serveurs les plus susceptibles de transformer une simple erreur d’invocation en un incident plus large.

Les candidats prioritaires pour l’isolation dans un bac à sable incluent :

• Outils d’exécution de code qui exécutent des commandes shell, Python, Node.js, des compilateurs, des tests ou des notebooks.
• Outils de système de fichiers qui lisent ou écrivent un dépôt, un fichier utilisateur, un jeu de données monté, un fichier d’identifiants ou un artefact généré.
• Outils de navigation et d’utilisation d’ordinateur qui conservent des cookies, des sessions, des fichiers téléchargés ou des captures d’écran.
• Connecteurs de données capables d’interroger des enregistrements clients, des exports d’analytique, des tickets ou des documents privés.
• Outils de déploiement et d’intégration continue capables de créer des branches, publier des aperçus, modifier la configuration ou modifier l’infrastructure.
• Outils de paquets et de dépendances capables de récupérer du code depuis des registres, des dépôts Git ou des URL arbitraires.

Les serveurs MCP à moindre risque peuvent toujours mériter des contrôles. Un serveur de recherche de documentation publique en lecture seule peut ne pas nécessiter une microVM par requête, mais il doit toujours avoir une liste blanche de chemins réseau, des journaux et des limites de débit. L’isolation doit suivre le rayon d’explosion pratique de l’outil, pas l’étiquette « serveur MCP ».

Où exécuter le serveur MCP

Il existe trois schémas de placement courants. Aucun n’est universellement correct.

Placement	Quand l’utiliser	Attention à
Dans le même bac à sable que l’espace de travail de l’agent	Le serveur est étroitement couplé aux fichiers actuels de l’agent, aux commandes shell, à la session de navigation ou aux artefacts générés	Le serveur et l’agent partagent l’état, donc un outil compromis peut voir le même espace de travail à moins que les montages et les secrets ne soient limités
Bac à sable séparé par serveur MCP ou groupe d’outils	L’outil nécessite une isolation plus forte de l’espace de travail de l’agent, gère des identifiants différents ou effectue une exécution à plus haut risque	Le transfert de fichiers entre bacs à sable et la latence font partie de la conception du produit
En dehors du bac à sable derrière une API limitée	L’outil est un service de production stable avec sa propre authentification, autorisation, journalisation et limites de débit	L’API doit être étroite ; n’exposez pas une large surface d’administration interne simplement parce qu’elle se trouve en dehors du bac à sable

Exécuter un serveur dans le même bac à sable est pratique pour les agents de codage. Le serveur MCP peut voir le dépôt, exécuter des tests, inspecter des artefacts et retourner des résultats sans déplacer de fichiers entre environnements. Cela fonctionne mieux lorsque l’espace de travail lui-même est déjà jetable et ne contient que les fichiers que l’agent doit utiliser.

Un bac à sable séparé est préférable lorsque l’outil mérite une politique différente. Par exemple, un serveur MCP d’analyse de paquets pourrait avoir besoin d’un accès Internet aux registres publics, tandis que l’agent de codage principal ne devrait pas y avoir accès. Un serveur MCP de navigateur peut avoir besoin de cookies pour un compte de test, tandis qu’un serveur d’exécution de code ne doit jamais voir ces cookies.

Un service externe convient aux outils qui ne sont pas vraiment des « outils d’exécution ». Une consultation de facturation, une lecture de fonctionnalités ou une recherche de suivi de problème peuvent être plus sûres en tant qu’API backend normale avec autorisation côté serveur plutôt qu’en tant que serveur libre dans l’environnement de calcul de l’agent.

Montages de système de fichiers et espaces de travail par agent

L’accès au système de fichiers est là où la commodité de MCP se transforme souvent en privilège accidentel. Un serveur qui doit lire ./src ne devrait pas hériter du répertoire personnel d’un développeur. Un outil qui écrit des graphiques générés ne devrait pas pouvoir écraser la configuration de déploiement.

Utilisez des limites d’espace de travail explicites :

• Donnez à chaque exécution d’agent son propre répertoire d’espace de travail.
• Montez uniquement le dépôt, le dossier de téléchargement, le jeu de données ou le répertoire d’artefacts nécessaire à la tâche.
• Préférez les montages en lecture seule pour le matériel source et les montages en lecture-écriture uniquement pour les sorties.
• Séparez les sorties générées des fichiers source fiables.
• Évitez de monter des dossiers d’identifiants tels que .ssh, les répertoires de configuration cloud, les profils de navigateur ou les fichiers d’authentification du gestionnaire de paquets local.
• Réinitialisez ou sauvegardez l’espace de travail entre des utilisateurs, locataires ou tâches non liés.

Les racines MCP peuvent aider les clients à communiquer les emplacements du système de fichiers sur lesquels un serveur doit opérer, mais les racines ne constituent pas à elles seules une limite de sécurité complète. Traitez-les comme un mécanisme de coordination entre le client et le serveur. L’environnement d’exécution a toujours besoin de limites au niveau du système de fichiers, et le serveur doit valider les chemins afin que les requêtes ne puissent pas s’échapper de l’espace de travail prévu avec des liens symboliques, des chemins relatifs ou des astuces d’extraction d’archive.

Un schéma pratique consiste à diviser l’accès à l’espace de travail par rôle :

Répertoire	Accès	Objectif
/workspace/input	Lecture seule	Téléchargements utilisateur, dépôt de départ, fixture de référence ou données de test
/workspace/output	Lecture-écriture	Fichiers générés, rapports, correctifs, graphiques ou captures d’écran
/workspace/tmp	Lecture-écriture, jetable	Cache de construction, cache d’installation de paquets, fichiers temporaires
/workspace/secrets	Évitez les montages de fichiers si possible	Si inévitable, montez un fichier secret limité avec durée de vie stricte et masquage

Les chemins exacts n’ont pas d’importance. Le principe, oui.

Secrets et variables d’environnement

Les secrets sont généralement plus faciles à divulguer que les fichiers car ils transitent par des variables d’environnement, des journaux, des traces de pile, des scripts de paquets, l’historique du shell, des sessions de navigateur et des réponses d’outils. Lorsqu’un serveur MCP a besoin d’un identifiant, donnez-lui l’identifiant le plus restreint capable de terminer l’action de l’outil.

Utilisez des identifiants séparés pour des serveurs MCP séparés. Un serveur de recherche de tickets GitHub peut avoir besoin d’un accès en lecture seule aux tickets. Un serveur de création de PR peut avoir besoin d’un accès en écriture aux branches. Un serveur de déploiement ne devrait pas partager l’un ou l’autre jeton, sauf si le modèle de permission l’exige vraiment.

Une bonne gestion des secrets pour les serveurs MCP ressemble à ceci :

• Injectez les secrets au démarrage du bac à sable ou du processus, pas via des invites.
• Utilisez des jetons à courte durée de vie ou révocables lorsque le fournisseur le permet.
• Limitez les identifiants par outil, locataire, environnement et action.
• Masquez les secrets dans stdout, stderr, les réponses structurées des outils et les journaux de trace.
• Ne renvoyez pas les variables d’environnement brutes au modèle.
• Ne laissez pas l’agent décider quel secret charger.
• Faites tourner les identifiants utilisés par les serveurs à haut risque et après une suspicion d’exposition par injection d’invite.

Évitez un anti-modèle courant : un fichier d’environnement universel monté dans chaque session d’agent. Cela facilite le développement local et rend la révision en production plus difficile. Si un outil n’a pas besoin d’un secret, il ne devrait pas pouvoir le lire.

Sortie réseau et choix de transport

MCP prend en charge les schémas de transport local et à distance. La spécification décrit stdio pour la communication entre processus locaux et Streamable HTTP pour la communication serveur-client via HTTP. Les conceptions plus anciennes basées sur SSE apparaissent encore dans l’écosystème, mais les nouvelles intégrations devraient vérifier la documentation MCP actuelle et le SDK choisi avant de dépendre d’un transport spécifique.

Le choix du transport et la politique réseau du bac à sable résolvent des problèmes différents :

Question	Le transport répond	La politique réseau répond
Comment le client MCP parle-t-il au serveur ?	stdio, transport HTTP, ou un autre schéma pris en charge	Non applicable
Quels hôtes externes le serveur peut-il appeler ?	Pas suffisant en soi	Liste blanche, liste noire, proxy, politique DNS ou absence de sortie
Le serveur peut-il récupérer des paquets ou des pages web ?	Pas suffisant en soi	Listes blanches de registres, listes blanches d’URL, mise en cache et journalisation
Un autre processus peut-il atteindre le serveur ?	Détails de liaison et d’authentification	Pare-feu entrant et limite réseau du bac à sable

Pour les serveurs stdio locaux, le risque est souvent l’accès hérité à l’hôte. Le serveur peut s’exécuter en tant que processus enfant de l’application hôte et voir les fichiers locaux, les variables d’environnement et les routes réseau. Si ce serveur exécute du code ou lit des fichiers sensibles, déplacez-le dans un processus en bac à sable ou exécutez toute la paire hôte-travailleur dans un espace de travail jetable.

Pour les serveurs MCP HTTP, le risque se déplace vers l’authentification, l’exposition réseau et la séparation entre locataires. Utilisez une autorisation côté serveur, TLS, des vérifications d’origine le cas échéant, et des identifiants par client. N’exposez pas un serveur MCP distant sur un large réseau interne sans une politique claire sur qui peut invoquer quels outils.

Pour la sortie réseau, le refus par défaut est plus facile à raisonner que l’ouverture par défaut. Si un outil a besoin d’installations de paquets, autorisez le registre de paquets ou un cache de type pull-through. S’il a besoin de recherches web, acheminez via un proxy qui journalise les domaines demandés et bloque les points de terminaison metadata internes. S’il a besoin d’API internes, exposez une API étroite au lieu de l’ensemble du réseau privé.

Installations de paquets, sous-processus et état à long terme

De nombreux outils MCP utiles ont besoin de sous-processus. Les agents de codage exécutent des tests. Les agents de données installent des bibliothèques. Les agents de navigateur lancent des navigateurs. Les agents de construction appellent des compilateurs. Le support des sous-processus n’est pas le problème ; c’est le support invisible des sous-processus qui l’est.

Avant d’autoriser les installations de paquets ou l’exécution de shell, définissez :

• Quelles commandes sont autorisées, interdites ou soumises à approbation.
• Si les gestionnaires de paquets peuvent atteindre l’Internet public.
• Si les versions des dépendances doivent être épinglées ou basées sur un fichier de verrouillage.
• Où se trouvent les caches de construction et les paquets installés.
• Combien de temps les processus en arrière-plan peuvent s’exécuter.
• Quels fichiers de sortie sont conservés après le nettoyage.
• Si l’agent peut démarrer des écouteurs réseau.

Les serveurs MCP de longue durée introduisent un second problème : la dérive d’état. Un serveur qui vit pendant des heures peut accumuler des fichiers, des identifiants, des cookies de navigateur, un historique de shell, des modifications de dépendances et des tâches en arrière-plan. Cet état peut être utile pour des workflows multi-étapes, mais il doit appartenir au bon agent, au bon utilisateur et à la bonne tâche.

Utilisez des contrôles de cycle de vie :

Contrôle	Pourquoi c’est important
Identifiants de bac à sable par agent	Empêche que l’état d’outil d’un agent devienne le contexte d’un autre agent
Délai d’inactivité	Nettoie les sessions d’outils abandonnées
Politique de pause et reprise	Prend en charge les tâches longues sans garder du calcul inutile actif
Politique d’instantané ou de modèle	Démarre des environnements reproductibles à partir d’une base de référence connue
Nettoyage explicite	Supprime les fichiers, tue les processus et libère les identifiants après la tâche

Si un outil produit des artefacts durables, copiez uniquement ces artefacts hors du bac à sable. Ne préservez pas l’ensemble de l’espace de travail sauf si le produit nécessite explicitement une relecture complète de session.

Journalisation, nettoyage et révision humaine

Les journaux des outils MCP doivent répondre aux questions de sécurité et de débogage sans devenir un nouveau magasin de secrets. Les journaux utiles incluent le nom de l’outil, l’identité de l’appelant, l’identifiant du bac à sable, l’identifiant de l’espace de travail, la catégorie de commande, les fichiers lus ou écrits, les domaines externes contactés, les noms de paquets installés, le statut de sortie et les chemins d’artefacts.

Ne journalisez pas par défaut les invites brutes, les données brutes des clients, les jetons, le contenu complet des fichiers ou la sortie complète des commandes. Gardez les traces sensibles derrière des contrôles d’accès et des politiques de conservation plus stricts.

Certaines actions MCP doivent rester soumises à une révision humaine même à l’intérieur d’un bac à sable :

• Publier ou déployer en production.
• Envoyer des e-mails, des chats, des tickets, des factures ou des messages destinés aux clients.
• Modifier le contrôle d’accès, la facturation, les données utilisateur ou la configuration de l’infrastructure.
• Exfiltrer de gros fichiers, des dépôts privés, des exports de bases de données ou des chaînes ressemblant à des identifiants.
• Exécuter des commandes en dehors de la politique de l’espace de travail.
• Appeler des API internes avec des permissions d’écriture.

Le bac à sable doit réduire le rayon d’explosion. Il ne doit pas devenir une raison de supprimer la révision des actions commerciales sensibles.

Comment Novita Agent Sandbox s’intègre

Novita Agent Sandbox est conçu pour les charges de travail d’agents qui ont besoin d’un environnement d’exécution isolé pour l’exécution de code, les fichiers, les processus, les workflows de type navigateur et les sessions de longue durée. Il peut s’intégrer dans des architectures MCP où un serveur d’outils a besoin d’un espace de travail jetable plutôt que d’un accès direct à un ordinateur portable de développeur, à un hôte de production ou à une machine CI partagée.

Utilisez-le comme limite d’exécution pour les serveurs qui doivent :

• Exécuter du code ou des commandes générés.
• Travailler avec des fichiers temporaires et des artefacts générés.
• Conserver l’état de l’espace de travail par agent à travers des tâches multi-étapes.
• Exécuter un travail en arrière-plan que l’agent pourra vérifier plus tard.
• Séparer l’expérimentation de l’agent de l’hôte d’application.

Gardez la limite du produit claire : un serveur MCP est toujours votre code d’application. Vous concevez toujours les permissions des outils, les limites des identifiants, la politique réseau, le flux d’approbation, le schéma de journalisation et le comportement de nettoyage. Le bac à sable fournit l’environnement isolé où ces décisions sont appliquées.

Pour une configuration spécifique au produit, utilisez la documentation actuelle de Novita plutôt que de copier des extraits obsolètes de tutoriels plus anciens. Conceptuellement, la forme est :

for each agent task:
  create sandbox from approved template
  mount only the task workspace
  inject only tool-specific secrets
  start the MCP server inside the sandbox or connect to a sandbox-backed tool API
  route tool calls through approval and policy checks
  collect logs and approved artifacts
  stop, reset, or pause the sandbox according to the task lifecycle

Cela maintient les conseils au niveau de l’article stables tout en laissant les appels SDK exacts à la documentation la plus récente et à votre code de plateforme.

Liste de contrôle de mise en œuvre

Utilisez cette liste de contrôle avant de connecter un serveur MCP à un agent autonome ou semi-autonome :

Domaine	Questions à répondre
Périmètre de l’outil	Quels outils le serveur expose-t-il, et lesquels modifient l’état externe ?
Placement	Le serveur doit-il s’exécuter dans le bac à sable de l’agent, dans un bac à sable séparé, ou en dehors du bac à sable derrière une API étroite ?
Système de fichiers	Quels répertoires sont montés, sont-ils en lecture seule ou lecture-écriture, et comment les évasions de chemin sont-elles bloquées ?
Secrets	Quels identifiants sont injectés, comment sont-ils limités, et où peuvent-ils apparaître dans les journaux ou les sorties ?
Réseau	La sortie est-elle par défaut refusée, routée via proxy, ou autorisée par domaine, registre et API interne ?
Sous-processus	Quelles commandes, gestionnaires de paquets, tâches en arrière-plan et écouteurs sont autorisés ?
État	Comment sont gérés les espaces de travail par agent, les instantanés, les délais d’inactivité, le comportement pause/reprise et le nettoyage ?
Journaux	Pouvez-vous reconstituer les appels d’outils, les modifications de fichiers, les domaines externes et les artefacts sans stocker de secrets ?
Révision humaine	Quels appels d’outils nécessitent une approbation avant exécution, exportation, déploiement ou action destinée au client ?
Tests	Avez-vous testé l’injection d’invite, le traversement de chemin (lien symbolique ou chemin relatif), les sorties volumineuses, l’échec de nettoyage et les chemins de sortie refusés ?

MCP facilite l’intégration d’outils. La mise en bac à sable empêche cette intégration de devenir une extension silencieuse des privilèges du modèle. La bonne conception est généralement un mélange : certains serveurs dans le même espace de travail d’agent, certains dans des bacs à sable séparés, et certains en dehors du bac à sable derrière des API avec une autorisation stricte. Choisissez le placement qui correspond aux besoins de l’outil en termes de données, secrets, sous-processus et réseau.

FAQ

Chaque serveur MCP doit-il s’exécuter dans un bac à sable ?

Non. Priorisez les serveurs qui exécutent du code, lisent ou écrivent des fichiers, utilisent des secrets, appellent des services privés, lancent des navigateurs, installent des paquets ou modifient l’état externe. Les serveurs en lecture seule à moindre risque peuvent encore nécessiter une authentification, une journalisation et des contrôles réseau, mais ils peuvent ne pas avoir besoin d’un bac à sable dédié par requête.

stdio est-il plus sûr que HTTP pour les serveurs MCP ?

Pas automatiquement. stdio peut être simple pour les serveurs locaux, mais le serveur peut hériter du système de fichiers local, de l’environnement et de l’accès réseau. Les serveurs basés sur HTTP ont besoin de contrôles d’authentification et d’exposition plus forts. Le choix le plus sûr dépend de l’endroit où s’exécute le processus et des permissions d’exécution qu’il reçoit.

Les racines MCP peuvent-elles remplacer l’isolation du système de fichiers ?

Non. Les racines aident à communiquer les emplacements de l’espace de travail prévus entre le client et le serveur, mais elles ne constituent pas une limite d’exécution complète. Utilisez la validation de chemin et les contrôles du système de fichiers au niveau du bac à sable pour maintenir le serveur dans l’espace de travail prévu.

Où stocker les secrets pour les outils MCP en bac à sable ?

Injectez uniquement les identifiants dont l’outil a besoin, idéalement sous forme de variables d’environnement à courte durée de vie ou de secrets d’exécution limités. Ne montez pas de dossiers larges d’identifiants de développeur et ne passez pas de secrets via des invites. Masquez-les dans les journaux et les réponses d’outils.

Quand un outil MCP doit-il nécessiter une approbation humaine ?

Exigez une approbation pour les déploiements en production, les messages destinés aux clients, les modifications de facturation ou de contrôle d’accès, les exportations importantes de données, les écritures dans l’infrastructure, et toute commande ou action réseau en dehors de la politique normale de l’espace de travail.

Articles recommandés

• Construire un serveur MCP d’exécution de code à distance avec Novita Sandbox et la bibliothèque mcp-use
• Construire un agent de codage avec Novita Agent Sandbox
• Comment les bacs à sable d’agents alimentent une innovation IA sécurisée et évolutive