Confidentialité Claude Code : que révèle l’incident ?

Le scénario décrit par Anthropic

Dans un commentaire, un contributeur d'Anthropic indique que ce n'était pas une fonctionnalité prévue pour partager des adresses e-mail. L'idée serait plutôt la suivante : un site comme Wikipédia demande aux clients automatisés d'indiquer une adresse de contact dans leur User-Agent. L'utilisateur demande une recherche, le modèle lance une commande curl, et l'agent pourrait alors inclure l'adresse fournie par l'utilisateur dans l'en-tête.

C'est là que le risque devient intéressant. Une règle affichée par un site peut être interprétée par le modèle comme une instruction à appliquer, alors qu'elle ne constitue pas une autorisation de transmettre une donnée personnelle. Résultat : une commande techniquement valide, mais problématique du point de vue de la confidentialité.

Ce qui est établi, et ce qui ne l'est pas

D'après les échanges du dépôt, Anthropic dit avoir ajouté un module intégré nommé cc-plugin-privacy, activé par défaut à partir de la version 2.1.317, pour bloquer ce type de comportement de façon déterministe. Le commentaire précise aussi que le module peut être désactivé via la commande /plugins, et que son code source devait être rendu accessible. Un contributeur indique ensuite que le code est disponible.

De son côté, l'auteur du signalement - qui utilise la version 2.1.318 - explique ne pas voir le module dans la liste des plugins. Cet écart entre l'annonce et l'expérience rapportée mérite d'être vérifié : « annoncé », « présent », et « activé » ne sont pas toujours la même chose. Avec les seules informations disponibles, on ne peut pas conclure que toutes les versions et configurations étaient protégées de la même manière.

À retenir : il s'agit d'un signalement de divulgation potentielle, suivi d'une annonce d'un contrôle logiciel. On ne dispose pas d'éléments pour affirmer que toutes les installations ont transmis une adresse, ni que cette transmission explique, à elle seule, les courriels indésirables rapportés.

Une requête réseau expose plus que son contenu

Quand un agent appelle un service Web, le corps de la requête n'est qu'une partie de ce qui circule. Les en-têtes peuvent contenir des informations d'identification ou de contexte. Le serveur destinataire peut aussi enregistrer l'adresse IP, l'heure de la requête et d'autres données techniques. Rien de tout cela n'est spécifique à Claude Code : tout logiciel qui accède à Internet laisse des traces.

Ce qui change, ici, c'est le côté « piloté par un modèle ». Le développeur n'a pas forcément écrit la requête complète. L'agent peut générer une commande à partir d'une consigne, d'une page consultée ou du contexte de la session. Une adresse qui traîne dans une configuration, un fichier de projet ou un échange précédent peut alors se retrouver, par accident, dans une requête construite à la volée.

Pourquoi le consentement ne peut pas être implicite

Une consigne comme « recherchez cette information sur Wikipédia » autorise la recherche. Elle ne donne pas automatiquement l'autorisation de transmettre l'adresse personnelle si le site la « demande ». Il faut séparer l'autorisation de faire la tâche de celle de divulguer une information identifiante.

Cette approche colle avec les principes européens de protection des données, notamment la minimisation : ne collecter et ne transmettre que ce qui est nécessaire pour une finalité précise. C'est aussi utile en entreprise, même quand on ne fait pas forcément une analyse juridique complète. Une adresse professionnelle, un nom de client ou un identifiant interne peuvent être sensibles selon le contexte.

Un bon système ne demande donc pas au modèle d'être « juste prudent ». Il limite ce que l'agent peut accéder, bloque certains envois, ou demande une validation avant transmission. La consigne en langage naturel peut aider, mais elle ne devrait pas remplacer ces garde-fous.

Le bon niveau de défense

Pour un agent capable d'exécuter des commandes, la protection devrait exister à plusieurs niveaux :

• Au niveau du modèle, des règles interdisent de transmettre des données personnelles sans accord explicite.
• Au niveau du harnais, des mécanismes détectent ou bloquent les commandes et en-têtes risqués avant exécution.
• Au niveau du réseau, un proxy, un pare-feu ou une liste de destinations autorisées limite les sorties possibles.
• Au niveau de l'exploitation, des journaux aident à comprendre ce qui a été envoyé, sans conserver inutilement des données sensibles.

Ces couches ne coûtent pas pareil. Pour un usage individuel, vérifier les plugins et séparer les données peut réduire le risque. En contexte professionnel, les contrôles qui surveillent et limitent les sorties réseau sont souvent plus fiables qu'une consigne adressée au modèle.

Le contrôle doit être visible et vérifiable

L'écart entre la version annoncée comme protégée et l'absence du module dans /plugins rappelle une exigence simple : un utilisateur doit pouvoir confirmer l'état d'un contrôle. Est-il installé ? activé ? désactivable ? appliqué exactement à la commande qui sera exécutée ?

En pratique, une équipe devrait prévoir une procédure de vérification après chaque mise à jour. Si le contrôle n'apparaît pas, si sa portée est floue, ou si sa désactivation n'est pas clairement signalée, il faut le considérer comme non vérifié. Ce n'est pas une accusation contre l'éditeur : c'est juste une règle d'exploitation.

Une checklist avant de le laisser naviguer

1. Vérifiez la version et les contrôles actifs. Regardez les paramètres et la documentation de la version installée. Ici, Anthropic indique que le module cc-plugin-privacy est activé par défaut depuis la version 2.1.317, mais il faut confirmer ce qui est réellement en place chez vous.
2. Évitez de rendre les données personnelles accessibles sans raison. Ne mettez pas d'adresse, de jeton d'accès ou de secret dans des fichiers que l'agent peut lire s'ils ne sont pas nécessaires à la tâche.
3. Séparez les identifiants. Si un service demande une adresse de contact technique, utilisez une adresse dédiée quand c'est possible, plutôt que l'adresse personnelle d'un développeur.
4. Limitez les destinations réseau. Pour des tâches sensibles, autorisez seulement les domaines nécessaires via un proxy et une politique réseau adaptée.
5. Demandez une approbation avant toute transmission inhabituelle. Si une requête inclut une adresse, un jeton ou un extrait de configuration, faites-la relire avant exécution.
6. Testez les cas de refus. Vérifiez ce qui se passe quand un site demande un e-mail dans le User-Agent. L'attendu : ne rien envoyer sans autorisation explicite.

Une consigne écrite dans un fichier de configuration peut renforcer ces règles. Par exemple : demander à l'agent de ne jamais inclure votre adresse dans un en-tête et de s'arrêter pour demander une validation si un site l'exige. Utile, oui, mais pas suffisant si la même adresse reste accessible et que l'agent peut exécuter des commandes réseau sans frein.

Choisir le niveau de contrôle selon le contexte

Pour une recherche publique sans données sensibles, un contrôle intégré et une vérification ponctuelle peuvent suffire. Pour un projet qui manipule un dépôt client, des données personnelles, ou des contraintes contractuelles, les sorties réseau doivent être limitées et traçables. Une machine virtuelle isolée, un conteneur sans accès aux secrets ou un environnement de développement dédié réduit la portée d'une erreur.

L'inconvénient existe : ces restrictions peuvent interrompre des tâches légitimes, demander des validations répétées et ralentir l'exécution. Donc, l'objectif n'est pas de couper Internet « par principe ». Il faut calibrer les permissions selon la sensibilité des données et le coût d'une divulgation. Une tâche de documentation publique ne ressemble pas à une intervention sur un dépôt contenant des informations clients.

Règle pratique : si une action enverrait une donnée identifiable avec un script écrit par un développeur, exigez au minimum le même niveau de vérification lorsqu'elle est proposée par un agent.