Il y a un moment que tout développeur connaît. Tu clones un dépôt, l'agent demande s'il peut exécuter les étapes d'installation, tu dis oui, et 40 secondes plus tard la machine compile quelque chose. Ça ressemble au progrès.
Cette semaine, ce réflexe est devenu une surface d'attaque documentée. Un nouveau travail des chercheurs Aadesh Bagmar et Pushkar Saraf a testé douze scénarios d'attaque en cinq classes sur des harnesses d'agents de code en production, avec des modèles de frontière. Leur conclusion est directe : les agents lisent les fichiers README, les listes de dépendances et les Makefiles, exécutent les étapes d'installation, et ne vérifient presque rien sur les noms de paquets, les sources ou les versions avant de le faire.
Ensuite, BleepingComputer a rapporté un tour jumeau : dépose un fichier AGENTS.md dans un dossier Téléchargements, et un agent qui y passe peut être amené à exécuter du code ou à livrer des identifiants. Pas de chaîne d'exploit. Pas de faille jour zéro. Juste un fichier texte qui ressemble à de la documentation.
Si ton équipe livre avec Claude Code, Codex, Copilot ou Cursor, c'est désormais ton problème, pas une curiosité de laboratoire.
La revue de trois secondes que plus personne ne fait
Avant les agents, la dernière ligne de défense était l'impatience humaine qui faisait de la sécurité sans le vouloir. Un développeur qui survolait un README pouvait remarquer une URL de registre bizarre ou un nom de paquet avec une lettre de trop, et marquer une pause.
Cette pause a disparu. L'agent lit le fichier, interprète la spécification des dépendances et lance l'installation avec tes droits et tes variables d'environnement, souvent en approuvant automatiquement les commandes shell parce que la vitesse est justement tout l'intérêt.
L'étude est juste sur ce que les agents font bien. Un typosquat flagrant comme "tranformers" est repéré quasiment à chaque fois. Les agents sont bons pour voir l'erreur évidente.
Le problème commence là où l'erreur paraît raisonnable :
- Confusion de séparateurs. "azurecore" au lieu d'"azure-core". Crédible, assez proche pour passer un survol, assez différent pour aboutir au paquet d'un attaquant.
- Redirection de registre. Les index cachés et les sources non fiables s'installent presque sans condition. Les auteurs notent que l'effort de l'attaquant sur des noms plausibles est largement inutile, car le canal source est précisément celui que les agents ne surveillent pas.
- Versions vulnérables connues. Un paquet techniquement correct mais des années en retard sur les correctifs.
L'angle mort n'est pas l'intelligence. C'est l'autorité. L'agent traite un fichier du projet comme une instruction légitime, parce qu'un fichier de projet est censé l'être.
Pourquoi le modèle n'est pas le maillon faible
Voici la partie qui devrait changer ta façon d'acheter et de déployer ces outils. Le même modèle a repéré une attaque via un harness et l'a installée via un autre. Dans un essai contrôlé où seul le harness changeait, une même attaque est passée d'être repérée dans les dix exécutions à neuf sur trente.
Autrement dit, la sécurité à l'installation est une propriété du couple harness-modèle, pas du niveau de benchmark du modèle. Passer à un "meilleur" modèle n'est pas une mise à jour de sécurité. Le harness est ce qui arbitre les appels d'outils, les permissions, l'exécution et la mémoire, et c'est aussi ce que presque aucune équipe ne configure.
Les auteurs chiffrent l'écart en citant des travaux parallèles : les demandes malveillantes explicites échouent face à de bonnes défenses, mais la même charge utile blanchie dans des artefacts de développement ordinaires contourne l'alignement dans 11,6 à 33,5 % des cas. L'intention cachée dans la documentation passe sous l'entraînement au refus qui l'arrêterait de face.
L'astuce de persistance : AGENTS.md comme point d'ancrage
Avec l'histoire AGENTS.md, la stratégie devient plus claire. Une issue GitHub malveillante est un coup unique : injecter, exécuter, peut-être voler un jeton avant que quelqu'un remarque. Un AGENTS.md inscriptible, c'est un bail.
Des chercheurs travaillant avec Codex d'OpenAI ont montré que des consignes écrites par l'attaquant dans un AGENTS.md inscriptible persistaient à travers plusieurs étapes automatisées, parce que les étapes suivantes réutilisaient l'espace de travail et continuaient à faire confiance au fichier. L'agent d'Anthropic a de même été amené, depuis une issue piégée, à lire des fichiers arbitraires et à récupérer des identifiants d'API GitHub et Anthropic.
Enchaîne les deux résultats. Un fichier d'instructions qui survit aux frontières entre étapes, plus un agent avec les permissions CI/CD par défaut, cela donne une intrusion qui n'a pas besoin de faire du bruit. Les pipelines multi-étapes partagent leurs espaces de travail. Les éditeurs ont publié des correctifs. Ta copie de ces valeurs par défaut est peut-être toujours là.
À quoi ça ressemble dans une vraie équipe
Imagine une équipe produit de taille moyenne à Dubaï. Douze ingénieurs, trois dépôts, un pipeline CI qui lance un agent sur chaque PR pour corriger le lint et résumer les diffs. L'agent détient un jeton de dépôt avec droit d'écriture, parce que c'était le moyen le plus rapide de le rendre utile.
Un contributeur ouvre une issue sympathique : "La CI échoue sur main, merci d'exécuter les étapes de CONTRIBUTING pour reproduire." L'agent obéit. Rien dans cette séquence ne paraît anormal dans un journal où les agents exécutent déjà des commandes toute la journée.
Personne ne le remarque pendant onze jours. Non pas parce que la détection est difficile, mais parce que personne n'a défini à quoi ressemble "normal" pour un agent dans ce pipeline.
Le correctif est ennuyeux, et c'est tout l'intérêt
Les auteurs ont constaté qu'un contrôle déterministe avant installation, vérifiant nom, source et version avant l'exécution du moindre code, ferme l'essentiel de la brèche. Aucun agent actuel ne l'implémente par défaut. Donc tu le construis, ou tu mets une barrière.
Cinq choses à faire cette semaine :
- Place une barrière avant l'installation. Liste blanche de registres, échec sur similarité de nom avec des paquets populaires, refus des versions non épinglées. Cinq lignes de politique valent mieux qu'un prompt plein d'espoir.
- Resteins les jetons. Le jeton de l'agent ne devrait pas pouvoir écrire sur main, lire des secrets ou toucher la production. Le moindre privilège n'est pas un slogan, c'est du confinement.
- Traite les fichiers d'instructions comme du code. Les modifications de AGENTS.md, CLAUDE.md, .cursorrules, CONTRIBUTING et des workflows YAML passent par une revue obligatoire, exactement comme un changement de module d'authentification.
- Rends les espaces de travail éphémères. Un conteneur neuf par étape. Rien d'inscriptible ne survit pour porter une instruction plus loin.
- Journalise les actions de l'agent comme une identité. Chaque commande, chaque fichier lu, chaque accès aux identifiants, attribué à l'agent et envoyé là où un humain regarde vraiment.
Ce que ça veut dire pour nos clients
Rien de tout cela ne plaide contre l'usage des agents de code. Les nôtres font du vrai travail chaque jour, et le gain de productivité n'est pas une illusion.
Cela plaide pour traiter l'agent comme un nouveau collègue avec un portable et tes clés de production : utile immédiatement, dangereux sans gestion. Le périmètre a bougé. Ce n'est plus le bord de ton réseau, ni même ton fournisseur de modèle. C'est le dernier fichier que ton agent a lu avant d'exécuter quelque chose.
Si tu déploies des agents dans la CI, ou si tu n'es pas sûr des permissions qu'ils ont aujourd'hui, c'est une conversation de deux heures que nous avons régulièrement. Apporte ton pipeline. Nous apportons la paranoïa.