Sandboxing de Claude Code : comment isoler, contraindre et sécuriser le code Claude en production

Présentation

Claude Code peut lire des fichiers, écrire du code, exécuter des commandes shell, effectuer des requêtes réseau et appeler des outils externes. Sur l'ordinateur portable d'un développeur, cette autonomie est essentielle. Dans le pipeline d'une entreprise, il s'agit d'une surface de menace qui nécessite des limites explicites.

Le sandboxing du code Claude consiste à exécuter Claude Code dans un environnement d'exécution contraint. Accès au système de fichiers, sortie du réseau, exécution des processus et disponibilité des outils : tout cela est défini et limité de manière explicite. Ignorez cette étape et vous disposez d'un agent autonome doté d'un accès complet au système, à une seule instruction injectée d'un incident réel.

Anthropic le sait. En octobre 2025, ils ont lancé un sandboxing natif pour Claude Code, basé sur des primitives au niveau du système d'exploitation : Linux Bubblewrap et macOS Seatbelt. Des tests internes ont révélé une réduction de 84 % des demandes d'autorisation. La technologie fonctionne. Mais le sandboxing natif ne couvre qu'une partie des besoins des équipes d'entreprise. L'isolation au niveau du conteneur, les contrôles de sortie du réseau, la définition de la portée des informations d'identification et la journalisation des audits nécessitent des décisions d'infrastructure qui vont au-delà d'un seul indicateur CLI.

Nous couvrons ici les quatre surfaces de confinement : système de fichiers, shell, réseau et outils externes. Sans oublier les contrôles de confidentialité des données du code Claude qui déterminent ce qui quitte réellement votre environnement.

Pourquoi le sandboxing Claude Code n'est pas facultatif pour les entreprises

La configuration par défaut de Claude Code permet à l'agent d'accéder à l'ensemble du système de fichiers du développeur, d'exécuter des commandes shell arbitraires et d'envoyer des requêtes réseau à n'importe quel point de terminaison accessible. C'est très bien pour une utilisation en solo par un développeur. Pour les déploiements d'entreprise desservant plusieurs équipes et exécutant des flux de travail automatisés, ces valeurs par défaut ne sont pas acceptables.

Chaque système automatisé d'un environnement d'entreprise doit fonctionner selon le principe du moindre privilège. Claude Code, en tant qu'agent de codage autonome, nécessite un sandboxing explicite pour répondre à cette norme. Quatre surfaces doivent être confinées : le système de fichiers, le shell, le réseau et les outils externes.

Les conséquences de l'absence de sandboxing sont bien documentées. Développeur Mike Wolak's Numéro #10077 de GitHub décrit Claude Code exécutant rm -rf depuis le root de sa machine, détruisant ainsi tous les fichiers appartenant à l'utilisateur. Une pièce séparée incident survenu en novembre 2025 a vu Claude créer accidentellement un répertoire nommé ~, puis exécuter rm -rf * dans le parent, que le shell a étendu au répertoire personnel. Aucun des deux cas ne nécessitait --dangerously-skip-permissions. Le système d'autorisation lui-même a échoué.

Le sandboxing ne remplace pas les autorisations. Il ajoute une couche de confinement structurelle en dessous. Si les autorisations constituent la première étape (« Cet outil doit-il fonctionner ? ») , le sandboxing est le second (« s'il fonctionne, que peut-il réellement toucher ? »).

Les quatre surfaces d'attaque que Claude Code Sandboxing doit aborder

Chaque surface comporte des risques distincts. Les comprendre individuellement est la première étape vers un confinement efficace.

Système de fichiers : accès étendu en lecture/écriture par défaut

Le comportement du système de fichiers par défaut de Claude Code est généreux :

• L'accès en lecture couvre l'ensemble du système, à l'exception de certains répertoires refusés
• Accès en écriture par défaut au répertoire de travail et aux sous-répertoires actuels
• Lorsque --dangerously-skip-permissions est activé, les opérations sur les fichiers s'exécutent sans aucune confirmation
• Les fichiers sensibles (clés SSH, fichiers .env, configurations de production) sont souvent accessibles depuis une session de développeur

Le documentation sur le sandboxing confirme que l'outil bash en bac à sable limite les écritures dans le répertoire de travail actuel par défaut. Mais les outils de lecture et de modification intégrés à Claude Code fonctionnent en dehors du bac à sable : ils utilisent directement le système de permissions. Cela signifie que la portée du système de fichiers doit se faire à la fois au niveau de la couche sandbox et de la couche d'autorisation.

Exécution du shell : autorisations utilisateur complètes

Claude Code peut exécuter des commandes bash arbitraires avec les autorisations complètes de l'utilisateur qui l'exécute. Sans isolation de la coque :

• Une session compromise peut installer un logiciel, modifier la configuration du système ou exécuter des scripts persistants
• Les gestionnaires de packages (npm, pip) extraient et exécutent du code à partir de registres externes
• L'accès au shell dans les pipelines automatisés crée un chemin direct entre l'injection rapide et l'exécution de code arbitraire

Sur macOS, le framework Seatbelt limite ce que peuvent faire les commandes en mode sandbox. Sur Linux, film à bulles fournit une isolation basée sur l'espace de noms. Les deux imposent également des restrictions aux processus enfants : tout script ou programme généré par une commande en mode sandbox hérite des mêmes limites.

Accès au réseau : sortie illimitée sans contrôles

Sans isolation réseau, chaque session Claude Code est un vecteur potentiel d'exfiltration de données :

• L'agent peut envoyer des requêtes HTTP à des points de terminaison externes arbitraires
• Une injection rapide peut diriger l'agent vers le contenu du référentiel POST, les informations d'identification ou les réponses de l'API à l'infrastructure de l'attaquant
• Même sans intention malveillante, npm install ou pip install extrait du code non fiable des registres publics

Anthropiques blog d'ingénierie sur le sandboxing indique ceci directement : un sandboxing efficace nécessite les deux systèmes de fichiers et isolation du réseau. Sans isolation du réseau, un agent compromis pourrait exfiltrer des fichiers sensibles. Sans isolation du système de fichiers, un agent compromis pourrait échapper au sandbox et accéder au réseau. Les deux doivent travailler ensemble.

Claude Code achemine le trafic réseau en mode sandbox via un serveur proxy qui s'exécute en dehors du sandbox. Le proxy applique les restrictions de domaine et gère la confirmation par l'utilisateur pour les domaines nouvellement demandés.

Outils externes et serveurs MCP : portée illimitée

Claude Code connecté à Serveurs MCP hérite de toutes les fonctionnalités de ces serveurs par défaut :

• Un agent ayant accès à un outil de base de données peut souvent lire des données bien au-delà de ce que nécessite la tâche en cours
• Un serveur GitHub MCP permet à l'agent d'accéder à tous les dépôts autorisés par ses informations d'identification.
• La portée illimitée de l'outil signifie qu'une seule instruction manipulée peut atteindre des systèmes bien au-delà de la tâche prévue

La définition de la portée de l'outil MCP nécessite une couche de contrôle distincte. Le Approche MCP Gateway filtre les outils qui sont visibles pour chaque session en fonction de l'identité de l'agent et du contexte de la tâche.

Isolation du système de fichiers : limitation de ce que le code Claude peut lire et écrire

Une isolation efficace du système de fichiers limite l'agent à des répertoires spécifiques pertinents pour la tâche en cours. Aucun accès à l'ensemble du système de fichiers hôte. Aucune boutique d'informations d'identification. Aucun répertoire personnel.

Configuration de la sandbox native

Le sandbox intégré de Claude Code prend en charge des contrôles granulaires du système de fichiers via settings.json :

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "allowUnsandboxedCommands": false,
    "filesystem": {
      "allowWrite": ["./output"],
      "denyRead": ["~/.ssh", "~/.aws", "~/.env"]
    }
  }
}

Principaux paramètres à connaître :

• Sandbox.FileSystem.AllowWrite — donne accès en écriture à des chemins supplémentaires au-delà du répertoire de travail
• Sandbox.FileSystem.DenyRead — bloque l'accès en lecture aux répertoires sensibles
• AllowUnsandboxedCommands : lorsqu'il est défini sur false, il empêche Claude de réessayer les commandes ayant échoué en dehors du sandbox. Réglez ce paramètre sur false en production.

Ne montez que ce que la tâche nécessite

Lorsque vous exécutez Claude Code dans un conteneur Docker, montez uniquement le référentiel cible :

docker run -it --rm \
  -v $(pwd)/project:/workspace:ro \
  -v $(pwd)/output:/output \
  docker/sandbox-templates:claude-code

Le référentiel source est monté en lecture seule (:ro). La sortie est dirigée vers un répertoire inscriptible distinct. Une instruction injectée qui tente de modifier la source qu'elle analyse atteint un système de fichiers en lecture seule.

Ne montez jamais de fichiers d'identification

Les fichiers d'environnement, les configurations .env, les répertoires de clés SSH et les magasins d'informations d'identification cloud ne doivent jamais apparaître dans un sandbox Claude Code. Les informations d'identification de production appartiennent à une couche de gestion des secrets de plate-forme, et non à des fichiers que l'agent peut lire. Consultez les guide de sécurité d'entreprise pour savoir comment gérer l'injection d'informations d'identification en toute sécurité.

Isolation du réseau : contrôle de l'accès externe de Claude Code

L'isolation du réseau est l'élément le plus important du sandboxing de Claude Code pour empêcher l'exfiltration de données. Un agent qui ne peut pas accéder à des terminaux externes ne peut pas envoyer votre code, vos informations d'identification ou vos données en dehors de votre environnement.

Par défaut, Refuser, Autoriser par exception

Les environnements Claude Code devraient bloquer tous les accès réseau sortants par défaut. Autorisez uniquement les points de terminaison spécifiques requis par la tâche :

• Le point de terminaison de l'API Anthropic (pour inférence)
• Serveurs d'outils internes et points de terminaison MCP
• Registres de packages définis (npm, PyPI)
• Votre plateforme de contrôle de code source (GitHub, GitLab)

Bloquez tout le reste au niveau de la couche de politique réseau, et non de la couche d'application. Les restrictions au niveau de l'application peuvent être contournées. Les politiques réseau au niveau de l'infrastructure ne le peuvent pas, du moins pas par l'agent.

Utiliser les paramètres réseau de Claude Code comme première couche

Le sandbox de Claude Code achemine le trafic réseau via un proxy qui applique les restrictions de domaine. Configurez les domaines autorisés dans vos paramètres :

{
  "sandbox": {
    "network": {
      "allowedDomains": [
        "api.anthropic.com",
        "registry.npmjs.org",
        "github.com"
      ],
      "httpProxyPort": 8080,
      "socksProxyPort": 1080,
      "allowLocalBinding": true
    }
  }
}

Le tableau AllowedDomains contrôle les domaines auxquels les commandes sandbox peuvent accéder et prend en charge les caractères génériques (par exemple, *.npmjs.org). Les clés HttpProxyPort et SocksProxyPort vous permettent d'utiliser votre propre proxy au lieu du proxy intégré. AllowLocalBinding permet la liaison de ports localhost (macOS uniquement, la valeur par défaut est false).

Traitez-le comme un contrôle de première couche. Nécessaire mais pas suffisant en soi. La véritable mise en œuvre doit se faire au niveau de l'infrastructure : règles de sortie VPC, groupes de sécurité ou politiques réseau que l'agent ne peut pas modifier.

Acheminer le trafic de l'API via une passerelle

Envoyez les appels à l'API Anthropic de Claude Code via une passerelle contrôlée qui enregistre chaque demande et réponse. Le Passerelle IA fournit une visibilité sur ce qui est envoyé au modèle et ce qui en revient, indépendamment de ce que Claude Code enregistre lui-même. Pour la gestion des équipes limites d'utilisation, la passerelle applique également des limites tarifaires et des plafonds budgétaires.

Sandboxing au niveau du conteneur : exécution de code Claude en exécution isolée

Le déploiement basé sur des conteneurs est l'architecture de référence pour le sandboxing de Claude Code en production. Il combine l'isolation du système de fichiers, la politique réseau et l'isolation des processus dans une seule unité déployable.

Les bacs à sable Docker, lancés en janvier 2026, vont encore plus loin. Chaque sandbox s'exécute dans une microVM dédiée. Il ne s'agit pas d'un conteneur standard, mais d'une machine virtuelle complète et légère dotée de son propre noyau Linux et d'un démon Docker privé. Le démon Docker de l'hôte ne peut même pas voir les bacs à sable dans Docker PS.

Liste de contrôle de sécurité des conteneurs

Suivez les principes d'exécution suivants pour les déploiements en production :

• Image de base minimale. Supprimez les gestionnaires de packages, les utilitaires réseau et les outils dont la tâche n'a pas besoin. Une image plus petite signifie une surface d'attaque plus petite.
• Utilisateur non root. Les processus Claude Code ne doivent jamais être exécutés en tant que root. Un utilisateur limité ne peut pas modifier les fichiers système ni installer de packages au niveau du système via des commandes shell.
• Système de fichiers racine en lecture seule. Montez la racine du conteneur en lecture seule, avec uniquement des répertoires de sortie spécifiques accessibles en écriture. Aucune commande shell ne peut apporter de modifications persistantes à l'environnement du conteneur.
• Limites de ressources. Les limites du processeur et de la mémoire empêchent une automatisation galopante de consommer une infrastructure partagée. Les limites de processus réduisent la capacité de l'exécution du shell à générer des processus supplémentaires.
• Conteneurs éphémères. Détruisez le conteneur après chaque session Claude Code. Les écritures de fichiers involontaires, les entrées de cache des informations d'identification et les configurations modifiées disparaissent toutes avec le conteneur.

Le problème de Sandbox Escape

Aucun bac à sable n'est parfait. Une entreprise, Ona, présenté en mars 2026 que Claude Code pourrait contourner sa propre liste de déni en utilisant des astuces de chemin (/proc/self/root/usr/bin/npx aboutit au même binaire mais évite la correspondance de modèles). Lorsque Bubblewrap a détecté cela, l'agent a désactivé le bac à sable lui-même et a exécuté la commande en dehors de celui-ci.

L'agent n'a pas été jailbreaké. On ne lui a pas dit de s'échapper. Il voulait juste terminer la tâche, mais le bac à sable le gênait. La leçon : le sandboxing au niveau de l'application est nécessaire mais pas suffisant. L'application au niveau du système d'exploitation (bubblewrap, Seatbelt) détecte les erreurs des règles d'application. L'isolation au niveau de l'infrastructure (machines virtuelles, politiques réseau) permet de détecter les lacunes de l'application au niveau du système d'exploitation. La défense en profondeur est plus importante ici que partout ailleurs.

Claude Code Confidentialité des données : ce qui quitte votre environnement

La confidentialité des données de Claude Code comporte deux dimensions : ce qui est envoyé à l'API d'Anthropic dans le cadre d'un fonctionnement normal, et ce qui pourrait être divulgué via les mécanismes d'accès au réseau ou de sortie de Claude Code en cas d'échec du sandboxing.

Ce que Claude Code envoie à Anthropic

Le code, le contenu des fichiers et les fenêtres de contexte que Claude Code utilise pour l'inférence sont accessibles à l'API d'Anthropic. La durée pendant laquelle Anthropic conserve ces données dépend de votre plan :

• Forfaits grand public (Free, Pro, Max) : Conservation de 30 jours par défaut. Si vous optez pour l'amélioration du modèle, la durée de conservation s'étend sur 5 ans. Les forfaits destinés aux consommateurs incluent l'utilisation de Claude Code.
• Plans commerciaux (Team, Enterprise, API) : Anthropic n'entraîne pas de modèles à partir de vos données dans des conditions commerciales. La rétention standard de 30 jours s'applique.
• Aucune conservation de données : Disponible sur Claude pour Enterprise. Doit être activé par organisation par l'équipe chargée de votre compte.

Ces politiques proviennent directement d'Anthropic documentation sur l'utilisation des données et centre de confidentialité. Les équipes opérant dans le respect d'exigences strictes en matière de résidence ou de confidentialité des données doivent examiner attentivement les contrats d'entreprise d'Anthropic.

Ce que Claude Code peut divulguer sans sandboxing

Sans isolation réseau, une session Claude Code manipulée peut :

• Contenu du référentiel POST, informations d'identification ou réponses d'API aux points de terminaison externes via des commandes shell
• Lisez les fichiers sensibles dans le périmètre du système de fichiers de l'agent et incluez-les dans le contexte du modèle (qui est ensuite transféré vers l'API)
• Envoyez du code à des télécommandes Git non autorisées
• Écrire des informations d'identification dans les fichiers de sortie qui sont partagés en dehors de l'environnement

Les contrôles de confidentialité des données de Claude Code sont aussi efficaces que l'isolation du réseau et du système de fichiers qui les sous-tend. Le cadre de gouvernance explique comment élaborer des politiques organisationnelles autour de ces contrôles.

Journalisation pour des raisons de confidentialité et de conformité

Toutes les actions de Claude Code (lectures de fichiers, commandes shell, appels réseau, appels d'outils) devraient générer des journaux d'audit conservés dans votre propre infrastructure. Ne les transférez pas vers des plateformes SaaS externes si vous devez satisfaire aux exigences de la HIPAA, de la SOC 2 ou de la loi européenne sur l'IA. Le guide de sécurité d'entreprise explique comment acheminer les logs vers Grafana, Datadog ou Splunk via OpenTelemetry.

Comment TrueFoundry met en œuvre le sandboxing Claude Code pour les équipes d'entreprise

TrueFoundry fournit la couche d'infrastructure dont les équipes d'entreprise ont besoin pour exécuter Claude Code en toute sécurité à grande échelle. Tout est déployé dans votre propre environnement AWS, GCP ou Azure. L'exécution, la journalisation et le trafic réseau restent dans les limites de votre cloud.

Le sandboxing par code Claude dans TrueFoundry est appliqué au niveau de la couche d'infrastructure. Les équipes individuelles ne le configurent pas par session : les limites sont structurelles, appliquées avant le démarrage de Claude Code et cohérentes à chaque session.

• Exécution native au VPC. Chaque session Claude Code s'exécute au sein de votre réseau privé. Les politiques de sortie proviennent de l'infrastructure cloud et non de l'agent. Le Passerelle IA achemine tout le trafic du modèle via un seul point de terminaison contrôlé.
• Isolation conteneur par session. Claude Code s'exécute dans des conteneurs éphémères adaptés à la tâche. Chaque contenant est jeté une fois terminé. Aucune session ne partage un conteneur avec un autre utilisateur ou une autre tâche.
• Injection d'informations d'identification à périmètre limité. Les secrets de production n'apparaissent jamais dans l'environnement d'exécution de Claude Code. La plateforme fournit uniquement les autorisations spécifiques requises pour chaque tâche, l'accès au moindre privilège étant géré automatiquement.
• Étendue du système de fichiers. Seuls les répertoires pertinents pour la tâche en cours sont montés. Accès en lecture seule lorsque l'écriture n'est pas requise. Pas de répertoires personnels, pas de magasins d'identifiants, pas de bases de code indépendantes.
• Application de la liste d'autorisation réseau. L'accès réseau sortant à partir de sessions Claude Code est limité à des points de terminaison définis au niveau de la couche d'infrastructure. Les appels externes arbitraires sont bloqués avant d'atteindre le réseau.
• Journaux d'audit immuables. Chaque lecture de fichier, chaque commande shell, chaque appel réseau et chaque appel d'outil sont enregistrés avec l'identité de l'utilisateur, l'horodatage et la sortie. Les journaux restent dans votre environnement. Acheminez-les vers votre SIEM existant via OpenTelemetry.

Les organisations qui exécutent Claude Code via l'infrastructure de TrueFoundry ne s'appuient pas sur une configuration au niveau du drapeau pour créer des limites de sécurité. Les limites sont structurelles. Pour les équipes qui gèrent également Connexions au serveur MCP, la passerelle MCP fournit les mêmes contrôles d'accès au niveau de l'infrastructure que l'accès aux outils externes. Le complet Guide du flux de travail Claude Code explique comment ces contrôles s'intègrent aux flux de production et de développement.

Si votre équipe configure des sandbox manuellement pour chaque session Claude Code (configuration de conteneurs Docker, rédaction de règles de pare-feu, définition de la portée des montages de fichiers), TrueFoundry gère tout cela au niveau de la couche infrastructure.

Chaque session s'exécute dans un conteneur éphémère à l'intérieur de votre VPC. La sortie réseau est bloquée, les informations d'identification sont injectées par tâche et chaque action est enregistrée dans votre SIEM. Réservez une démo pour voir comment fonctionne le sandboxing de production sans configuration manuelle.