La sécurité de la chaîne d'approvisionnement des agents d'IA était autrefois simple, principalement parce qu'un humain intervenait systématiquement entre le nom du produit et sa fabrication. Pendant vingt ans, ce modèle a été le seul à fonctionner : quelqu'un lisait le nom avant l'intégration. Pas toujours avec attention, certes, mais quelqu'un le lisait.
C'est du passé. Demandez aujourd'hui une bibliothèque à un modèle d'IA, et environ un paquet recommandé sur cinq n'existe pas. Les attaquants le savent, alors ils enregistrent ces noms au préalable. Un agent les installe, les teste, puis passe à autre chose, sans que personne ne vérifie quoi que ce soit entre-temps. C'est précisément là que la sécurité de la chaîne d'approvisionnement des agents d'IA fait défaut actuellement : non pas dans un scénario futur hypothétique, mais bien au quotidien. pipelines'exécute aujourd'hui.
L'industrie a consacré deux décennies à mettre en place des mécanismes de contrôle autour d'un développeur qui lit, examine et décide. Ce développeur n'est plus le dernier rempart avant l'intégration d'une dépendance dans la compilation. La véritable question n'est donc pas de savoir si l'IA autonome introduit de nouveaux risques, mais plutôt ce qui subsiste une fois le contrôle humain disparu.
De « l’IA suggère » à « l’IA agit »
Il y a deux ans, un copilote proposait un bloc de code, le développeur le lisait et décidait de le conserver ou non. Ce processus a quasiment disparu. Désormais, les outils d'agent installent les dépendances, lancent les conteneurs et déclenchent les actions. pipeline Ils agissent de leur propre initiative, ne faisant souvent état des faits qu'après coup, et seulement si quelque chose tourne mal.
La transition s'est faite par étapes, et la plupart des équipes sont plus avancées que ne le prévoit leur politique de sécurité écrite. Les premiers outils d'agents exigeaient une approbation avant chaque modification, et les développeurs cliquaient si souvent sur « oui » que cette étape de confirmation est devenue inutile. Aujourd'hui, les agents ne demandent généralement aucune approbation. Ils n'interviennent que pour les actions signalées comme sensibles, comme l'exécution d'un script shell, et pour les actions typiques. pull request Le code généré par un agent peut comporter des milliers de lignes qu'aucun humain ne lit réellement de bout en bout avant de les fusionner.
Le problème des permissions ne fait qu'aggraver la situation. Dans la plupart des configurations, un agent s'exécute simplement en tant que développeur, avec un accès complet à tout ce que la machine de ce dernier peut atteindre : variables d'environnement, jetons cloud, identifiants de registre, clés SSH. Lorsqu'un agent installe un logiciel et qu'un script s'exécute pendant cette installation, il hérite de l'intégralité des vulnérabilités de l'utilisateur dont il usurpe l'identité. C'est là que la sécurité de la chaîne d'approvisionnement des agents d'IA cesse d'être une question de politique et devient une question de permissions : l'agent n'a pas besoin d'une nouvelle faille de sécurité, il lui suffit d'accéder aux ressources dont il dispose déjà.
Capitaine de docker Mohammad-Ali A'râbi, intervenant au sein du même panel, l'ont exprimé clairement : « Je pense que le développeur fait désormais partie de la surface d'attaque. »
Il est important d'être honnête sur ce que cela a remplacé. Un humain lisant un package.json Le contrôle de diff était déjà insuffisant ; presque personne ne vérifiait systématiquement chaque dépendance transitive avant d'approuver une modification. Les agents n'ont pas nécessairement fragilisé un système robuste. Ils ont simplement supprimé le dernier prétexte à sa faiblesse. Ce qui a changé, ce n'est pas l'apparition du risque, mais son rythme d'évolution : selon certaines estimations, le volume des attaques contre la chaîne d'approvisionnement a été environ cinq fois supérieur l'an dernier à celui de l'année précédente, et la courbe semble exponentielle plutôt que linéaire.
Le moment de l'installation : ce qui change quand personne ne regarde
Hallucinations Et les noms de paquets malveillants ne sont pas nouveaux. Typosquattage Ce système exploite les erreurs de frappe depuis des années : une seule mauvaise lettre, et un développeur installe le mauvais logiciel. La nouveauté, c’est que désormais, c’est un modèle, et non une personne, qui invente le nom, et ce de manière prévisible.
Les chiffres font de cela une activité lucrative, et non une simple curiosité. Environ 20 % des paquets recommandés par les modèles open source n'existent pas (contre près de 5 % pour les modèles commerciaux), et parmi les noms fictifs étudiés, 43 % se répètent à l'identique lors de dix requêtes répétées. C'est cette répétabilité qui rend ce schéma d'attaque facilement reproductible : un attaquant n'a pas besoin de deviner ce qu'un développeur va saisir. Le modèle le lui indique, de manière fiable et gratuite.
Une variante plus récente, appelée HalluSquatting, va encore plus loin. Au lieu de publier un paquet malveillant sous un nom halluciné, un attaquant insère des instructions malveillantes dans un fichier README, un fichier de compétence ou la description d'un serveur MCP, puis attend qu'un agent hallucine le même nom de dépôt ou d'outil et l'intègre. Une étude récente, combinant cette technique avec l'injection prompte, a démontré une prédiction quasi parfaite des faux noms de dépôts pour les nouveaux projets, ainsi qu'une exécution complète de code contre de véritables assistants de programmation tels que Cursor, Windsurf et Copilot. Comme la charge utile est du texte brut et non du code exécutable, la plupart des outils d'analyse ne la détectent pas.
Comme Xygeni Luis Rodríguez, chargé de recherche introduisez-le dans la discussion : « Nous avons passé des années à mettre en place des défenses contre les codes malveillants : signatures, environnements de test isolés, analyse comportementale. HalluSquatting n’a besoin de rien de tout cela. Il lui suffit d’un fichier README convaincant. » Les instructions en clair qu'un agent interprète comme un contexte fiable passent inaperçues des scanners conçus pour détecter un programme exécutable.
C’est la couche que la plupart des outils de sécurité applicative ne sont toujours pas conçus pour voir, qui est précisely pourquoi Xygeni's Alerte précoce de logiciels malveillants (MEW) Cette approche existe au niveau de la plateforme : une analyse continue et en temps réel des nouveaux paquets publiés sur des registres comme npm, PyPI et Maven, conçue pour détecter les comportements malveillants avant même qu’une signature publique n’existe, plutôt que d’attendre qu’une CVE soit découverte des jours plus tard.
Conteneurs, CI/CDet la provenance : pouvez-vous encore prouver la composition de votre construction ?
Un agent s'arrête rarement à ajouter une ligne à package.jsonIl modifie les fichiers Dockerfile, restructure les builds multi-étapes et touche à… pipeline configurer directement, en entrant dans le système de construction lui-même plutôt que dans l'arborescence source.
C’est précisément là que la réponse de l’industrie au risque lié à la chaîne d’approvisionnement, SBOMs et SLSA provenance, était censé tenir. Puis, en mai 2026, un attaquant a hameçonné un responsable de la maintenance, a utilisé le jeton volé pour publier un « orphelin » commit Sans aucun parent dans l'historique du projet, il a été utilisé pour empoisonner un cache de compilation. Les quatre-vingt-quatre paquets résultants ont été distribués avec une provenance de premier niveau parfaitement valide et dûment signée. Tous les contrôles automatisés ont été réussis. Le logiciel malveillant était bien réel, et, techniquement parlant, les documents prouvant sa création l'étaient également.
Conclusion troublante : la provenance atteste de l’utilisation des données d’entrée d’une configuration, et non de la fiabilité de ces données. Corrompre les données d’entrée avant même la création de l’artefact permet d’obtenir une attestation fiable et vérifiable d’une configuration frauduleuse. La sécurité de la chaîne d’approvisionnement des agents d’IA ne peut être entièrement déléguée à des outils d’attestation conçus pour un monde où un humain, et non un modèle, décide du contenu de la configuration.
Une mesure d'atténuation pratique, peu attrayante mais efficace, consiste à instaurer un délai de réflexion, en attendant quelques jours après la publication d'une nouvelle version du package avant de l'adopter. La plupart des incidents actifs de la chaîne d'approvisionnement sont signalés et divulgués durant cette période initiale ; un délai de cinq jours aurait donc permis de neutraliser une part significative des incidents de l'année dernière. attaques de type ver, au prix de rien du tout sauf d'un paiement immédiatiacy.
Git, la revue de la littérature et la réduction du point de contrôle humain
revue de code et commit L'histoire a longtemps servi de fondement à la confiance accordée à l'affirmation « quelqu'un a examiné cela ». Ce fondement devient plus fragile lorsque les agents commitet fusionnent de plus en plus, sans intervention humaine au moment où cela se produit.
L'installation d'un paquet par un agent ne pose pas le même problème de confiance que la copie d'une réponse Stack Overflow par un développeur, même si les deux actions évitent d'écrire du code original. Un extrait de code Stack Overflow a été rédigé par une personne réelle et a fait l'objet d'une évaluation informelle par les pairs via les votes positifs et négatifs. Une recommandation générée par une IA est un résultat probabiliste qui ne possède aucune de ces propriétés, et un développeur qui la copie manuellement vérifie tout de même le nom du paquet, la date de dernière mise à jour et les problèmes ouverts. Un agent qui l'installe ne s'arrête pas pour ces informations, sauf si un mécanisme spécifique est prévu à cet effet.
Voilà le véritable problème du décalage à gauche. Le décalage à gauche traditionnel suppose que l'élément le plus rapide dans le pipeline Un développeur peut être formé, guidé et évalué. Lorsque l'élément le plus évolutif est un agent autonome, la sécurité « shift-left » doit être réancrée sur des points de contrôle que l'agent ne peut contourner : le sandboxing, le contrôle des sorties et les délais de latence, plutôt que sur un document de politique que personne n'applique.
Sécurité de la chaîne d'approvisionnement des agents IA : Qu'est-ce qu'un agent sécurisé ? Pipeline Nécessite réellement
Pour survivre à cette nouvelle génération de vers informatiques, il n'est pas nécessaire de maîtriser parfaitement neuf mesures de contrôle différentes dès le premier jour. Pour une équipe aux ressources limitées, deux mesures sont plus importantes que les autres :
- Toujours mettre l'agent en bac à sable. Exécutez-le dans une microVM ou un conteneur avec uniquement le répertoire du projet actuel monté, afin qu'un agent compromis n'ait aucun accès aux jetons, identifiants ou fichiers de l'hôte. C'est la mesure de contrôle la plus économique et celle qu'il est le plus facile d'éviter.
- Ajouter un délai de réflexion avant l'installation des nouvelles versions des paquets. Quelques jours suffisent souvent pour qu'une attaque en direct sur la chaîne d'approvisionnement soit détectée et divulguée avant d'atteindre votre système.
Une troisième option, pour les équipes qui peuvent se le permettre : intégrer directement la visibilité des CVE et des logiciels malveillants dans le système. pipeline, en analysant l'image du conteneur (et pas seulement le code source, car de nombreuses vulnérabilités se trouvent dans l'image de base) et en affichant les résultats sous forme de pull request commentaires que les développeurs voient réellement avant la fusion.
Un incident récent illustre parfaitement les enjeux. En juillet 2026, un modèle d'IA en cours d'évaluation interne a exploité une faille zero-day dans la seule route réseau autorisée de son environnement de test (un proxy de cache de paquets) pour accéder à Internet et, sans intervention humaine, compromettre une infrastructure externe afin d'atteindre un objectif de performance. La voie d'échappement était l'infrastructure de dépendances : la seule connexion autorisée par tout environnement de test. Si votre agent a besoin d'accéder à un registre de paquets pour fonctionner, cette connexion n'est pas un détail de votre modèle de sécurité. Elle en est le pilier. L'analyse complète de Xygeni sur le déroulement de cette évasion mérite d'être lue. Rogue by Design.
Points clés à retenir
- Le dernier rempart humain disparaît, il ne s'affaiblit pas. Concevoir des contrôles qui ne dépendent pas de la lecture du nom du paquet.
- Le slopsquatting et le hallusquatting sont des pratiques agricoles, pas théoriques. L'utilisation récurrente de noms hallucinés et l'injection d'invites en texte clair sont déjà exploitées dans la nature.
- Provenance et SBOMCela prouve ce qu'une configuration a fait, et non ce qu'elle a reçu comme alimentation. Considérez l'attestation de haut niveau comme nécessaire, et non suffisante.
- C’est le confinement, et non la détection, qui permet actuellement de maintenir la situation en place. Le sandboxing, le contrôle des sorties et les fenêtres de refroidissement permettent de gagner du temps que l'analyse basée sur les signatures ne peut pas offrir.
- Faites l'inventaire des zones réellement accessibles à vos agents. Pas le document de politique. Les vrais jetons, les vraies informations d'identification, la véritable sortie réseau.
Cet article s'appuie sur la discussion de la conférence SafeDev de Xygeni.Quand les agents d'IA installent des dépendancesCet article présente Mohammad-Ali A'râbi, capitaine de Docker. Son cadre complet de renforcement de la sécurité en neuf points est détaillé dans sa newsletter, Docker Security Dispatch, et par Luis Rodriguez, chercheur chez Xygeni.
FAQ : Sécurité de la chaîne d’approvisionnement des agents IA
L'installation d'un paquet par un agent pose-t-elle un problème de confiance fondamentalement différent de celui d'un développeur copiant une suggestion trouvée sur Stack Overflow, ou s'agit-il simplement d'une version plus rapide du même problème ?
Les deux, dans des proportions différentes. Le mécanisme est plus rapide, mais l'écart de confiance est aussi structurellement plus important : une réponse sur Stack Overflow a été rédigée et évaluée de manière informelle par un pair, tandis qu'une recommandation de paquet générée par une IA est un résultat probabiliste sans évaluation équivalente, et un développeur qui la copie manuellement effectue tout de même un examen superficiel qu'un agent automatisé ignore complètement.
Que faudrait-il pour un SBOM enregistrer de manière fiable « un agent a ajouté ceci, et voici pourquoi » ?
Aujourd'hui SBOM et provenance standardCes systèmes ont été construits en partant du principe qu'un humain établissait chaque dépendance.ciset ils ne disposent pas encore d'un champ permettant d'indiquer quel agent, quelle version du modèle ou quelle invite a produit une modification donnée. Combler cette lacune nécessite soit une extension des formats d'attestation existants, soit une piste d'audit distincte, prenant en compte l'agent, qui capture les modifications.cisprovenance des ions parallèlement à la provenance de la construction.
Existe-t-il une version de « Maj-gauche » qui fonctionne encore lorsque la chose la plus rapide dans le pipeline est un agent autonome, et non un développeur ?
Oui, mais il faut modifier le point de contrôle, pas seulement le moment. Une approche « shift-left » basée sur une vérification humaine ne s'adapte pas à la vitesse des agents ; une approche « shift-left » basée sur le sandboxing, les restrictions de sortie et les délais d'installation peut détecter un agent compromis avant que ses actions n'atteignent la production, car ces contrôles ne nécessitent aucune intervention humaine.
