IA en ligne de commande : Claude Code, Cursor et Copilot CLI exposent vos secrets

Vos ingénieurs seniors tapent maintenant claude . dans le terminal

Il y a trois ans, le risque IA pour une équipe sécurité, c'était un développeur junior qui collait du code dans ChatGPT. Ce problème est largement résolu avec une extension navigateur et une politique écrite. Le nouveau problème est différent et bien plus difficile : vos ingénieurs les plus seniors exécutent des agents CLI qui lisent activement des fichiers sur le disque et les diffusent vers un modèle de frontière, souvent des centaines de fois par session.

Claude Code refactore un service. Le mode agent de Cursor réécrit un répertoire entier. Copilot CLI explique une erreur shell. Aider pratique le pair-programming. Codex CLI exécute une tâche longue. Tous ces outils font la même chose en arrière-plan : lire un fichier, l'envoyer au modèle, accepter un appel d'outil, lire d'autres fichiers. Le développeur ne voit jamais les octets quitter la machine.

Aucun problème, sauf quand l'une de ces lectures concerne .env, ~/.aws/credentials ou ~/.ssh/id_rsa. À ce moment-là, votre clé root AWS, votre clé Stripe production ou votre identité SSH de prod est dans le cache de contexte d'un fournisseur LLM, possiblement dans des logs éligibles à l'entraînement, possiblement dans la table d'audit d'un serveur MCP tiers.

La nouvelle norme : des agents lisant les fichiers sur les portables des développeurs

Regardez ce qu'un ingénieur typique d'une startup en série B a en marche en ce moment :

• Claude Code ouvert sur la racine d'un projet, avec permission de lire n'importe quel fichier du workspace.
• Cursor avec mode agent activé, indexant tout le dépôt pour le contexte.
• GitHub Copilot CLI répondant à des questions sur les commandes shell, ce qui veut dire qu'il lit ce que l'erreur shell référence.
• Aider dans un terminal latéral, parfois pointé sur ~/scripts ou ~/dotfiles.
• Un serveur MCP connectant l'un des outils ci-dessus à Postgres, GitHub, Linear ou un outil interne sur mesure.

Chacun est un véritable multiplicateur de productivité. Chacun est aussi un câble entre votre système de fichiers local et un LLM cloud. Vos contrôles existants — gitleaks en CI, secret scanning au push, une extension DLP navigateur — sont du mauvais côté de ce câble.

Cinq vecteurs de fuite reproductibles en cinq minutes

1. La lecture "serviable" du .env

La fuite la plus courante. Un développeur câble un nouveau service et demande de l'aide à l'agent :

$ claude
> aide-moi à configurer ce webhook Stripe, les clés sont dans .env

[Claude Code] Je vais lire votre fichier .env pour voir la configuration actuelle.
[lecture de .env]
[lecture de webhook_handler.py]

Le .env entier — incluant STRIPE_SECRET_KEY=sk_live_…, DATABASE_URL=postgres://user:password@… et la clé OpenAI que l'équipe avait oubliée — vient de partir en clair vers un modèle de frontière, plus dans le cache de contexte du fournisseur, plus dans tout log d'audit MCP sur le chemin.

2. Identifiants AWS pendant une session de debug

Un ingénieur débogue un script boto3 qui renvoie 403 sur S3. L'agent demande à inspecter les identifiants :

$ claude
> ce script reçoit AccessDenied sur s3:GetObject

[Claude Code] Laissez-moi vérifier votre configuration AWS.
[lecture de ~/.aws/credentials]
[lecture de ~/.aws/config]
[lecture de deploy.py]

~/.aws/credentials contient typiquement tous les profils que l'ingénieur a déjà utilisés : bac à sable perso, compte staging, parfois un rôle break-glass production. Tout atterrit dans le contexte du modèle.

3. Clés en dur dans le code — avec le contexte autour

Le pire, parce que la fuite paraît invisible. Un fichier contient une clé qui n'aurait jamais dû y être :

$ claude
> refactore billing_service.py pour extraire la logique Stripe

[Claude Code] Lecture de billing_service.py (412 lignes)…

La ligne 38 du fichier contient STRIPE_KEY = "sk_live_51H…". L'agent la voit, refactore autour, et — selon le modèle — peut la renvoyer telle quelle dans son diff. Même s'il ne le fait pas, le fichier complet avec cette clé est désormais dans les logs du fournisseur.

4. Archéologie via git log -p

Les agents adorent lancer git pour comprendre l'historique. C'est l'un des schémas les plus dommageables :

$ claude
> quand a-t-on changé le flow d'authentification pour la dernière fois ?

[Claude Code] Je vais vérifier l'historique git.
[exécution : git log -p --all -- src/auth/]

Cette commande remonte chaque patch jamais appliqué aux fichiers d'auth. L'identifiant que quelqu'un a commité en 2022, force-pushé hors de main, et jamais tourné parce que "il n'est plus dans l'arbre actuel" — il est toujours dans le reflog. git log -p --all le tend tel quel au modèle.

5. Clé SSH privée lors d'un problème de connexion

Un ingénieur n'arrive pas à se ssh sur un jumpbox. Il demande à l'agent :

$ claude
> mon ssh vers bastion-prod reste pendu, regarde ma config

[Claude Code] Je vais examiner votre configuration SSH.
[lecture de ~/.ssh/config]
[lecture de ~/.ssh/id_rsa]
[lecture de ~/.ssh/known_hosts]

La clé privée elle-même part au modèle. Que le modèle s'en "souvienne" ou non est la mauvaise question — les octets sont dans les logs de transit, les caches du fournisseur et tout proxy de logging entre les deux.

Pourquoi gitleaks et truffleHog ne vous sauvent pas

Votre équipe lance déjà gitleaks ou truffleHog en hook pre-commit ou en CI. C'est un bon contrôle. Il est aussi entièrement du mauvais côté du problème.

Ces outils se déclenchent quand vous tentez d'écrire un secret dans le contrôle de version. La fuite des agents CLI se produit quand vous lisez un secret sur le disque et le diffusez à un tiers. Quand gitleaks tourne, les octets sont dans le contexte d'un modèle de frontière depuis dix minutes. Le scanning pre-commit protège votre historique git. Il ne protège pas votre système de fichiers d'être exfiltré, un appel d'outil serviable à la fois.

La solution : scanner le chemin de lecture, pas seulement d'écriture

Le contrôle dont vous avez réellement besoin se trouve entre l'agent et le système de fichiers. Chaque fichier que l'agent ouvre et chaque commande shell qu'il exécute doit passer par un scanner avant que les octets n'atteignent le fournisseur du modèle. Zeuslock CLI l'implémente comme un wrapper :

zeuslock cli wrap claude-code -- claude-code .

Le wrapper intercepte les lectures de fichiers et invocations shell de l'agent, lance la pipeline de détection trois couches de Zeuslock (regex, NER, heuristiques contextuelles) sur les octets, et applique le mode de politique configuré par type de détection :

• Monitor — laisser passer la lecture mais journaliser la détection dans la Console Opérateur.
• Anonymize — remplacer le secret par un faux structurellement valide (un stub sk_live_ réaliste) pour que la logique du modèle fonctionne toujours, sans que la vraie clé ne sorte.
• Block — refuser la lecture entièrement et renvoyer une erreur claire à l'agent.

Le déploiement suit le même schéma que nous recommandons partout : Monitor deux semaines pour que les ingénieurs voient ce que font leurs agents, Anonymize trois semaines pour retirer les secrets vivants sans casser les workflows, puis Block à partir de la semaine six.

Trois contrôles supplémentaires qui s'ajoutent bien

Allowlists de répertoires

La plupart des agents CLI liront volontiers tout chemin que l'OS leur laisse atteindre. Configurez le wrapper pour que l'agent ne puisse lire qu'à l'intérieur de la racine du dépôt courant. ~/.env, ~/.aws, ~/.ssh et ~/Documents deviennent structurellement inatteignables. Cela ferme à soi seul les trois premiers vecteurs ci-dessus.

Allowlisting des serveurs MCP

MCP est l'endroit où ça se complique. Un serveur MCP Postgres mal configuré peut diffuser des lignes de production vers le modèle. Un serveur MCP interne sur mesure peut exposer Vault. Zeuslock CLI maintient une allowlist par utilisateur des serveurs MCP et intercepte les payloads JSON-RPC sur le câble — même pipeline de détection, mêmes trois modes, appliqués aux réponses tools/call avant qu'elles n'atteignent l'agent.

Modes de politique par outil

Vous voulez probablement des règles différentes pour Claude Code sur un portable développeur et pour un job Aider en CI. La Console Opérateur permet de scoper les politiques par binaire, par hôte et par environnement. Un runner CI peut être en Block par défaut sur tout ; une session interactive Claude Code peut anonymiser les secrets et monitorer les données personnelles.

Ce que les éditeurs font déjà — et où le trou subsiste

Honneur à qui de droit. Claude Code se cantonne par défaut au répertoire projet, demande avant de lire à l'extérieur, et alerte sur les noms de fichiers contenant des secrets. Le mode agent de Cursor a des garde-fous similaires. Copilot CLI scope ses lectures avec soin. Aucun de ces outils ne souhaite faire fuiter vos secrets.

Le trou, c'est l'humain dans la boucle. Quand l'agent demande "puis-je lire .env pour t'aider à configurer Stripe ?", l'ingénieur clique sur Autoriser parce que la demande est raisonnable dans le contexte. Quand l'ingénieur colle une stack trace qui contient un header Authorization, aucune permission n'est demandée. Quand git log -p remonte un identifiant de 2022, l'agent fait exactement ce qui lui était demandé.

Le sandboxing au niveau outil gère les cas évidents. Une couche DLP séparée est ce qui gère les cas où l'ingénieur a dit oui — alors qu'il n'aurait pas dû.

À faire ce trimestre

1. Inventoriez les agents CLI que vos ingénieurs utilisent réellement. Demandez sur #engineering, pas par sondage. La réponse inclura des outils dont la sécurité n'a jamais entendu parler.
2. Lancez zeuslock cli scan ~/ sur la machine d'un volontaire. Comptez les secrets qui seraient lisibles par n'importe quel agent ayant accès au répertoire home. Le chiffre sera inconfortable.
3. Wrappez un seul outil — commencez par celui qu'utilise le plus votre ingénieur le plus ancien. Mettez-le en Monitor pendant deux semaines.
4. Examinez les détections dans la Console Opérateur. Partagez le top cinq avec l'équipe ingénierie. La conversation sur le Block en semaine six s'écrit toute seule.
5. Étendez aux serveurs MCP, puis aux runners CI.

Le principe tient en une ligne : ajoutez un scanner de secrets sur le chemin de lecture, pas seulement sur le chemin d'écriture. Tous les autres contrôles DLP-IA que votre équipe achètera cette année en découlent. Conforme au RGPD et aligné sur les recommandations CNIL pour l'usage professionnel des modèles génératifs.

La marche à suivre pour le wrapper CLI est dans la documentation : Wrapper des agents IA avec Zeuslock CLI.