Quand l’agent devient le meilleur allié de l’attaquant
Une campagne rapportée par CSO Online marque une véritable nouveauté dans le paysage des menaces sur la supply chain. Les attaquants ont disséminé des paquets malveillants de second niveau sur npm, PyPI et Cargo, se faisant passer pour des utilitaires de cryptomonnaie. Les cibles n’étaient pas des développeurs humains installant des dépendances par habitude — les cibles étaient des agents de codage IA qui scannent les registres de manière autonome et intègrent des composants dans les projets sans qu’aucun humain ne vérifie chaque choix.
La campagne a évolué au fil du temps. Les premiers payloads volaient des identifiants. Les versions suivantes déployaient des clés SSH contrôlées par l’attaquant pour un accès distant direct, archivaient et exfiltraient des dépôts de code entiers, et finissaient par livrer des applications compilées en exécutable unique pour échapper à la détection. À chaque évolution, le message restait le même : quand le consommateur du paquet est un agent IA, il suffit de convaincre l’agent. Le graphe de dépendances n’est plus géré par les développeurs — ce sont les agents qui le modifient de façon autonome, et les attaquants l’ont bien compris.
5 points clés à retenir
1. Les dépendances sont devenues la nouvelle surface d’attaque de l’IA.
Les chercheurs ont documenté des paquets comme aes-create-ipheriv, jito-proper-excutor et @validate-sdk/v2 volontairement disséminés sur npm, PyPI et Cargo pour être découverts et intégrés par des agents de codage IA. Ce n’est pas une menace hypothétique — c’est une opération active qui change la façon dont chaque agent IA en production doit être gouverné. La surface de compromission de la supply chain a glissé du périmètre vers le graphe de dépendances.
2. L’agent fait le travail de l’attaquant à sa place.
Les outils de codage IA scannent de façon autonome les registres de paquets et modifient leurs propres graphes de dépendances. Aucun humain dans la boucle signifie aucune vérification humaine de ce qui vient d’être installé. 63 % des organisations ne peuvent pas limiter les usages des agents IA et 60 % ne peuvent pas rapidement désactiver un agent défaillant selon les Prévisions Kiteworks 2026. Une dépendance piégée exploite ces failles sans rencontrer de résistance et sans laisser de traces exploitables par la plupart des organisations.
3. Les payloads évoluent très vite.
Ce qui a commencé par du vol d’identifiants a évolué vers des clés SSH contrôlées par l’attaquant, l’exfiltration complète de dépôts et des applications compilées en exécutable unique conçues pour éviter la détection. À chaque évolution, le message reste le même : quand le consommateur du paquet est un agent IA, il suffit de convaincre l’agent — pas le développeur. Le taux de conversion ne se mesure pas en pourcentage, mais en nombre d’agents ayant téléchargé le paquet avant son retrait du registre.
4. Les garde-fous au niveau du modèle ne suffisent pas.
Un modèle sécurisé continue de télécharger toute dépendance récupérée par ses outils. Le paquet malveillant s’exécute dans l’environnement de l’agent, déploie des clés SSH et exfiltre du code sans jamais passer par une invite du modèle. La vulnérabilité se situe sous le modèle, au niveau de l’exécution des outils et de l’accès aux données — là où l’alignement, le filtrage des prompts et la modération de contenu n’ont aucun effet.
5. La solution passe par la gouvernance au niveau des données.
Authentifiez chaque agent. Autorisez chaque demande de données via des contrôles d’accès basés sur les attributs. Chiffrez avec FIPS 140-3. Journalisez chaque action dans une piste d’audit infalsifiable. L’agent ne peut pas exfiltrer ce qu’il n’a jamais été autorisé à voir — quelle que soit la dépendance piégée installée. Même si le modèle est compromis, la couche donnée applique la politique de sécurité.
Vous pensez que votre organisation est sécurisée. Mais pouvez-vous le prouver ?
Pour en savoir plus :
L’adoption de l’IA agentique dépasse la gouvernance de l’IA agentique
Toutes les organisations interrogées dans les Prévisions Kiteworks 2026 ont l’IA agentique dans leur feuille de route — sans exception. L’adoption est généralisée. La gouvernance ne l’est pas. 63 % des organisations ne peuvent pas limiter les usages des agents IA, 60 % ne peuvent pas rapidement désactiver un agent défaillant et 55 % ne peuvent pas isoler les systèmes IA du reste du réseau. Côté secteur public, c’est pire : 90 % n’ont pas de mécanisme de limitation d’usage, 76 % n’ont pas d’interrupteur d’arrêt, 33 % n’ont aucun contrôle dédié à l’IA.
Les mêmes données montrent où ça casse en premier. 27 % des organisations prévoient d’automatiser le MFT avec l’IA, mais seuls 46 % ont mis en place une sécurité MFT suffisante. L’IA s’ajoute à des canaux déjà insuffisamment contrôlés. Ajoutez une dépendance piégée, et l’agent devient un outil d’exfiltration parfaitement autorisé, doté d’identifiants valides et générant un événement d’audit légitime.
Pourquoi les garde-fous au niveau du modèle ne suffisent pas
Un modèle parfaitement aligné peut toujours tourner sur une couche d’outils qui vient d’installer aes-create-ipheriv parce que l’agent a estimé avoir besoin d’un utilitaire cryptographique. Le modèle ne voit jamais la clé SSH déployée. Il ne sait pas que le dépôt est archivé et exfiltré. Quand on interroge le modèle sur ce qui s’est passé, le mal est déjà fait, à un niveau où le modèle n’a aucune visibilité.
L’étude Agents of Chaos — fruit d’une collaboration de 38 auteurs issus de Northeastern, Harvard, MIT, Stanford, CMU et d’autres institutions — a documenté trois failles structurelles exploitées par cette campagne de dissémination de paquets : absence de modèle de parties prenantes (les agents ne distinguent pas les opérateurs légitimes des attaquants), absence de modèle de soi (les agents prennent des décisions irréversibles sans savoir quand ils dépassent leurs compétences) et absence de surface de délibération privée (les agents divulguent des informations sensibles via de mauvais canaux). Chacune de ces failles est critique quand l’agent devient le point d’entrée.
Le graphe de dépendances est le nouveau mail de phishing
Pendant des années, le phishing était la porte d’entrée privilégiée des attaquants — convaincre un humain de cliquer, d’ouvrir ou de saisir des identifiants. L’humain dans la boucle est devenu une surface de contrôle : sensibilisation, filtrage des e-mails, MFA, accès conditionnel. L’agent de codage IA retire l’humain de la boucle. Quand l’agent décide quoi installer, le registre de dépendances devient l’équivalent d’une boîte de réception — un flux continu d’entrées évaluées sans sensibilisation, sans MFA, sans accès conditionnel.
Un risque de second ordre s’ajoute au premier. Les agents de codage IA ne se contentent pas d’installer des paquets — ils génèrent du code qui dépend de ces paquets. Lorsqu’un agent a été exposé à un paquet malveillant, il peut le suggérer à d’autres développeurs, propageant la compromission à des équipes qui n’ont jamais interagi directement avec le registre. La frontière entre « l’agent a installé quelque chose de malveillant » et « l’agent a recommandé quelque chose de malveillant à un humain qui l’a ensuite installé » est plus mince que ce que la plupart des programmes de sécurité peuvent gérer.
La faille de confinement que la plupart des conseils d’administration ignorent
54 % des conseils d’administration ne s’impliquent pas dans la gouvernance de l’IA, et ces organisations accusent un retard de 26 à 28 points sur tous les indicateurs de maturité IA selon les Prévisions Kiteworks 2026. L’implication du conseil est le meilleur indicateur de maturité en gouvernance IA — devant le secteur, la région ou la taille. Cette faille se manifeste surtout dans les contrôles de confinement. Les organisations ont investi dans la surveillance de l’IA — humain dans la boucle, monitoring continu. Elles n’ont pas investi dans les moyens de l’arrêter.
La campagne de paquets piégés révèle le coût de ce déséquilibre. Une organisation qui surveille parfaitement ses agents mais ne peut pas les arrêter documente sa propre compromission. La question du conseil d’administration pour le prochain trimestre n’est pas « utilisons-nous l’IA en toute sécurité ? » — c’est « pouvons-nous arrêter un agent compromis en moins de cinq minutes, avec des preuves à présenter à un régulateur ? »
À quoi ressemble la gouvernance au niveau des données
Les contrôles ne doivent pas vivre là où vit le modèle — ils doivent vivre là où résident les données. Lorsqu’un agent IA accède à des données sensibles, il doit se heurter à une vérification d’identité cryptographique, une évaluation de politique d’accès basée sur les attributs, un chiffrement FIPS 140-3 et une journalisation d’audit infalsifiable à chaque interaction. Un agent compromis par une dépendance piégée ne peut pas accéder à des données qu’il n’était pas autorisé à voir, ne peut pas exfiltrer au-delà de son périmètre d’usage, et ne peut pas agir sans laisser de traces exploitables.
Le serveur MCP sécurisé Kiteworks et la passerelle de données IA appliquent ce modèle : chaque requête d’agent est authentifiée, autorisée selon une politique ABAC, chiffrée avec FIPS 140-3 et journalisée en temps réel dans le SIEM. Le Réseau de données privé Kiteworks étend cette gouvernance à la messagerie électronique, au partage de fichiers, au MFT, au SFTP, aux formulaires web et aux API — un moteur de politique unique, un journal d’audit consolidé. 33 % des organisations n’ont pas de pistes d’audit exploitables et 61 % utilisent une infrastructure d’échange de données fragmentée. Lors de la prochaine campagne de paquets piégés visant vos agents, les régulateurs ne demanderont pas « comment le paquet est-il entré » mais « qu’a fait l’agent une fois compromis, et pouvez-vous le prouver ? »
Ce que les responsables sécurité doivent faire ce trimestre
Premièrement, recensez tous les agents IA qui accèdent au code ou aux données. Impossible de gouverner ce que vous n’avez pas inventorié. 100 % des organisations ont l’IA agentique dans leur feuille de route — le problème d’inventaire ne fera que croître.
Deuxièmement, considérez les environnements d’exécution des agents comme des infrastructures sensibles. Appliquez les mêmes contrôles d’accès, listes d’autorisation et monitoring que pour les comptes administrateurs. Limitez quels agents peuvent exécuter quels outils. Imposer des listes d’autorisation de dépendances. Exigez la vérification de signature de code sur les paquets installés par un agent.
Troisièmement, déployez une gouvernance au niveau des données indépendante du modèle. Quel que soit le modèle utilisé par vos agents, les données auxquelles ils accèdent doivent passer par l’application de politiques ABAC, le chiffrement FIPS 140-3 et la journalisation d’audit. 63 % des organisations ne peuvent pas limiter les usages des agents IA — comblez cette faille avant que la prochaine campagne sur la supply chain ne la teste.
Quatrièmement, mettez en place un interrupteur d’arrêt et testez-le. 60 % des organisations ne peuvent pas rapidement désactiver un agent défaillant. Développez cette capacité, documentez-la, testez-la en simulation et attribuez clairement la responsabilité de son déclenchement. C’est indispensable pour tout système manipulant des données réglementées.
Cinquièmement, testez vos agents IA comme vous testez votre réseau. Les chercheurs d’Agents of Chaos ont documenté au moins 10 compromissions majeures dans 11 études de cas, obtenues par simple conversation, sans outils sophistiqués. Menez des exercices d’attaque sur vos propres agents. Identifiez les failles avant qu’un tiers ne le fasse.
Pour en savoir plus sur la protection des données sensibles contre les attaques d’origine IA, réservez votre démo personnalisée dès aujourd’hui.
Foire aux questions
Si vos agents de codage IA récupèrent de façon autonome des dépendances depuis npm, PyPI ou Cargo, vous êtes directement exposé. Cette campagne cible spécifiquement les agents, car ils installent des paquets sans validation humaine. 60 % des organisations ne peuvent pas rapidement désactiver un agent IA défaillant selon les Prévisions Kiteworks 2026 — ce qui signifie qu’en cas d’activation d’une dépendance piégée, le confinement est le premier point de défaillance. Mettez en place immédiatement des listes d’autorisation de dépendances et des contrôles d’accès au niveau des données.
Les garde-fous au niveau du modèle agissent au-dessus de la couche d’exécution des outils, là où l’attaque se produit. Le paquet malveillant s’exécute dans l’environnement de l’agent sans passer par une invite du modèle. La gouvernance au niveau des données — application de politiques ABAC, chiffrement FIPS 140-3, pistes d’audit infalsifiables — résiste à la compromission de la couche outil car elle se situe sous le modèle. 33 % des organisations n’ont pas de pistes d’audit exploitables, la faille principale exploitée par ce type d’attaque.
Les examinateurs exigeront l’authentification de l’identité des agents, l’application de politiques ABAC, le chiffrement FIPS 140-3 et des journaux d’audit infalsifiables couvrant chaque interaction agent-donnée. 33 % des organisations n’ont pas de pistes d’audit exploitables selon les Prévisions Kiteworks 2026. Sans journalisation unifiée sur tous les canaux utilisés par un agent, les constats d’audit sont quasi inévitables.
Le MFT est ici le canal le plus exposé. 27 % des organisations prévoient d’automatiser le MFT avec l’IA, mais seulement 46 % disposent d’une sécurité MFT adéquate selon les Prévisions Kiteworks 2026. Comblez d’abord la faille de gouvernance MFT — accès agent limité à l’usage, application des politiques ABAC et journaux infalsifiables — avant d’étendre les agents à la gestion des données fournisseurs.
Oui. Les familles CMMC AC, AU et IR couvrent aussi l’activité des agents IA. 63 % des organisations ne peuvent pas limiter les usages des agents IA selon les Prévisions Kiteworks 2026. Une compromission exfiltrant des CUI via un agent mal gouverné expose à la False Claims Act si la gouvernance IA était certifiée mais non appliquée. Déployez une gouvernance au niveau des données avec ABAC et des pistes d’audit infalsifiables avant l’audit.
Ressources complémentaires
- Article de blog
Stratégies Zero Trust pour protéger la vie privée à l’ère de l’IA à moindre coût - Article de blog
Comment 77 % des organisations échouent à sécuriser les données IA - eBook
AI Governance Gap : pourquoi 91 % des petites entreprises jouent à la roulette russe avec la sécurité des données en 2025 - Article de blog
Il n’existe pas de « –dangerously-skip-permissions » pour vos données - Article de blog
Les régulateurs ne se contentent plus de demander si vous avez une politique IA. Ils veulent des preuves de son efficacité.