Sandbox pour serveur MCP : serveurs MCP isolés avec contrôle du système de fichiers, des secrets et du réseau

Les serveurs MCP doivent s’exécuter avec des montages de système de fichiers limités, des secrets à privilèges minimaux, une politique réseau explicite, des limites par espace de travail par agent, et des journaux, afin que l’accès aux outils n’étende pas silencieusement la frontière de confiance de l’agent. Un sandbox 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 partie difficile n’est pas de décider que MCP nécessite une isolation ; c’est de décider quelle frontière appartient à chaque outil, quelles données traversent cette frontière, et quelles actions nécessitent encore une révision humaine.

Pourquoi MCP change la frontière de confiance de l’agent

Le Model Context Protocol (MCP) offre aux applications d’IA un moyen commun de connecter des modèles à des outils, des invites et des ressources. Cela rend l’intégration plus propre, mais transforme aussi chaque serveur MCP en une frontière de 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.

Si vous connectez ces outils à un flux de travail plus large, commencez par How to Automate Tasks with AI puis décidez si la boucle externe a besoin d’un agent de codage ou d’un interpréteur plus léger.

La spécification MCP décrit plusieurs attentes en matière de sécurité qui comptent pour la conception du sandbox : les utilisateurs doivent comprendre et consentir aux outils exposés, les hôtes doivent exiger le consentement avant l’invocation d’un outil, 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 sandbox 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’invites fait une mauvaise demande.

Pensez à la frontière 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 des outils, 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 sandbox	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 consultation 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 aussi large que le travail qu’il effectue.

Quoi 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’invite en un incident plus large.

Les candidats prioritaires pour le sandboxing 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 téléchargé par l’utilisateur, un ensemble 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, l’état de session, des fichiers téléchargés ou des captures d’écran.
• Connecteurs de données qui peuvent interroger des enregistrements clients, des exportations analytiques, des tickets ou des documents privés.
• Outils de déploiement et d’intégration continue qui peuvent créer des branches, publier des aperçus, modifier la configuration ou modifier l’infrastructure.
• Outils de paquets et de dépendances qui peuvent récupérer du code depuis des registres, des dépôts Git ou des URLs arbitraires.

Les serveurs MCP à risque plus faible peuvent tout de même mériter des contrôles. Un serveur de recherche de documentation publique en lecture seule peut ne pas nécessiter une micro-VM par requête, mais il devrait tout de même avoir un chemin réseau autorisé, 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ù le serveur MCP doit-il s’exécuter

Il existe trois modèles de placement courants. Aucun n’est universellement correct.

| Placement | À utiliser quand | Attention à | |—|—| | Même sandbox que l’espace de travail de l’agent | Le serveur est étroitement couplé aux fichies, commandes shell, session de navigation ou artefacs générés actuels de l’agent | Le serveur et l’agent partagent l’état, donc un outil compomis peut voir le mêe espace de travail à moins que les montages et les secrets soint spécifiés | | Sandbox séparée par serveur MCP ou groupe d’outils | L’outil nécessite une isolement plus fort de l’espace de travail de l’agent, gère des identifiants différents, ou effectue une exécution à risque plus élevé | Le transert de fichies entre sandboxes et la latence deviennent partis du design du produi | | Hors du sandbox 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 surface d’administration interne large juste parce qu’elle se trouve en dehors du sandbox |

Exécuter un serveur dans le même sandbox est pratique pour les agents de codage. Le serveur MCP peut voir le dépôt, exécuter des tests, inspecter des artefacts et renvoyer des résultats sans déplacer des 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 sandbox séparé est préférable lorsque l’outil mérite une politique différente. Par exemple, un serveur MCP d’analyse de paquets peut 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 devrait jamais voir ces cookies.

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

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

L’accès au système de fichiers est l’endroit où la commodité de MCP se transforme souvent en privilège accidentel. Un serveur qui a besoin de 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 explicites d’espace de travail :

• 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, l’ensemble 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 de confiance.
• Évitez de monter les dossiers d’identifiants tels que .ssh, les répertoires de configuration cloud, les profils de navigateur ou les fichiers d’authentification de gestionnaire de paquets locaux.
• Réinitialisez ou faites un instantané de l’espace de travail entre des utilisateurs, locataires ou tâches sans rapport.

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 frontière de sécurité complète. Traitez-les comme un mécanisme de coordination entre client et 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 modèle 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 benchmark 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	Éviter les montages de fichiers si possible	Si inévitable, monter un fichier de secret limité avec une durée de vie stricte et une rédaction

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 voyagent à travers les variables d’environnement, les journaux, les traces de pile, les scripts de paquets, l’historique du shell, les sessions de navigateur et les réponses des outils. Lorsqu’un serveur MCP a besoin d’un identifiant, donnez-lui l’identifiant le plus étroit qui peut accomplir 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, à moins que le modèle d’autorisation ne l’exige véritablement.

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

• Inectez les secrets au démaage du sandbox ou du processus, pas via des invites.
• Utilisez des jetons à duré de vie courte ou révocables lorsque le fournisseur le supporte.
• Limitez les identifiants par outil, locataire, environnement et action.
• Rédigez les secrets de 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.
• Rotez les identifiants utilisés par les serveurs à haut risque et après une exposition suspectée à une injection d’invite.

Évitez un anti-modèle courant : un seul fichier d’environnement universel monté dans chaque session d’agent. Cela rend le développement local plus facile et 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 modèles de transport locaux et distants. 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 sandbox résolvent des problèmes différents :

Question	Ce que le transport répond	Ce que la politique réseau répond
Comment le client MCP communique-t-il avec le serveur ?	stdio, transport basé sur HTTP, ou un autre modèle 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 aucune sortie
Le serveur peut-il récupérer des paquets ou des pages web ?	Pas suffisant en soi	Listes d’autorisation de registres, listes d’autorisation 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 sandbox

Pour les serveurs stdio locaux, le risque est souvent un accès hérité à l’hôte. Le serveur peut s’exécuter en tant que processus fils 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 sandboxé ou exécutez toute la paire hôte-travailleur dans un espace de travail jetable.

Pour les serveurs MCP basés sur HTTP, le risque se déplace vers l’authentification, l’exposition réseau et la séparation entre locataires. Utilisez l’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 réseau interne large sans une politique claire déterminant 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 transit. S’il a besoin de recherche web, acheminez via un proxy qui enregistre les domaines demandés et bloque les points de terminaison de métadonnées internes. S’il a besoin d’API internes, exposez une API étroite au lieu de tout le réseau privé.

Installations de paquets, sous-processus et état de longue durée

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 navigation lancent des navigateurs. Les agents de construction appellent des compilateurs. Le support des sous-processus n’est pas le problème ; le support invisible des sous-processus 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 les flux de travail en plusieurs étapes, mais il doit appartenir au bon agent, utilisateur et tâche.

Utilisez des contrôles de cycle de vie :

Contrôle	Pourquoi c’est important
Identifiants de sandbox par agent	Empêche l’état d’outil d’un agent de devenir le contexte d’un autre agent
Délai d’inactivité	Nettoye les sessions d’outil abandonnées
Politique de pause et reprise	Supporte les travaux longs sans garder du calcul inutile actif
Politique d’instantané ou de modèle	Démarre des environnements reproductibles à partir d’une base connue
Teardown explicite	Supprime les fichiers, tue les processus et libère les identifiants après la tâche

Si un outil produit des artéfacts durables, copiez uniquement ces artefacts hors du sandbox. Ne conservez pas tout l’espace de travail à moins que le produit n’exige explicitement une relecture complète de la session.

Journalisation, nettoyage et révision humaine

Les journaux d’outils MCP doivent répondre aux questions de sécurité et de débogage sans devenir un nouveau coffre-fort de secrets. Les journaux utiles incluent le nom de l’outil, l’identité de l’appelant, l’ID du sandbox, l’ID 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 des artefacts.

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

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

• 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 exportations 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 sandbox 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’agent qui ont besoin d’un environnement d’exécution isolé pour l’exécution de code, les fichiers, les processus, les flux de travail de type navigateur et les sessions de longue durée. Il peut s’intégrer aux architectures MCP où un serveur d’outil a besoin d’un espace de travail jetable au lieu d’un accès direct à un ordinateur de développeur, un hôte de production ou un machine CI partagée.

Utilisez-le comme limite d’exécution pour les serveurs qui ont besoin de :

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

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

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

pour chaque tâche d'agent :
  créer un sandbox à partir d'un modèle approuvé
  monte seulement l'espace de travail de la tâche
  injecter seulement les secrets spécifiques à l'outil
  démarrer le serveur MCP à l'intérieur du sandbox ou se connecter à une API d'outil basée sur le sandbox
  acheminer les appels d'outil via des vérifications d'approbation et de politique
  collecter les journaux et les artefacts approuvés
  arrêter, réinitialiser ou mettre en pause le sandbox selon le cycle de vie de la tâche

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éponder
Portée de l’outil	Quels outils le serveur expoe-til, et quels changent l’état exerne ?
placement	Le serveur doit-il s’exécuter dans le sandbox de l’agent, un sandbox séparé, ou en dehors du sandbox derrière une API étroite ?
Système de fichies	Quels répertoires sont montés, sont-ils en lecteure seule ou en lecteure-écriture, et comment les échappes de chemins sont-ils bloqués ?
Secrets	Quels identifants sont inectés, comment sont-ils limités, et où peuvent-ils apparaître dans les journaux ou les sorties ?
Réeau	La sortie est-elle refusée par défaut, acheminée par proxy, ou autorisée par domaine, registre et API inerne ?
Sous-processus	Quelles commandes, gestionnaires de paquets, travaux 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 de pause/reprise et le nettoyage ?
Journaux	Pouvez-vous reconstruire les appels d’outils, les modifiations de fichies, les domaines exernes et les artefacs sans stocker de secrets ?
Révision humaine	Quels appels d’outil nécessitent une apprbation avant exécution, exportation, déploiement ou action destinée aux clents ?
Tests	Avez-vous testé l’jection d’invit, le traversement de lien symbolique/chemin, les sorties volumineuses, l’échec de nettoyage et les chemins de sortie refusés ?

MCP rend l’inégration des outils plus facile. Le sandboxing empêche cette inégration de devenir une exension 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 de l’agent, d’autres dans des sandboxes séparés, et d’autres en dehors du sandbox derrière des APIs avec une autorisation stricte. Choisissez le placeent qui correspnd aux données, secrets, sous-processus et besoins réseau de l’outil.

FAQ

Chaque serveur MCP doit-il s’exéuter dans un sandbox ?

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 changent l’état exerne. Les serveurs à plus faible risque en lecteure seule peuvent encore nécessiter une authentification, une journalisation et des contrôles réseau, mais peuvent ne pas nécessiter un sandbox 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, de l’environnement et de l’accès réseau locaux. Les serveurs basés sur HTTP nécessitent une authentification et des contrôles d’exposition plus forts. Le choix le plus sûr dépend de l’endroit où le processus s’exécute et des permissions d’exécution qu’il reçoit.

Les racines MCP peuvent-elles remplacer le sandboxing du système de fichiers ?

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

Où stocker les secrets pour les outils MCP en sandbox ?

Injectez uniquement les identifiants dont l’outil a besoin, idéalement en tant que variables d’environnement de courte durée ou secrets d’exécution limités. Ne montez pas de dossiers d’identifiants de développeur larges et ne transmettez pas de secrets via des invites. Rédigez-les des journaux et des réponses des 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 de données volumineuses, les écritures d’infrastructure, et toute commande ou action réseau en dehors de la politique normale de l’espace de travail.

Articles recommandés

• AI-Generated Code Sandbox Requirements for Production Apps
• Claude MCP: How to Configure MCP Servers in Claude Code and Claude Desktop
• Building a Coding Agent with Novita’s Agent Sandbox