CrdaN
Administrateur
PREMIUM
Marchand
Level 5
Level 4
Level 3
Level 2
Level 1
- 29 Avr. 2012
- 5,337
- 437
- 999
- Discord
- crdan
Claude Code 2.1.187 : empêcher un agent IA de lire vos secrets
Anthropic a publié Claude Code 2.1.187 le 23 juin 2026. Dans le changelog, une ligne mérite vraiment l’attention des devs qui utilisent des agents IA sur des projets réels : `sandbox.credentials`, un réglage prévu pour empêcher les commandes sandboxées de lire des fichiers d’identifiants et des variables d’environnement sensibles.
Source officielle :
Pourquoi c’est important ? Parce qu’un agent IA n’est plus juste une fenêtre de chat. Il peut lancer des commandes, lire des fichiers, appeler des outils MCP, modifier un repo, lancer des tests, générer des configs, ouvrir des logs et parfois travailler en arrière-plan. Si le projet contient des clés API, tokens Discord, accès SSH, cookies ou fichiers `.env`, il faut arrêter de compter uniquement sur “l’agent devrait faire attention”.
Sur un PC de dev classique, les secrets ne sont pas toujours rangés proprement. On trouve souvent :
Un humain sait généralement qu’il ne doit pas ouvrir certains fichiers. Un agent, lui, optimise pour résoudre la tâche. Si on lui dit “corrige l’intégration API”, il peut naturellement vouloir inspecter la config, les logs, les variables d’environnement et les scripts de lancement.
Ce n’est pas forcément malveillant. C’est juste un risque de surface : plus l’agent a accès à de contexte, plus il peut tomber sur des données qu’il ne devrait pas voir.
Le changelog indique que Claude Code 2.1.187 ajoute un réglage `sandbox.credentials` pour bloquer les commandes sandboxées lorsqu’elles tentent de lire des fichiers d’identifiants ou des variables d’environnement secrètes.
C’est le bon sens : si l’agent doit lancer un test, inspecter une erreur TypeScript ou corriger un composant, il n’a généralement pas besoin de lire les vraies clés de production. Il peut travailler avec :
L’idée n’est pas de rendre l’agent inutile. L’idée est de lui donner assez d’informations pour coder, sans lui donner les clés de la maison.
Sur le forum, beaucoup de membres touchent à des projets qui mélangent dev, gaming et automatisation : bots Discord, panels web, scripts de modération, outils marketplace, launchers, serveurs privés, outils de stats, scraping légal de patch notes, workflows IA, etc.
Dans ces projets, une clé exposée peut vite devenir un vrai problème :
Même si l’agent IA est fiable, un prompt mal cadré, un dépôt douteux ou un outil MCP trop permissif peut créer une fuite involontaire.
La phrase qui met en danger, c’est souvent : “Regarde tout le projet et corrige.”
C’est pratique, mais trop large. L’agent peut scanner des fichiers qui n’ont rien à voir avec la correction. Il peut aussi recopier un extrait sensible dans son raisonnement, dans un résumé, dans un commit message, dans un ticket ou dans une réponse.
Un meilleur prompt ressemble plutôt à ça :
Ce n’est pas de la paranoïa. C’est juste une hygiène de dev moderne.
Beaucoup de développeurs protègent les fichiers `.env`, mais oublient les variables déjà chargées dans le terminal. Si vous lancez un agent depuis un shell qui contient des secrets, il peut parfois y accéder via l’environnement, directement ou indirectement.
Exemples typiques :
Le bon réflexe : lancer l’agent dans un environnement réduit quand la tâche ne nécessite pas ces secrets. Si l’agent doit tester une intégration, fournissez une clé limitée, révocable et dédiée au test.
MCP rend les agents beaucoup plus utiles : accès à des docs, navigateur, GitHub, base de données, outils internes, recherche, etc. Mais chaque serveur MCP ajoute aussi une porte.
Si un MCP peut lire des fichiers locaux, accéder à GitHub ou interroger une base de données, il faut savoir :
Le combo à éviter : agent en mode large + MCP puissant + dépôt inconnu + secrets accessibles. C’est là qu’un simple “corrige ce bug” peut devenir une fuite silencieuse.
Un workflow propre ne donne jamais les secrets de production à un agent pour une tâche banale. On peut faire beaucoup mieux :
Si l’agent doit modifier du code qui touche à la production, il peut travailler sur le code et les tests sans voir les secrets de production. C’est ensuite à l’humain de déployer via un pipeline contrôlé.
La même mise à jour apporte d’autres points utiles : restrictions de modèles configurées par organisation, correction des sorties structurées avec `--json-schema`, timeout pour les appels MCP distants qui restent bloqués, et nettoyage de certaines inscriptions de worktrees d’agents tués.
Ce sont des détails, mais ils vont dans le même sens : rendre les agents plus prévisibles, plus contrôlables, et moins dangereux quand ils travaillent sur des vrais projets.
Claude Code 2.1.187 n’est pas seulement une mise à jour technique. C’est un rappel : plus les agents IA deviennent capables, plus il faut cadrer leur accès aux secrets.
Mon avis : chaque projet sérieux devrait avoir trois choses avant de laisser un agent travailler dessus : un `.env.example` propre, une règle claire “ne lis pas les secrets”, et une sandbox qui bloque réellement les credentials. Le gain de productivité ne vaut pas une clé API exposée ou un bot Discord compromis.
Anthropic a publié Claude Code 2.1.187 le 23 juin 2026. Dans le changelog, une ligne mérite vraiment l’attention des devs qui utilisent des agents IA sur des projets réels : `sandbox.credentials`, un réglage prévu pour empêcher les commandes sandboxées de lire des fichiers d’identifiants et des variables d’environnement sensibles.
Source officielle :
Vous devez etre connecte pour voir les liens.
Pourquoi c’est important ? Parce qu’un agent IA n’est plus juste une fenêtre de chat. Il peut lancer des commandes, lire des fichiers, appeler des outils MCP, modifier un repo, lancer des tests, générer des configs, ouvrir des logs et parfois travailler en arrière-plan. Si le projet contient des clés API, tokens Discord, accès SSH, cookies ou fichiers `.env`, il faut arrêter de compter uniquement sur “l’agent devrait faire attention”.
Le vrai problème : les secrets sont partout dans les projets dev
Sur un PC de dev classique, les secrets ne sont pas toujours rangés proprement. On trouve souvent :
- un fichier `.env` dans le projet ;
- un `.env.local` oublié ;
- des tokens dans l’historique shell ;
- une clé API dans un vieux script de test ;
- un token de bot Discord dans un fichier de config ;
- des credentials cloud dans un dossier utilisateur ;
- des logs qui contiennent des headers ou des URLs signées ;
- des backups du style `config.old`, `secrets.bak`, `prod.env`.
Un humain sait généralement qu’il ne doit pas ouvrir certains fichiers. Un agent, lui, optimise pour résoudre la tâche. Si on lui dit “corrige l’intégration API”, il peut naturellement vouloir inspecter la config, les logs, les variables d’environnement et les scripts de lancement.
Ce n’est pas forcément malveillant. C’est juste un risque de surface : plus l’agent a accès à de contexte, plus il peut tomber sur des données qu’il ne devrait pas voir.
Ce que change `sandbox.credentials`
Le changelog indique que Claude Code 2.1.187 ajoute un réglage `sandbox.credentials` pour bloquer les commandes sandboxées lorsqu’elles tentent de lire des fichiers d’identifiants ou des variables d’environnement secrètes.
C’est le bon sens : si l’agent doit lancer un test, inspecter une erreur TypeScript ou corriger un composant, il n’a généralement pas besoin de lire les vraies clés de production. Il peut travailler avec :
- des exemples de configuration ;
- un fichier `.env.example` ;
- des valeurs factices ;
- un token de test limité ;
- une documentation interne sans secret ;
- un log nettoyé.
L’idée n’est pas de rendre l’agent inutile. L’idée est de lui donner assez d’informations pour coder, sans lui donner les clés de la maison.
Pourquoi Cheat-Gam3 doit s’en soucier
Sur le forum, beaucoup de membres touchent à des projets qui mélangent dev, gaming et automatisation : bots Discord, panels web, scripts de modération, outils marketplace, launchers, serveurs privés, outils de stats, scraping légal de patch notes, workflows IA, etc.
Dans ces projets, une clé exposée peut vite devenir un vrai problème :
- bot Discord contrôlé par quelqu’un d’autre ;
- clé OpenAI/Anthropic consommée par erreur ;
- accès GitHub compromis ;
- token Steam ou session web retrouvé dans un log ;
- webhook Discord spammé ;
- base de données Supabase/Firebase ouverte ;
- serveur VPS manipulé via une clé SSH trop accessible.
Même si l’agent IA est fiable, un prompt mal cadré, un dépôt douteux ou un outil MCP trop permissif peut créer une fuite involontaire.
Le piège classique : “analyse ce bug avec tout le contexte”
La phrase qui met en danger, c’est souvent : “Regarde tout le projet et corrige.”
C’est pratique, mais trop large. L’agent peut scanner des fichiers qui n’ont rien à voir avec la correction. Il peut aussi recopier un extrait sensible dans son raisonnement, dans un résumé, dans un commit message, dans un ticket ou dans une réponse.
Un meilleur prompt ressemble plutôt à ça :
- “Analyse uniquement `src/`, `tests/` et `package.json`.”
- “Ignore `.env`, `secrets/`, `backups/` et les logs bruts.”
- “Si une valeur secrète manque, demande-moi une variable factice.”
- “Ne copie jamais de token dans ta réponse.”
- “Donne-moi un diff avant toute modification sensible.”
Ce n’est pas de la paranoïa. C’est juste une hygiène de dev moderne.
Les variables d’environnement méritent une attention spéciale
Beaucoup de développeurs protègent les fichiers `.env`, mais oublient les variables déjà chargées dans le terminal. Si vous lancez un agent depuis un shell qui contient des secrets, il peut parfois y accéder via l’environnement, directement ou indirectement.
Exemples typiques :
- `OPENAI_API_KEY`
- `ANTHROPIC_API_KEY`
- `GITHUB_TOKEN`
- `DISCORD_TOKEN`
- `DATABASE_URL`
- `AWS_ACCESS_KEY_ID`
- `SUPABASE_SERVICE_ROLE_KEY`
Le bon réflexe : lancer l’agent dans un environnement réduit quand la tâche ne nécessite pas ces secrets. Si l’agent doit tester une intégration, fournissez une clé limitée, révocable et dédiée au test.
MCP : puissant, mais pas magique côté sécurité
MCP rend les agents beaucoup plus utiles : accès à des docs, navigateur, GitHub, base de données, outils internes, recherche, etc. Mais chaque serveur MCP ajoute aussi une porte.
Si un MCP peut lire des fichiers locaux, accéder à GitHub ou interroger une base de données, il faut savoir :
- quels outils il expose ;
- quelles permissions il possède ;
- s’il peut lire des secrets ;
- s’il envoie des données à un service externe ;
- s’il est activé globalement ou seulement dans un projet ;
- comment couper son accès rapidement.
Le combo à éviter : agent en mode large + MCP puissant + dépôt inconnu + secrets accessibles. C’est là qu’un simple “corrige ce bug” peut devenir une fuite silencieuse.
Méthode simple : séparer dev, test et prod
Un workflow propre ne donne jamais les secrets de production à un agent pour une tâche banale. On peut faire beaucoup mieux :
- dev local : données factices, tokens jetables ;
- test/staging : accès limité, logs nettoyés ;
- production : jamais lu directement par l’agent, validation humaine obligatoire.
Si l’agent doit modifier du code qui touche à la production, il peut travailler sur le code et les tests sans voir les secrets de production. C’est ensuite à l’humain de déployer via un pipeline contrôlé.
À surveiller aussi dans la version 2.1.187
La même mise à jour apporte d’autres points utiles : restrictions de modèles configurées par organisation, correction des sorties structurées avec `--json-schema`, timeout pour les appels MCP distants qui restent bloqués, et nettoyage de certaines inscriptions de worktrees d’agents tués.
Ce sont des détails, mais ils vont dans le même sens : rendre les agents plus prévisibles, plus contrôlables, et moins dangereux quand ils travaillent sur des vrais projets.
Conclusion
Claude Code 2.1.187 n’est pas seulement une mise à jour technique. C’est un rappel : plus les agents IA deviennent capables, plus il faut cadrer leur accès aux secrets.
Mon avis : chaque projet sérieux devrait avoir trois choses avant de laisser un agent travailler dessus : un `.env.example` propre, une règle claire “ne lis pas les secrets”, et une sandbox qui bloque réellement les credentials. Le gain de productivité ne vaut pas une clé API exposée ou un bot Discord compromis.
