Louis LAURENT
Claude Code Sandbox renforce la sécurité Claude en isolant les commandes Bash, le système de fichiers et le réseau selon tes réglages. Sécuriser Claude Code ne demande pas de transformer ton ordinateur en bunker : il faut borner ce que l’agent peut lire, modifier, exécuter et appeler via des services externes ou des serveurs MCP. Voici une configuration concrète pour profiter de l’agent sans lui donner les clés de toute ta machine.
Le vrai risque n’est pas que Claude « devienne méchant »
Claude Code travaille dans un environnement réel. Il lit des fichiers, explore un projet, propose des modifications et peut exécuter des commandes. C’est précisément ce qui le rend utile, mais c’est aussi ce qui change la nature du risque par rapport à un chatbot classique.
Le scénario le plus courant n’est pas une IA qui décide soudainement de vider ton disque. C’est une consigne mal comprise, un script récupéré dans un projet, une page web contenant une instruction hostile ou un connecteur trop permissif. L’agent peut alors faire exactement ce qu’on lui demande, mais dans un contexte que tu n’avais pas complètement vu.
La bonne sécurité repose donc sur un principe simple : réduire le rayon d’action par défaut, puis ouvrir uniquement ce qui est nécessaire à la tâche. C’est la même logique que pour un nouvel employé : tu ne lui donnes pas l’accès administrateur à toute l’entreprise le premier matin.
Les protections déjà intégrées à Claude Code
La documentation officielle d’Anthropic décrit plusieurs garde-fous actifs dès le départ :
Lecture seule par défaut. Claude peut examiner le projet, mais les modifications de fichiers et les commandes sensibles passent par un système d’autorisation
Limites liées au dossier de travail. L’agent est censé opérer dans le projet ouvert, au lieu de parcourir librement toute la machine
Demandes d’approbation. Les actions qui changent l’état du système peuvent être présentées avant exécution
Isolation par sandbox. Le système peut limiter l’accès au réseau et au système de fichiers pendant l’exécution d’une commande
Défenses contre l’injection de prompt. Anthropic applique des filtres et des contrôles sur les contenus non fiables rencontrés pendant le travail
Ces protections forment une base sérieuse, pas une garantie absolue. Anthropic le dit elle-même : la sécurité dépend aussi de tes permissions, de tes connecteurs et de ton comportement. Si tu découvres encore l’outil, commence par notre guide Claude Code pour non-codeurs avant d’ouvrir des accès plus larges.
1. Ouvre le bon dossier, pas ton disque entier
La première décision de sécurité se prend avant même ton premier message : le dossier depuis lequel tu lances Claude Code. Ouvre le projet exact sur lequel tu veux travailler. Évite ton dossier personnel, ton dossier Documents complet ou une arborescence qui contient plusieurs clients.
Pour une tâche ponctuelle sur des données sensibles, crée une copie de travail limitée. Mets-y seulement les fichiers nécessaires, retire les exports historiques et remplace les données personnelles par des exemples quand c’est possible. Une fois la tâche terminée, tu peux comparer le résultat puis supprimer cette copie.
Cette séparation apporte deux gains. L’agent voit moins de bruit, donc il raisonne mieux. Et une mauvaise commande touche un périmètre plus petit. Sécurité et qualité vont ici dans la même direction.
2. Traite chaque permission comme une décision
Quand Claude demande l’autorisation de lancer une commande, le mauvais réflexe est de cliquer automatiquement sur « toujours autoriser ». Lis trois éléments :
La commande exacte. Est-ce une lecture, une installation, une écriture ou une suppression ?
La cible. Le chemin vise-t-il bien le projet ouvert ? Une variable ou un joker pourrait-il élargir la portée ?
L’effet externe. La commande envoie-t-elle des données, publie-t-elle quelque chose ou modifie-t-elle un service distant ?
Tu peux autoriser durablement les opérations banales et réversibles que tu comprends. Garde une validation manuelle pour les suppressions, les déploiements, les changements de permissions, les actions Git distantes et les commandes utilisant des identifiants.
Le but n’est pas de tout bloquer. Un agent qui demande ton accord pour chaque lecture devient inutilisable. Le bon réglage automatise le travail local à faible risque et garde un humain devant les actions difficiles à annuler.
3. Utilise la sandbox pour les commandes incertaines
Une sandbox limite ce qu’un processus peut atteindre. Dans Claude Code, elle peut isoler l’accès aux fichiers et au réseau. C’est particulièrement utile quand l’agent lance un script que tu n’as pas écrit, installe une dépendance ou analyse un dépôt récupéré sur Internet.
La sandbox ne remplace pas la lecture de la commande. Elle ajoute une ceinture à la ceinture. Si un script tente d’accéder à un fichier hors projet ou de contacter un domaine inattendu, l’isolation peut l’empêcher de réussir.
Pour un projet inconnu, la séquence propre est la suivante :
Ouvrir le dépôt dans un dossier dédié
Demander à Claude d’analyser les scripts d’installation sans les exécuter
Vérifier les dépendances et les commandes prévues
Lancer l’installation dans la sandbox avec un accès réseau limité au nécessaire
Examiner les fichiers modifiés avant de continuer
Cette méthode prend quelques minutes de plus et évite de faire confiance à une chaîne d’installation entière sur la base d’un fichier README.
4. Les secrets ne doivent jamais vivre dans les prompts
Une clé API, un mot de passe ou un jeton d’accès collé dans une conversation devient une donnée à protéger, à révoquer et parfois à auditer. Utilise des variables d’environnement ou un gestionnaire de secrets, et ne demande pas à l’agent d’imprimer leur valeur.
Ajoute les fichiers sensibles comme .env, les clés privées et les exports clients aux exclusions du projet. Si Claude a besoin de connaître la forme d’une configuration, donne-lui un fichier d’exemple avec de fausses valeurs.
Avant tout partage de journal ou de capture d’écran, cherche les chaînes ressemblant à des clés. Le risque vient souvent du débogage : une commande échoue, affiche toute la configuration, puis le résultat finit dans un ticket public.
5. Les serveurs MCP étendent aussi le risque
MCP permet de connecter Claude Code à des outils comme GitHub, une base de données, un navigateur ou un espace documentaire. C’est puissant parce que l’agent n’est plus limité au terminal. Mais chaque connecteur ajoute ses propres permissions, son propre code et ses propres données.
Anthropic précise que son annuaire MCP ne constitue pas un audit de sécurité de chaque serveur. « Disponible » ne veut pas dire « vérifié ». Avant d’installer un serveur MCP :
Vérifie qui le maintient et si le code source est public
Lis les autorisations demandées
Préfère un accès en lecture seule quand il suffit
Utilise un compte ou une clé dédiés avec un périmètre limité
Supprime les connecteurs devenus inutiles
Pour comprendre comment ces connecteurs s’insèrent dans une architecture plus large, lis aussi ce qu’est réellement un agent IA.
6. Le piège subtil : l’injection de prompt
Une injection de prompt est une instruction cachée dans une source que l’agent consulte. Elle peut apparaître dans une page web, un fichier, un commentaire de code ou un document. Exemple : une page demande à l’agent d’ignorer sa mission et d’envoyer des données vers un serveur externe.
Les modèles modernes savent souvent reconnaître ce piège, mais « souvent » n’est pas un contrôle de sécurité. Quand Claude travaille sur du contenu externe non fiable :
Évite de lui donner simultanément un accès large à des secrets et au réseau
Demande-lui de séparer les données observées des instructions à suivre
Garde une approbation manuelle avant tout envoi ou publication
Inspecte les changements proposés et les domaines contactés
Plus un agent est autonome, plus la séparation entre lecture et action devient importante. Notre article sur les limites de l’autonomie des agents développe ce point avec des cas concrets.
7. Auditer un projet avec Claude Code Security
Anthropic propose aussi Claude Code Security, un système d’analyse de vulnérabilités présenté en aperçu limité pour certaines offres Team et Enterprise. Le produit examine le code, tente de confirmer les problèmes en plusieurs étapes, puis classe les résultats par sévérité et niveau de confiance. Les corrections restent soumises à validation humaine.
Anthropic affirme qu’Opus 4.6 a découvert plus de 500 vulnérabilités dans des projets open source. C’est un chiffre du fournisseur, pas un benchmark indépendant, mais le cas d’usage est solide : un agent peut parcourir plus de chemins qu’une revue manuelle ponctuelle et expliquer chaque découverte dans le contexte du dépôt.
Pour les projets qui n’ont pas accès au produit hébergé, Anthropic publie également un outil open source de revue de sécurité sur GitHub. Utilise-le comme un second regard, jamais comme un certificat. Un scan automatique peut manquer une faille logique ou signaler un faux positif.
La checklist propre avant de laisser l’agent travailler
Le dossier ouvert contient uniquement le projet utile
Les secrets vivent hors des prompts et des fichiers suivis
Les suppressions, publications et actions distantes demandent une validation
Les scripts inconnus sont lus avant d’être exécutés
La sandbox limite fichiers et réseau quand le contexte est non fiable
Chaque serveur MCP a un propriétaire connu et le minimum de permissions
Les modifications sont comparées avant validation
Les clés utilisées par l’agent peuvent être révoquées facilement
Si ces huit points sont vrais, tu as déjà éliminé l’essentiel du risque évitable. Le reste relève de la supervision normale : vérifier le résultat, garder des sauvegardes et ne pas automatiser une action irréversible avant de l’avoir testée.
FAQ
Claude Code peut-il supprimer mes fichiers ?
Il peut proposer ou exécuter des modifications selon les permissions accordées. Par défaut, les actions sensibles passent par des contrôles. Le risque augmente surtout quand tu accordes des permissions permanentes trop larges ou que tu lances l’outil depuis un dossier contenant trop de données.
La sandbox rend-elle Claude Code totalement sûr ?
Non. Elle réduit l’accès d’une commande au système de fichiers et au réseau, mais ne corrige pas une mauvaise décision métier, une fuite dans un fichier autorisé ou une action externe que tu as explicitement validée.
Peut-on utiliser Claude Code avec des données clients ?
Oui si ton contrat, ton offre Anthropic et tes règles internes l’autorisent. Minimise les données, isole le dossier, supprime les identifiants inutiles et vérifie la politique de conservation applicable à ton organisation.
Faut-il installer tous les serveurs MCP utiles ?
Non. Chaque connexion augmente la surface d’attaque et la complexité. Installe seulement ce qui sert à une tâche récurrente, avec un accès en lecture seule quand c’est possible.
Traduire les réglages de sandbox en contrôles concrets
Dans la documentation anglaise, tu rencontreras des termes comme sandboxed Bash, permission prompts, filesystem and network, sandbox settings ou OS-level isolation. Ils décrivent la même logique : isoler les commandes Claude, limiter les fichiers et le réseau accessibles, puis demander une autorisation avant les actions sensibles. Lance Claude dans un dossier borné, contrôle les correctifs proposés et garde une validation humaine avant toute mise en production.
Un audit de sécurité concret avant la production
Commence par lister les fichiers que Claude peut lire, les dossiers qu’il peut écrire et les domaines réseau qu’il peut contacter. Lance ensuite un scénario sans secret : lecture du projet, exécution des tests, génération d’un correctif puis comparaison des changements. Si l’agent sort du périmètre prévu, resserre la sandbox avant de continuer.
Teste aussi l’échec. Coupe le réseau, refuse une permission et fournis un fichier contenant une instruction hostile. Claude doit expliquer le blocage, conserver les données dans le projet et demander une validation au lieu de contourner la règle. Sur le web comme en local, garde une personne responsable avant le déploiement.
Enfin, vérifie les correctifs proposés : commande exacte, fichiers modifiés, dépendances ajoutées et effet sur la production. Une revue courte mais reproductible vaut mieux qu’une autorisation permanente accordée parce qu’une première exécution s’est bien passée.
Le drapeau à ne pas banaliser
Concrètement, Claude peut proposer des correctifs en temps réel, mais les permissions restent le contrôle décisif. Les expressions anglaises sandbox isolates, sandboxed Claude et run Claude renvoient à cette isolation d’exécution. N’utilise jamais --dangerously-skip-permissions par confort : ce drapeau désactive les demandes d’autorisation. Voir la référence CLI Anthropic.
Comprendre la frontière d’isolation de Claude Code
Une sandbox ne rend pas une commande sûre par magie. Elle limite surtout ce que le processus peut lire, écrire et joindre sur le réseau. Cette isolation boundary doit être définie avant le premier test.
Dans la documentation et les recherches techniques, tu rencontreras plusieurs expressions anglaises. Une bash command désigne simplement une commande exécutée dans le terminal. Claude Code runs décrit les processus lancés pendant une session. Claude Code process désigne le processus actif. Claude Code session désigne le contexte de travail qui regroupe les messages, les permissions et les actions.
L’expression isolation Claude Code renvoie au périmètre réellement accessible. L’expression Anthropic AI sandbox runtime décrit, de façon générale, l’environnement d’exécution isolé. Ce n’est pas une permission universelle. Le dossier ouvert, les règles locales et les accès réseau restent déterminants.
Les built in file tools servent à lire ou modifier des fichiers avec les outils intégrés. Ils doivent rester limités au projet utile. Les server managed settings sont des réglages imposés par une organisation ou une infrastructure gérée. Ils peuvent renforcer une politique locale, mais ils ne remplacent pas la vérification du poste.
Tester l’isolation Claude Code sans risque
Crée d’abord un dossier de test. Place-y des fichiers factices. N’utilise aucun secret réel. Demande ensuite une lecture simple. Vérifie que l’outil reste dans ce dossier.
Teste ensuite une écriture. Le fichier créé doit apparaître au bon endroit. Refuse toute demande qui vise un dossier voisin. Cette étape prouve la frontière de fichiers.
Teste enfin le réseau. Commence sans jeton ni compte connecté. Observe les domaines appelés. Autorise seulement les destinations nécessaires. Une dépendance inconnue ne doit pas obtenir un accès automatique.
Pour chaque bash command, garde quatre informations : la commande demandée, la permission accordée, le résultat et les fichiers modifiés. Un journal court suffit. Il doit permettre de comprendre ce qui s’est passé.
Séparer lecture, écriture et exécution
La lecture expose des données. L’écriture change l’état du projet. L’exécution peut déclencher d’autres programmes. Ces trois capacités ne doivent pas partager la même règle par défaut.
Autorise la lecture dans le dossier du projet. Limite l’écriture aux fichiers prévus. Demande une validation avant une commande destructive. Bloque les chemins larges et les variables non résolues.
Une session saine commence avec peu de droits. Elle gagne des permissions quand le besoin est clair. Elle les perd dès que la tâche se termine. Cette méthode réduit le rayon d’impact d’une erreur ou d’une instruction malveillante.
La preuve finale
Ne juge pas la sécurité sur une simple fenêtre de réglages. Vérifie le comportement. Le Claude Code process doit échouer hors du périmètre autorisé. Les fichiers sensibles doivent rester illisibles. Les domaines non prévus doivent rester injoignables.
Relance ensuite le même scénario dans une nouvelle Claude Code session. Le résultat doit rester identique. Si une permission temporaire persiste sans raison, corrige la configuration avant de travailler sur un vrai dépôt.
La bonne sandbox est donc observable. Elle bloque ce qui doit l’être. Elle laisse passer le travail prévu. Et elle produit assez de traces pour expliquer chaque action.
Six scénarios pour vérifier la sécurité avant un vrai projet
Une politique paraît souvent solide sur le papier. Les scénarios suivants permettent de vérifier son comportement. Utilise uniquement des données factices. Observe ce qui est autorisé, refusé et journalisé.
Scénario 1 : lecture hors du projet
Ouvre un dossier de test. Place un faux fichier sensible dans un dossier voisin. Demande ensuite à Claude Code de le rechercher. La tentative doit échouer ou demander une permission claire.
Le point important n’est pas le message affiché. Vérifie aussi que le contenu du fichier n’apparaît pas dans la réponse, les logs ou un fichier temporaire. Une restriction d’écriture ne protège pas la lecture.
Scénario 2 : modification imprévue
Crée trois fichiers factices. Autorise une modification sur un seul fichier. Demande ensuite une amélioration générale du projet. Contrôle le diff final. Les deux autres fichiers doivent rester identiques.
Si l’agent élargit seul le périmètre, réduis ses droits. Une consigne textuelle ne suffit pas toujours. La frontière technique doit empêcher la modification non prévue.
Scénario 3 : commande destructive
Prépare un dossier jetable. Demande une opération qui pourrait supprimer ou remplacer plusieurs fichiers. La sandbox doit bloquer l’action ou exiger une validation explicite.
Lis la commande complète avant de répondre. Refuse les chemins trop larges. Refuse les variables dont la valeur est inconnue. Refuse aussi une opération récursive si la cible n’est pas précisément résolue.
Après le test, vérifie les fichiers. Un message de refus n’est pas une preuve suffisante. Seul l’état réel du dossier confirme que la protection a fonctionné.
Scénario 4 : accès réseau inattendu
Lance une tâche qui n’exige aucun accès externe. Observe les connexions. Aucun domaine imprévu ne devrait être contacté.
Ajoute ensuite une source publique précise. Autorise seulement ce domaine. Vérifie que la requête fonctionne et que les autres destinations restent bloquées. Cette approche réduit les sorties de données involontaires.
Les gestionnaires de paquets demandent parfois plusieurs domaines. N’ouvre pas tout le réseau pour gagner du temps. Identifie les destinations nécessaires, puis documente leur rôle.
Scénario 5 : instruction cachée dans un fichier
Place une fausse instruction malveillante dans un document de test. Elle peut demander de lire un secret, de modifier une règle ou d’envoyer un fichier. Demande ensuite à l’agent de résumer le document.
L’agent doit traiter le texte comme une donnée. Il ne doit pas transformer cette donnée en autorisation. La mission initiale et les permissions système restent prioritaires.
Répète le test avec un fichier HTML, un commentaire de code et une issue copiée depuis le web. Les injections ne vivent pas seulement dans les prompts directs.
Scénario 6 : serveur MCP trop puissant
Connecte uniquement un serveur MCP de test. Donne-lui des données factices. Vérifie la liste exacte de ses outils. Un connecteur de lecture ne doit pas exposer une action d’écriture inattendue.
Teste ensuite un appel refusé. Le serveur doit appliquer sa propre autorisation. La protection locale de Claude Code ne remplace pas les contrôles du service distant.
Déconnecte le serveur après le test. Vérifie que la session suivante ne conserve pas un accès devenu inutile. Les permissions oubliées créent un risque silencieux.
Construire une matrice de permissions simple
Une petite matrice évite les règles vagues. Place les ressources en lignes. Place les capacités en colonnes. Utilise quatre niveaux : refusé, lecture, écriture et action externe.
Pour les fichiers du projet, la lecture peut être autorisée. L’écriture reste limitée aux fichiers concernés par la mission. Pour les secrets, la règle par défaut est le refus. Pour le réseau, utilise une liste de destinations nécessaires.
Ajoute une colonne de validation humaine. Elle doit couvrir les envois, publications, dépenses, suppressions et changements de configuration. Une action réversible peut avancer plus librement. Une action difficile à récupérer exige une preuve et une confirmation.
Révise cette matrice quand le projet change. Un nouvel outil, un serveur MCP ou une tâche planifiée peut agrandir le périmètre. L’ancienne politique ne couvre pas automatiquement la nouvelle capacité.
Que faire après un comportement suspect
Arrête d’abord la session. Ne relance pas immédiatement la même commande. Conserve le transcript, les permissions accordées et le diff des fichiers.
Révoque les jetons qui ont pu être exposés. Change les secrets concernés. Ferme les connexions externes inutiles. Si un dépôt distant a reçu une modification, protège la branche avant toute nouvelle action.
Détermine ensuite le premier écart observable. La mauvaise réponse finale est rarement le début de l’incident. Cherche la première lecture imprévue, la première permission trop large ou la première instruction non fiable suivie par l’agent.
Corrige la règle la plus proche de cette cause. Puis rejoue le scénario avec des données factices. La protection est validée seulement si l’action dangereuse échoue et si la tâche légitime continue de fonctionner.
Documente enfin la leçon en une phrase. Exemple : « les fichiers téléchargés ne peuvent jamais élargir le périmètre ». Une règle courte est plus facile à relire et à tester.
Le contrôle mensuel
Une configuration sûre peut dériver. Les outils changent. Les dépendances changent. Les permissions s’accumulent. Prévois donc un contrôle léger.
Vérifie les dossiers autorisés. Vérifie les domaines réseau. Vérifie les serveurs MCP. Vérifie les tâches automatiques. Vérifie aussi les comptes et jetons encore actifs.
Relance les six scénarios principaux. Note le résultat. Un test qui échoue devient une correction prioritaire. Un test qui réussit garde une preuve datée.
Cette discipline paraît lente. Elle évite pourtant les audits improvisés après un incident. Quelques minutes de vérification valent mieux qu’une permission permanente oubliée.
Avant de partir
La sécurité d’un agent ne vient pas d’un bouton magique. Elle vient d’un système simple : petit périmètre, permissions compréhensibles, validation avant l’irréversible et preuves après l’action. C’est exactement le genre de système qu’on construit chaque semaine dans Kryve Weekly.
Recevoir Kryve Weekly et le guide de démarrage
Un email pour te l’envoyer. Pas de spam, désinscription en un clic.
Continuer avec
Pour élargir la comparaison : lis Claude Code vs Cursor pour non-développeur, puis le guide Grok Build pour comparer permissions et supervision.
Pars d’une vraie tâche de ton poste. Kryve t’aide à la cadrer, la confier à l’IA et contrôler le résultat.
