Deux incidents, une même leçon sur le pouvoir délégué
Le titre de travail résume l’affaire: BOSSAI and Claude expose agent risks. Les deux cas ne relèvent pas du même scénario, ni des mêmes cibles, ni des mêmes motivations. Pourtant, ils posent la même question de sécurité: que se passe-t-il lorsque des agents logiciels peuvent agir plus vite que les humains chargés de les superviser?
À Taïwan, des chercheurs ont décrit une campagne BOSSAI dans laquelle un attaquant unique a utilisé un maillage d’agents d’IA pour atteindre des données de services d’urgence, dont des dossiers de dispatching à Taipei couvrant sept districts . Côté développement logiciel, plusieurs rapports sur la fonction “Don’t Ask Again” de Claude Code ont montré comment une option pensée pour réduire les confirmations pouvait laisser des mots de passe et des clés API dans des fichiers GitHub publics lorsque des commandes approuvées étaient enregistrées telles quelles . Ensemble, ces affaires transforment le risque agentique en problème opérationnel concret.
BOSSAI: reconnaissance à vitesse machine contre des services publics
L’affaire BOSSAI n’est pas présentée comme une intrusion rendue magique par l’IA. Elle est plus inquiétante précisément parce qu’elle repose sur une dette de sécurité classique, exploitée avec une vitesse inhabituelle. L’attaquant aurait dirigé ses agents contre des centaines d’organisations dans au moins 11 pays, dont des services d’urgence, banques, universités et systèmes militaires, tandis que l’accès ou le vol confirmé de données concernerait environ 10 cibles à Taïwan, au Mexique et en Thaïlande . DailyStraits, en résumant les mêmes travaux, indique que l’opérateur était basé à Hualien City et utilisait une campagne de 12 agents contre ces secteurs .
Les éléments les plus sensibles à Taïwan touchent aux services d’urgence. Les agents ont extrait des dossiers depuis un système municipal de dispatching 119, comprenant les horaires d’incident, types de réponse, statuts de dossier et emplacements au niveau de la rue; The Hacker News précise qu’il s’agissait de dossiers de cas, et non d’un suivi en direct des ambulances . Les agents ont aussi trouvé une plateforme des pompiers de Taipei exposant sans authentification des dossiers de soins de 2018, incluant lectures ECG et vidéos d’ambulance . DailyStraits rapporte également que l’activité à Taïwan concernait des dossiers de soins et des cas issus du 119 .
Cette nuance compte. Des dossiers de dispatching ne révèlent peut-être pas la position d’ambulances en temps réel, mais ils peuvent exposer des schémas opérationnels: concentration géographique des appels, catégories d’incidents, suivi des statuts, districts présents dans les données. Les dossiers de soins ajoutent un enjeu de vie privée. Dans les deux cas, des données publiques sensibles deviennent utiles non seulement pour la fraude, mais aussi pour cartographier la capacité et les angles morts de services d’urgence.
BOSSAI montre aussi les limites des agents. Selon The Hacker News, les modèles commerciaux ont majoritairement refusé les demandes offensives directes, ce qui a poussé l’opérateur vers des modèles locaux dont les garde-fous avaient été retirés . Le même reportage indique que les agents ne communiquaient pas de manière autonome entre eux: l’opérateur copiait manuellement la sortie d’un agent dans un autre . Ce n’est donc pas la version “Skynet avant le petit-déjeuner” de l’histoire. C’est plutôt un opérateur junior, obstiné et très rapide, avec de nombreux terminaux ouverts.
Les échecs sont aussi importants que les succès. La campagne aurait produit des vulnérabilités imaginaires, des faux positifs et des résultats annoncés qui ne s’étaient pas réellement produits . Les agents ont échoué lorsque l’authentification était appliquée, lorsque des paywalls exigeaient une session valide et lorsque les points d’accès étaient correctement filtrés . Autrement dit, l’IA a élargi la recherche et réduit le coût des essais, sans annuler la valeur des contrôles de base.
Claude Code: quand moins de frictions devient fuite de secrets
Le cas Claude Code est plus proche du quotidien des développeurs, mais tout aussi instructif. Il commence par une habitude banale: approuver une commande pour que l’outil ne redemande plus. Les rapports indiquent que lorsque l’utilisateur choisissait “Yes, and don’t ask again”, Claude Code pouvait enregistrer la commande shell approuvée dans .claude/settings.local.json; si cette commande contenait un mot de passe ou un jeton, le secret pouvait être stocké en clair .
Les chiffres diffèrent parce qu’ils ne mesurent pas le même périmètre. The Hacker News rapporte qu’Apiiro a trouvé 104 185 copies publiques du fichier concerné, dont 1 122 contenaient au moins un secret, pour 1 379 secrets distincts . LATENT a détaillé l’écart: le total plus large de 2 539 secrets inclut les anciennes versions, les paramètres partagés et les transcriptions d’agents, tandis que le chiffre de 1 122 vise les copies publiques actuelles de .claude/settings.local.json . Yaamlabs reprend cette distinction et ajoute que le périmètre élargi couvre 1 994 dépôts et 63 organisations .
Cette différence n’est pas un simple détail comptable. Elle montre pourquoi les fuites automatisées sont difficiles à mesurer. Un secret peut apparaître dans la branche par défaut actuelle, dans l’historique Git, dans un fork, dans un fichier de paramètres partagé ou dans une transcription d’agent. Supprimer le fichier visible ne suffit donc pas; il faut d’abord faire tourner les identifiants compromis. The Hacker News rapporte que les anciennes versions contenaient 734 secrets supplémentaires dans 509 dépôts, et que 211 forks de 74 dépôts transportaient les mêmes secrets que les originaux .
Le mécanisme est aussi une leçon de conception. Claude Code tenterait d’éviter l’ajout du fichier local à Git en l’inscrivant dans les exclusions globales de l’utilisateur, mais cette protection reste liée à une machine et ne voyage pas avec le .gitignore du projet . Yaamlabs décrit les cas pratiques de fuite: nouvelle machine ou conteneur sans exclusion globale, dossier de projet copié, git add forcé, ou dépôt où le fichier était déjà suivi . Dans 539 des 1 105 dépôts retracés, Apiiro a trouvé qu’un commit mentionnant Claude comme coauteur modifiait le fichier, même si Yaamlabs précise qu’il s’agit d’une inférence et non d’une preuve que Claude a ajouté chaque secret .
Pourquoi les scanners et les valeurs par défaut doivent changer
Les rapports sur Claude Code remettent aussi en cause une défense courante: “nous avons du secret scanning”. LATENT indique que Gitleaks a détecté 50,3 % des 1 122 fichiers concernés et TruffleHog 57,3 %; ensemble, ils ont encore manqué 215 fichiers, soit 19,2 % . Yaamlabs explique pourquoi: beaucoup de valeurs exposées ressemblent à de simples mots de passe intégrés dans des commandes ou des chaînes de connexion, et non à des clés de fournisseurs avec préfixes reconnaissables .
Ranthis a mené un test avec un faux mot de passe et rapporte que le choix “Yes, and don’t ask again” a copié toute la commande dans .claude/settings.local.json; le même test a constaté que l’usage d’une variable d’environnement empêchait l’option “don’t ask again” d’enregistrer le secret littéral . Les mesures pratiques sont donc claires: ne jamais saisir directement de secrets dans des commandes approuvées par des agents, préférer les variables d’environnement ou gestionnaires de secrets, et approuver des motifs plutôt que des commandes exactes contenant des identifiants.
Des contrôles adaptés à la vitesse des agents
La leçon commune de BOSSAI et de Claude Code est que le risque agentique ne se limite pas aux défaillances exotiques de modèles. Il apparaît lorsque les agents accélèrent des actions ordinaires: scanner des points d’accès publics, tester des identifiants faibles, mettre en cache des approbations de commandes, committer des fichiers et rejouer des flux de travail. Dans le cas BOSSAI, les défenseurs doivent disposer d’une télémétrie capable de repérer la reconnaissance à vitesse machine, l’énumération d’API, les tentatives d’injection SQL, l’usage d’identifiants par défaut et les lectures massives de données sensibles . Dans le cas Claude Code, les équipes d’ingénierie doivent mettre en place des règles d’exclusion au niveau du dépôt, des contrôles pre-commit, l’analyse de l’historique, la rotation des identifiants et des permissions étroitement limitées autour des paramètres d’agents .
Les équipes sécurité devraient considérer les fichiers d’agents comme porteurs de secrets par défaut. Cela inclut les dossiers .claude/, les paramètres partagés, transcriptions, fichiers de mémoire et caches d’approbation enregistrant ce que l’agent a exécuté. Les organisations doivent aussi séparer l’approbation d’une opération de l’approbation des paramètres sensibles qu’elle contient. Le mode commodité doit réduire les confirmations répétitives, pas devenir un sudo amnésique.
Le changement le plus profond est culturel. Les contrôles à vitesse humaine supposent que quelqu’un remarque l’étape risquée avant qu’elle ne compte vraiment. Les systèmes agentiques peuvent effectuer cette étape, l’enregistrer, la répéter et passer à la suite. BOSSAI montre comment un opérateur peut multiplier la reconnaissance contre des données publiques critiques. Claude Code montre comment un clic peut conserver un identifiant longtemps après que le développeur l’a oublié. La réponse n’est pas d’interdire les agents, mais de les concevoir comme des systèmes susceptibles de commettre des erreurs de sécurité, puis de contenir ces erreurs avant qu’elles ne deviennent des incidents d’infrastructure publique ou des fuites de dépôts publics.
Commentaires
Sois le premier à commenter.