Ils filtrent le code Claude et révèlent KAIROS : l'agent persistant qui pourrait opérer en arrière-plan

L'incident passé dans Anthropic - où une partie du code source de son assistant de programmation Claude Code est devenue accessible publiquement - rappelle que même les entreprises les plus axées sur l'intelligence artificielle ne sont pas exemptées des erreurs humaines avec des conséquences puissantes. Selon l'entreprise elle-même, la libération était le résultat d'une défaillance dans l'emballage et non d'une attaque externe, et ils veillent à ce qu'aucune identification ou données sensibles du client ne soient affichées. Cependant, la portée du matériau filtré et la vitesse avec laquelle il a été virulué ont montré clairement que les risques techniques et de réputation sont réels et de grande ampleur. Pour ceux qui veulent revoir la couverture médiatique et les déclarations officielles, vous pouvez commencer par les sources reconnues comme CNBC et Fortune.

Ce qui a été publié à tort était un paquet npm qui comprenait une carte source capable de révéler la plupart du code source: des milliers de fichiers TypeScript et des centaines de milliers de lignes de code. La communauté technique a rapidement partagé et cloné ce matériel, et en quelques heures une marée de fourches, d'étoiles et d'analyses publiques a été observée. Ceux qui veulent curioser les dépôts et les recherches dans GitHub peuvent explorer les résultats connexes dans C'est pas vrai., et la conversation sur les médias sociaux peut être suivie de X (anciennement Twitter).

Au-delà du morbo, l'intérêt n'est pas occasionnel : le code filtré offre une carte détaillée du design interne de Claude Code. Les développeurs et les concurrents peuvent étudier comment Anthropic gère la mémoire de la session pour atténuer les limites du contexte, comment l'orchestre appelle des modèles et des outils auxiliaires, et même comment l'entreprise pense ses agents persistants qui accomplissent des tâches en arrière-plan. Certains fragments - déjà décrits publiquement par des personnes qui ont examiné les fichiers - mentionnent des modules pour l'exécution de commandes bash, la communication bidirectionnelle avec les extensions IDE, et des mécanismes pour lancer des "sous-agents" qui collaborent dans des tâches complexes.

Parmi les pièces les plus frappantes figure une fonctionnalité qui, par nom dans les fichiers, a été décrite comme KAIROS : un agent persistant capable d'agir de manière proactive, de corriger automatiquement les erreurs et de notifier les utilisateurs sans intervention directe. De plus, on a trouvé des références à un mode « rêveur » qui permettrait au système de continuer à générer des idées en arrière-plan. Il a également attiré l'attention sur une façon de désigner le mode Undercover, conçu pour que l'assistant fasse des contributions discrètes dans les dépôts publics sans révéler l'information interne de l'entreprise: l'objectif, selon le texte récupéré, était que les messages de commit et le PR ne signalent pas leur origine.

Alors que certaines de ces capacités sont ingénieux du point de vue de l'automatisation, l'exposition du public au design et les chaînes de données avec lesquelles ils travaillent ouvrent des vecteurs d'attaque beaucoup plus sophistiqués que les tentatives habituelles de prisonbreak par test et erreur. Les experts en sécurité ont averti que, avec le code en vue, les mauvais acteurs peuvent étudier exactement comment les données sont compactées et persistent dans la gestion du contexte et, à partir de là, concevoir des charges malveillantes capables de survivre à ces processus et de maintenir une présence non autorisée tout au long de sessions étendues. Une discussion technique de ces risques et des exemples d'exploitation théorique se trouve dans les analyses liées et dans les blogs des sociétés de sécurité.

Le problème n'était pas simplement l'accès au code: l'événement était compliqué parce que, selon les rapports publics, il y avait une fenêtre temporaire dans laquelle la personne qui a installé ou mis à jour le paquet de npm aurait pu prendre des unités commises par une attaque de chaîne d'approvisionnement liée à une version bondée d'une librairie HTTP populaire. Compte tenu de cela, les recommandations immédiates en matière de sécurité étaient claires : retour aux versions dites sûres, rotation des secrets et révision des systèmes par des indicateurs d'engagement. Pour obtenir des directives générales sur la façon de gérer les incidents de la chaîne d'approvisionnement et de protéger les unités, les ressources comme le guide de sécurité de la chaîne d'approvisionnement de la CISA et les documents de sécurité GitHub et npm sont de bons points de départ : CISA - Chaîne d'approvisionnement, GitHub - Sécurité du code et npm Docs.

Un autre dérivé immédiat a été le travail d'utilisation du bruit malveillant: les acteurs qui publient des paquets avec des noms presque identiques aux internes (typosquatting) et qui attendent que les développeurs désespérés compiler le code filtré pour installer ces mauvaises dépendances. En fait, les paquets publiés par des utilisateurs qui ont copié des noms internes et qui ont été, dans un premier temps, des talons vides ont été identifiés; la tactique classique est de gagner des téléchargements puis de publier une mise à jour malveillante qui infecte des projets comme la confusion dépendante. Pour comprendre le risque de cette technique et les défenses recommandées, voir la documentation technique et l'analyse de sécurité sur le typosquattage et la confusion des dépendances, par exemple dans des blogs spécialisés comme Snyk: Snyk - Confusion de typosquats et de dépendance.

Au-delà des dommages techniques immédiats, l'épisode soulève des questions éthiques et stratégiques pour l'industrie : quel niveau de secret est acceptable pour développer des outils qui peuvent écrire et modifier le code dans les dépôts publics ? Comment l'innovation peut-elle être équilibrée avec des contrôles techniques qui empêchent les abus, tels que l'insertion de fonctions qui cherchent à empoisonner les données de formation de tiers si elles détectent le grattage de sortie? Les fichiers filtrés ont trouvé des signes de défenses conçues pour compliquer la distillation des modèles par les concurrents - comme l'injection de définitions de faux outils dans les réponses - une stratégie controversée qui complique encore le débat sur la transparence et la défense active.

Pour les équipes de développement utilisant des assistants de programmation et des paquets tiers, la leçon est double : d'une part, maintenir les pratiques d'hygiène dans les dépendances et les secrets (blocs de sécurité, numérisation des paquets, politiques de version fixe et surveillance des changements de registre); d'autre part, augmenter la surveillance sur le temps de performance des outils automatisés qui exécutent des commandes ou interagissent avec le système de fichiers. Les guides des meilleures pratiques de sécurité des plates-formes telles que npm et GitHub offrent des étapes concrètes pour durcir les workflows et atténuer les attaques dérivées des écosystèmes de paquets.

Anthropic a déjà dit qu'elle mettra en œuvre des mesures internes pour empêcher qu'un emballage incorrect ne se reproduise. Mais la réalité est que, dans l'écosystème des logiciels modernes, les échecs humains et les erreurs de processus se traduisent très rapidement en vecteurs opérationnels. La collectivité, les fournisseurs d'infrastructures et les organismes de réglementation doivent travailler en parallèle : améliorer les vérifications internes, fournir des canaux de déclaration précoce et, surtout, sensibiliser les utilisateurs à réagir rapidement à la possibilité d'engagements dans les unités. Pour les sources qui discutent de la gestion des incidents et des bonnes pratiques dans les paquets, la documentation npm officielle et l'analyse de sécurité spécialisée sont recommandées : npm Blog et des ressources pour répondre aux incidents de signature de sécurité.

Bref, l'erreur d'Anthropic est un rappel utile que le logiciel, aussi puissant soit-il, n'est pas infaillible et que la sécurité opérationnelle compte autant que la capacité du modèle. Le monde de l'intelligence artificielle et des logiciels collaboratifs évolue rapidement; la question est de savoir si la sécurité et la responsabilité peuvent évoluer à la même vitesse. Entre-temps, pour ceux qui utilisent des outils comme Claude Code, la priorité immédiate est de supposer que l'incident peut avoir des effets secondaires et de prendre des mesures de confinement : examiner les dépendances, faire tourner les secrets et surveiller les activités suspectes dans les dépôts et les systèmes.