Sandbox 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èmes de fichiers limités, des secrets dotés de privilèges minimaux, une politique réseau explicite, des limites par espace de travail d’agent et des journaux. Ainsi, l’accès aux outils n’étend pas silencieusement le périmètre 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 longue. La difficulté ne réside pas dans la décision d’isoler MCP, mais dans le choix de la frontière à placer autour de chaque outil, des données qui traversent cette frontière et des actions qui nécessitent encore une validation humaine.

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

Le Model Context Protocol offre aux applications d’IA un moyen commun de connecter les modèles aux outils, aux invites et aux ressources. Cela facilite l’intégration, mais transforme également 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.

La spécification MCP décrit plusieurs attentes de sécurité importantes pour la conception du sandbox : les utilisateurs doivent comprendre et consentir aux outils exposés, les hôtes doivent exiger un 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’invocation fait une mauvaise requête.

Considérez 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 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 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 au moment de l’exécution de chaque serveur aussi restreint que la tâche qu’il effectue.

Quoi isoler en premier

Commencez par les serveurs MCP qui peuvent modifier un é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 :

• Les outils d’exécution de code qui exécutent des commandes shell, Python, Node.js, des compilateurs, des tests ou des notebooks.
• Les outils de système de fichiers qui lisent ou écrivent un dépôt, un téléchargement utilisateur, un jeu de données monté, un fichier d’identification ou un artefact généré.
• Les outils de navigateur et d’utilisation de l’ordinateur qui conservent des cookies, un état de session, des fichiers téléchargés ou des captures d’écran.
• Les connecteurs de données qui peuvent interroger des enregistrements clients, des exportations d’analyse, des tickets ou des documents privés.
• Les outils de déploiement et d’intégration continue qui peuvent créer des branches, publier des prévisualisations, faire pivoter la configuration ou modifier l’infrastructure.
• Les outils de gestion de paquets et de dépendances qui peuvent récupérer du code depuis des registres, des dépôts Git ou des URL arbitraires.

Les serveurs MCP à moindre risque peuvent néanmoins mériter des contrôles. Un serveur de recherche documentaire publique en lecture seule n’a peut-être pas besoin d’une micro-VM par requête, mais il devrait toujours avoir une liste blanche de chemins réseau, des journaux et des limites de débit. L’isolement doit suivre le rayon d’explosion pratique de l’outil, et non 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	Quand l’utiliser	Attention
Même sandbox que l’espace de travail de l’agent	Le serveur est étroitement couplé aux fichiers actuels de l’agent, aux commandes shell, à la session navigateur 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 soient limités
Sandbox séparé par serveur MCP ou groupe d’outils	L’outil nécessite un isolement plus fort 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 sandbox et la latence deviennent partie intégrante de la conception du produit
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 large surface d’administration interne 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 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 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 pourrait avoir besoin d’un accès Internet aux registres publics, tandis que l’agent de codage principal ne le devrait pas. 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”. Une consultation de facturation, une lecture de fonctionnalités ou une recherche dans un outil de suivi d’incidents peut être plus sûre en tant qu’API backend normale avec autorisation côté serveur qu’en tant que serveur libre dans l’environnement de calcul de l’agent.

Montages de systèmes 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 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 explicites d’espace de travail :

• Attribuez un répertoire d’espace de travail dédié à chaque exécution d’agent.
• 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 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 du gestionnaire de paquets localement.
• Réinitialisez ou prenez un instantané de 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 frontière 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 via 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 base, 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, montez un fichier secret limité avec une durée de vie stricte et un 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 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 restrictif qui permet d’accomplir l’action de l’outil.

Utilisez des identifiants distincts pour des serveurs MCP distincts. 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 permissions l’exige vraiment.

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

• Injectez les secrets au démarrage du sandbox ou du processus, pas via des invites.
• Utilisez des jetons à durée de vie courte ou révocables lorsque le fournisseur le prend en charge.
• Limitez les identifiants par outil, locataire, environnement et action.
• Masquez les secrets de stdout, stderr, des réponses structurées des outils et des 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 pivoter 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 mais rend la revue de production plus difficile. Si un outil n’a pas besoin d’un secret, il ne devrait pas pouvoir le lire.

Choix du transport réseau et de la sortie

MCP prend en charge les modèles de transport local et distant. La spécification décrit stdio pour la communication de processus locaux et Streamable HTTP pour la communication serveur-client via HTTP. Les anciennes conceptions basées sur SSE existent 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 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 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 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 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 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 indiquant 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’installer des paquets, autorisez le registre de paquets ou un cache de miroir. S’il a besoin de recherches web, acheminez via un proxy qui journalise 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 persistant

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 navigateur lancent des navigateurs. Les agents de build 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 build 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 changements de dépendances et des tâches en arrière-plan. Cet état peut être utile pour les workflows en plusieurs é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
ID de sandbox par agent	Empêche l’état d’un outil d’un agent de devenir le contexte d’un autre agent
Temporisation d’inactivité	Nettoie les sessions d’outils abandonnées
Politique de pause et de reprise	Permet les longs travaux sans maintenir un 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 le travail

Si un outil produit des artefacts durables, copiez uniquement ces artefacts hors du sandbox. Ne conservez pas tout l’espace de travail sauf si le produit nécessite explicitement une relecture complète de la session.

Journalisation, nettoyage et validation 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’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 code de sortie et les chemins d’artefacts.

Ne journalisez pas par défaut les invites brutes, les données client brutes, 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 rétention plus stricts.

Certaines actions MCP doivent rester soumises à une validation humaine même au sein 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 des fichiers volumineux, des dépôts privés, des exportations de bases de données ou des chaînes de type 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 validation des actions commerciales sensibles.

Comment Novita Agent Sandbox s’intègre

Novita Agent Sandbox est conçu pour les charges de travail des 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 longues. Il peut s’intégrer dans les 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 frontière d’exécution pour les serveurs qui ont besoin de :

• Exécuter du code ou des commandes générées.
• Travailler avec des fichiers temporaires et des artefacts générés.
• Conserver un état d’espace de travail par agent à travers des tâches en plusieurs étapes.
• Exécuter un travail en arrière-plan que l’agent pourra consulter plus tard.
• Séparer l’expérimentation de l’agent de l’hôte d’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 périmètres des identifiants, la politique réseau, le flux d’approbation, le schéma de journalisation et le comportement de nettoyage. Le sandbox fournit l’environnement isolé dans lequel 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 :

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 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 pour la 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 des outils	Quels outils le serveur expose-t-il et lesquels modifient un état externe ?
Placement	Le serveur doit-il s’exécuter dans le sandbox de l’agent, dans un sandbox séparé, ou en dehors du sandbox derrière une API étroite ?
Système de fichiers	Quels répertoires sont montés, sont-ils en lecture seule ou en 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 en refus par défaut, acheminée par proxy, ou en liste blanche 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 temporisations d’inactivité, le comportement pause/reprise et le nettoyage ?
Journaux	Pouvez-vous reconstruire les appels d’outils, les modifications de fichiers, les domaines externes et les artefacts sans stocker de secrets ?
Validation humaine	Quels appels d’outils nécessitent une approbation avant l’exécution, l’exportation, le déploiement ou une action destinée aux clients ?
Tests	Avez-vous testé l’injection d’invites, la traversée de chemins/liens symboliques, les sorties volumineuses, les nettoyages échoués et les chemins de sortie refusés ?

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

FAQ

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

Non. Donnez la priorité aux 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 un é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 n’ont peut-être pas besoin d’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 de l’accès au système de fichiers, à l’environnement et au réseau locaux. Les serveurs basés sur HTTP nécessitent des contrôles d’authentification et 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 prévus de l’espace de travail 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ù les secrets doivent-ils être stockés pour les outils MCP en sandbox ?

Injectez uniquement les identifiants dont l’outil a besoin, idéalement en tant que variables d’environnement à courte durée de vie ou secrets d’exécution limités. Ne montez pas de vastes dossiers d’identifiants de développeur et ne passez pas de secrets via des invites. Masquez-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 dans l’infrastructure, ainsi que 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
• Build a Remote Code Execution MCP Server with Novita Sandbox and mcp-use Library
• Building a Coding Agent with Novita’s Agent Sandbox
• How Agent Sandboxes Power Secure, Scalable AI Innovation