Les agents IA malveillants ne se contentent plus d’écrire du code : ils publient désormais des paquets piégés dans les dépôts publics dont dépendent vos développeurs. OpenAI a confirmé que des agents issus de sa propre plateforme avaient inondé RubyGems de paquets malveillants dès le mois de mai, quelques jours seulement après une campagne similaire visant des wikis. Anthropic avait déjà documenté un cas comparable sur PyPI. Pour une PME ou une ETI, cela change la nature du risque supply chain : l’attaquant n’est plus un humain qui publie dix paquets, c’est une flotte qui en publie mille.
Pourquoi les agents IA malveillants changent l’échelle de l’attaque
Une attaque de supply chain logicielle classique repose sur un goulot d’étranglement humain : il faut choisir un nom de paquet crédible, écrire une charge utile, créer un compte, publier, recommencer. Chaque étape coûte du temps. Un agent autonome supprime ce coût.
Les campagnes observées ces derniers mois partagent les mêmes caractéristiques :
- Volume : des centaines de paquets publiés en quelques jours, avec des noms générés pour couvrir toutes les fautes de frappe plausibles (typosquatting industrialisé).
- Variation : chaque paquet contient une charge légèrement différente, ce qui réduit l’efficacité des signatures statiques.
- Persistance : quand un compte est bloqué, l’agent en recrée un autre et reprend le travail, sans intervention humaine.
- Crédibilité : README, documentation et historique de commits sont générés pour donner au paquet l’apparence d’un projet vivant.
Le point important pour les équipes de sécurité : ces agents IA malveillants n’exploitent aucune faille du registre. Ils utilisent la fonctionnalité prévue — publier un paquet — mais à une cadence que la modération humaine ne peut pas suivre.
Le même moteur sert aussi à l’exploitation
Le phénomène ne s’arrête pas aux dépôts. Des rapports récents décrivent l’usage de modèles pour extraire des secrets depuis des millions d’applications Android publiques, ou pour reconstruire un malware à chaque fois qu’il est détecté. La logique est identique : là où l’attaquant devait choisir ses cibles faute de temps, il peut désormais traiter l’intégralité de la surface d’attaque. Nous l’avions déjà observé avec les dépôts Git piégés qui détournent les agents de développement.
Ce que risque concrètement une PME-ETI
Le vecteur d’entrée n’est pas le registre public : c’est votre pipeline CI/CD. Un paquet malveillant installé pendant un build s’exécute avec les droits du runner, donc avec l’accès aux variables d’environnement, aux jetons de déploiement et souvent au registre d’images interne.
- Vol de secrets CI/CD : clés cloud, jetons de dépôt, identifiants de base de données présents dans l’environnement de build.
- Compromission en aval : si l’artefact produit est signé et distribué, vos propres clients héritent du code piégé.
- Persistance discrète : une dépendance transitive introduite il y a trois mois ne déclenche aucune alerte au moment de l’incident.
Se défendre contre les agents IA malveillants : cinq mesures
1. Verrouiller les versions et geler les dépendances
Un lockfile commité et respecté en CI (npm ci, pip install --require-hashes, bundle install --frozen) supprime la fenêtre dans laquelle un paquet fraîchement publié peut entrer dans votre build. C’est la mesure au meilleur rapport effort/bénéfice.
2. Interdire les scripts d’installation
La majorité des charges utiles s’exécutent au moment de l’installation, pas de l’import. Désactivez les hooks (npm ci --ignore-scripts) et n’autorisez les exceptions que pour une liste courte et revue de paquets.
3. Passer par un miroir interne
Un proxy de dépôt (Artifactory, Nexus, Verdaccio) avec une politique de quarantaine — aucun paquet publié depuis moins de sept jours — bloque mécaniquement les campagnes de masse, qui sont détectées et retirées en quelques jours.
4. Cloisonner le runner CI
Aucun secret de production dans un job de build. Des identifiants éphémères à portée limitée, un accès réseau sortant restreint, et un runner jetable. Le principe reste celui décrit dans notre article sur la sécurisation des workflows GitHub face aux agents IA.
5. Surveiller les signaux de build
Alertez sur ce qui devrait être rare : une nouvelle dépendance transitive, une connexion sortante inattendue depuis un runner, une lecture de ~/.aws ou de ~/.npmrc pendant l’installation. Ces événements sont peu nombreux et très discriminants.
La modération ne suffira pas
Les registres publics améliorent leur détection, mais la dissymétrie est structurelle : publier coûte désormais quasiment zéro, vérifier coûte toujours quelque chose. Tant que cet écart persiste, la défense doit se déplacer vers le point de consommation — votre pipeline — plutôt que vers le point de publication.
Face aux agents IA malveillants, la bonne question n’est pas « ce paquet est-il sûr ? » mais « que se passe-t-il si ce paquet est hostile ? ». Un build qui ne détient aucun secret exploitable et qui n’exécute aucun script non validé transforme une compromission de dépôt en incident sans conséquence.
C’est précisément la surface que couvre AIGIL, notre offre de sécurisation des agents IA et du code LLM pour PME et ETI.