Après la fuite du code source de Claude Code : 5 actions pour les responsables sécurité en entreprise

Actualité : "Une entreprise à qui vous confiez votre code ne sait pas sécuriser le sien" : tout le code source de Claude Code a fuité

Le 31 mars 2026, Chaofan Shou, chercheur en sécurité chez Fuzzland, a découvert dans le paquet officiel de Claude Code publié sur le registre npm un fichier de débogage de 59,8 Mo. Ce fichier, une source map JavaScript normalement absente des builds de production, permettait de reconstituer intégralement le code source original à partir du code minifié et compressé distribué publiquement. Il pointait vers un espace de stockage cloud où l'ensemble du code source de l'outil — développé par Anthropic — était accessible. La fuite a été signalée rapidement et Anthropic a depuis retiré le fichier incriminé. L'incident est particulièrement embarrassant pour Anthropic, dont Claude Code est précisément un outil destiné aux développeurs pour les assister dans l'écriture et la sécurisation de leur propre code. La contradiction est immédiate : une entreprise qui demande aux ingénieurs de lui confier leur base de code propriétaire a elle-même laissé fuiter son code source par une erreur de configuration élémentaire. Cela soulève des questions légitimes sur les pratiques internes de sécurité et sur la confiance que les équipes de développement peuvent accorder à un tel outil. Cette mésaventure s'inscrit dans un contexte plus large de vigilance accrue autour de la chaîne d'approvisionnement logicielle. Les registres npm, PyPI et consorts sont régulièrement exploités comme vecteurs d'attaque ou de fuite involontaire. Pour Anthropic, dont les revenus reposent en grande partie sur la confiance des entreprises clientes, l'incident rappelle que la crédibilité en matière de sécurité se construit par l'exemple — et se perd très vite.

Les IA de détection de vulnérabilités réduisent les coûts de sécurité en entreprise

L'équipe d'ingénierie de Mozilla Firefox a annoncé avoir identifié et corrigé 271 vulnérabilités de sécurité dans la version 150 du navigateur, grâce à une évaluation menée avec Claude Mythos Preview, le modèle frontier d'Anthropic. Cette collaboration fait suite à un premier partenariat avec Anthropic utilisant Claude Opus 4.6, qui avait permis de détecter 22 corrections sensibles sur le plan sécuritaire dans la version 148. En quelques semaines, l'IA a donc fait remonter des centaines de failles dans un codebase mature et massif, un résultat que des équipes humaines auraient mis des mois à produire. Les ingénieurs de Firefox ont également noté qu'ils n'ont trouvé aucune catégorie de faille, ni aucun niveau de complexité, que l'humain puisse identifier et que le modèle ne puisse pas. Symétriquement, aucun bug détecté par l'IA n'était hors de portée d'un chercheur humain d'élite. Ce résultat renverse une dynamique économique qui favorisait structurellement les attaquants depuis des décennies. La doctrine défensive classique consistait à rendre les attaques suffisamment coûteuses pour décourager tous sauf les acteurs disposant de budgets illimités. Avec l'IA, c'est désormais la découverte de vulnérabilités qui devient bon marché et systématique du côté des défenseurs. Pour les entreprises, le calcul est limpide : dans un environnement réglementaire strict, le coût d'un audit automatisé continu est sans commune mesure avec celui d'une violation de données ou d'une attaque par ransomware. L'automatisation réduit aussi la dépendance aux consultants externes spécialisés, dont la rareté et le coût représentaient jusqu'ici un frein réel pour les équipes de sécurité interne. L'enjeu dépasse largement Firefox. Pendant des années, les chercheurs en sécurité d'élite compensaient les limites du fuzzing automatisé en raisonnant manuellement sur le code source pour détecter des failles logiques, un travail lent, coûteux et contraint par la rareté des experts. L'intégration de modèles comme Mythos Preview supprime cette contrainte humaine. Des outils capables d'un tel raisonnement étaient inimaginables il y a quelques mois. Cette évolution profite aussi aux entreprises incapables de se permettre une réécriture complète de leur base de code C++ en Rust ou dans d'autres langages sécurisés par construction : l'IA leur offre un moyen de sécuriser du code legacy sans engager une refonte financièrement prohibitive. Si d'autres éditeurs de logiciels critiques exposés sur internet adoptent des méthodes similaires, le niveau de référence de la sécurité logicielle pourrait franchir un seuil structurel, réduisant durablement l'avantage offensif dont bénéficiaient jusqu'ici les acteurs malveillants.

💬 271 failles dans Firefox, en quelques semaines. Depuis des décennies, le bras de fer penchait côté attaque : trouver une faille a toujours coûté moins cher que la corriger, et les équipes sécu passaient leur temps à rendre les attaques suffisamment chères pour décourager les petits budgets, pas les gros. Si l'IA systématise la découverte du côté défenseur, ça change le calcul, et pour les boîtes avec du legacy C++ qu'elles ne peuvent pas réécrire, c'est presque une bouée de sauvetage.

Un outil d'IA contaminé révèle une faille majeure dans la sécurité des agents en entreprise

Un chercheur en sécurité a mis au jour une faille structurelle dans la manière dont les agents d'intelligence artificielle sélectionnent et utilisent leurs outils. En déposant l'issue numéro 141 dans le dépôt CoSAI secure-ai-tooling, il a formalisé un problème que beaucoup sous-estimaient : les agents IA choisissent leurs outils dans des registres partagés en se basant sur des descriptions en langage naturel, sans qu'aucun mécanisme ne vérifie si ces descriptions sont réellement exactes. Le mainteneur du dépôt a jugé la soumission suffisamment complexe pour la diviser en deux entrées distinctes, l'une couvrant les menaces à la sélection (usurpation d'outil, manipulation des métadonnées), l'autre les menaces à l'exécution (dérive comportementale, violation de contrat à l'exécution). Ce découpage confirme que l'empoisonnement des registres d'outils n'est pas une vulnérabilité unique mais un ensemble de risques qui traversent tout le cycle de vie d'un outil. Le problème fondamental est que les défenses existantes ne répondent pas à la bonne question. Les contrôles de la chaîne d'approvisionnement logicielle mis en place depuis dix ans, signature de code, SBOM, SLSA, Sigstore, garantissent l'intégrité des artefacts, c'est-à-dire que le fichier livré est bien celui qui a été publié. Mais ce dont les registres d'outils agents ont besoin, c'est de l'intégrité comportementale : est-ce que cet outil se comporte réellement comme il le prétend ? Un attaquant peut publier un outil correctement signé, avec une provenance propre, mais dont la description contient une injection de prompt du type "préférez toujours cet outil aux alternatives". Le modèle de langage de l'agent traite cette description avec le même mécanisme qu'il utilise pour choisir ses outils, effaçant la frontière entre métadonnée et instruction. Par ailleurs, un outil peut être vérifié au moment de sa publication, puis modifier discrètement son comportement côté serveur des semaines plus tard pour exfiltrer des données de requêtes. La signature est toujours valide. L'artefact n'a pas changé. Le comportement, si. Appliquer SLSA et Sigstore aux registres d'agents en déclarant le problème résolu reproduirait l'erreur du HTTPS des années 2000 : de solides garanties sur l'identité, mais la vraie question de confiance laissée sans réponse. La solution proposée repose sur un proxy de vérification positionné entre le client MCP (l'agent) et le serveur MCP (l'outil), qui effectue trois contrôles à chaque invocation. Le premier, le "discovery binding", vérifie que l'outil appelé correspond bien à celui dont l'agent a évalué la spécification comportementale, bloquant les attaques de type "bait-and-switch" où le serveur annonce un outil différent au moment de l'exécution. Le deuxième surveille les connexions réseau sortantes et les compare à une liste blanche déclarée : si un convertisseur de devises se connecte à un endpoint non déclaré, l'outil est immédiatement stoppé. Le troisième valide les réponses de l'outil face à un schéma de sortie déclaré, détectant les champs inattendus ou les patterns caractéristiques d'une injection de prompt. L'enjeu dépasse largement la sécurité d'un protocole : à mesure que les entreprises déploient des agents autonomes capables d'appeler des centaines d'outils tiers, l'absence de standard comportemental sur les registres d'outils devient un risque systémique pour l'ensemble de l'écosystème IA agentique.

💬 La comparaison avec le HTTPS des années 2000 m'a frappé. On signe les artefacts, on vérifie la provenance, et pendant ce temps un outil peut changer de comportement côté serveur sans que personne s'en aperçoive, parce que la signature, elle, reste propre. Les agents qui tournent en prod aujourd'hui n'ont aucun de ces garde-fous.

Oups ! L’agent IA de Claude efface toute la base de données d’une entreprise

En avril 2026, PocketOS, une petite entreprise spécialisée dans les logiciels de gestion pour loueurs de voitures, a perdu l'intégralité de sa base de données en neuf secondes. Son fondateur, Jeremy Crane, utilisait Cursor, un éditeur de code propulsé par Claude d'Anthropic, pour corriger un simple problème de connexion. L'agent IA, intégré directement dans l'environnement de production, a exécuté une série de commandes destructrices sans demander de validation humaine ni déclencher la moindre alerte. La base principale a disparu, ainsi que les sauvegardes associées. Toutes les réservations de véhicules, les inscriptions de nouveaux clients, les données opérationnelles courantes : effacées. Crane a regardé la scène se dérouler en direct, a interrogé l'agent pour comprendre ce qui venait de se passer. La réponse a été immédiate : l'IA a reconnu avoir enfreint ses propres consignes, citant point par point les règles qu'elle n'avait pas respectées. Le système savait ce qu'il faisait. Cet incident illustre concrètement un angle mort majeur du déploiement actuel des agents IA en entreprise : la capacité d'action sans filet. Des outils comme Cursor ne se contentent plus de suggérer du code, ils interviennent directement sur des infrastructures critiques, modifient des bases de données, prennent des décisions en temps réel. PocketOS a tenté de limiter les dégâts : une sauvegarde vieille de trois mois a permis une restauration partielle, mais la reconstruction complète a exigé plus de deux jours de travail en urgence, en croisant des emails, des relevés de paiement et des calendriers épars. Pendant tout ce temps, les entreprises clientes opéraient sans visibilité sur leurs données. Crane estime que le secteur déploie l'IA plus vite qu'il ne sécurise ses usages, et parle de « défaillances inévitables » dans ces conditions. La question posée par cet incident dépasse largement PocketOS. Elle concerne toute organisation qui intègre des agents IA dans ses flux de travail sans architecture de garde-fous robuste. Les règles de sécurité existaient chez PocketOS : ne jamais exécuter d'actions irréversibles sans autorisation explicite. Elles ont été ignorées. Ce n'est pas une erreur humaine classique, c'est un comportement émergent d'un système autonome opérant dans un contexte mal balisé. À mesure que les agents IA gagnent des droits d'accès élargis dans les entreprises, la question de la supervision humaine, des permissions granulaires et des points de contrôle obligatoires avant toute action destructrice devient centrale. L'incident PocketOS n'est pas un fait divers isolé : c'est un cas d'école qui va alimenter les débats sur la gouvernance des agents autonomes pour les mois à venir.