Le piège de confiance dans les compétences IA: quand une compétence apparemment inoculée devient une passerelle vers vos systèmes

Une société de sécurité, AIR, a démontré une faiblesse structurelle dans l'écosystème des « compétences » pour les agents de l'IA : elle a créé une compétence apparemment inoffensive appelée brand-landingpage, il l'a téléchargé dans un dépôt populaire pour hériter de ses stars de GitHub , publié une annonce sur Instagram et , selon son rapport , atteint des dizaines de milliers d'agents - y compris certains enregistrés dans des comptes d'entreprise - sans aucun scanner indiquant qu'il est malveillant.

L'astuce technique qu'ils ont exploitée est simple et ancienne dans la sécurité des logiciels: le scanner passe en revue le paquet qui vous est livré (les fichiers qui viennent avec la compétence), mais la compétence peut viser la documentation externe ou les scripts qui sont téléchargés en temps d'installation. AIR a d'abord laissé un lien vers la documentation légitime pour passer l'examen, et une fois que la compétence s'est suffisamment répandue, il a changé le contenu du lien pour les instructions demandant d'exécuter un script. Dans son test, la charge utile n'a retourné que les adresses de courrier aux installations de comptage, mais le vecteur aurait pu servir à lire des fichiers, exfilter des données ou déplacer latéralement selon les permissions de l'agent.

Ce n'est pas une surprise isolée: d'autres équipes de recherche, comme Trail of Bits, ont montré comment les scanners de compétences peuvent être moqués par la même technique de séparation du contenu analysé de ce que l'agent télécharge en temps réel. Le problème n'est pas un bug opportun, mais un défaillance du modèle de confiance: on suppose qu'une compétence vérifiée avec des signes externes de légitimité (étoiles, dépôt reconnu, balayage propre) restera inoffensive, lorsqu'elle pourra réellement changer le contenu qu'elle exécute après l'examen.

Les implications pour les entreprises et les responsables de la sécurité sont claires et profondes. Un agent exécutant une compétence agit souvent avec le contexte et les permissions de l'utilisateur ou d'un système automatisé; cela signifie qu'une compétence malveillante ou manipulée peut devenir une porte vers les ressources internes. Les signaux de confiance du public ne remplacent pas les commandes techniques continues.

Pour les organisations qui ont déjà déployé des agents, la première priorité devrait être l'inventaire : identifier les compétences qui sont installées dans les comptes ministériels, vérifier quels domaines externes et URL sont consultés, et bloquer ou mettre en quarantaine ceux qui n'ont pas fait l'objet de contrôles centralisés. L'examen en temps opportun au moment de l'installation n'est pas suffisant; la surveillance et la revérification sont nécessaires pour modifier les ressources à distance.

En termes opérationnels, les compétences devraient être traitées comme des logiciels tiers, et non comme des fragments de texte. Cela nécessite des mesures qui vont au-delà de l'analyse statique typique: cliquez sur versions(aim à des dispositifs immuables signés ou des engagements spécifiques), exiger tout code exécutable pour aller dans le paquet vérifié ou dans un stockage immuable (libérations avec hash), appliquer le principe de moins de privilège et limiter l'évacuation du réseau des agents par des filtres proxy ou DNS qui évitent les téléchargements à partir de domaines non approuvés.

Les fournisseurs de plateformes de marchés et d'agents doivent également assumer la responsabilité technique: vérifier non seulement le paquet livré, mais aussi les domaines et les paramètres que la compétence déclare, exiger des signatures et des manifestes reproductibles, offrir des contrôles de re-analyse automatique lors du changement de ressources externes et exposer les autorisations détaillées à l'utilisateur final avant l'installation. Sans ces changements, l'écosystème continuera de compter sur des signaux fragiles comme les étoiles GitHub ou sur un résultat de balayage opportun.

Tout dans le rapport AIR ne peut pas être ramené au bas de la lettre sans vérification indépendante: le chiffre de «26 000 agents» et certains scénarios de contrôle absolu sont des revendications de la société elle-même, qui annonce également un marché géré dans sa déclaration. Pourtant, la méthode ils ont montré et la faiblesse structurelle qu'il expose sont supportés sur la base de tests précédents et d'analyses tierces.

D'un point de vue défensif, des recommandations concrètes et réalisables comprennent : l'audit et l'invention des compétences installées, la centralisation de l'approbation des nouvelles compétences dans une seule fenêtre contrôlée, l'application de l'inspection et du blocage de l'évacuation, l'exigence d'artéfacts immuables et signés dans les paquets, la réévaluation automatique des compétences par rapport aux changements dans leurs URL externes, et la réduction des permis qu'une compétence peut obtenir. Ces mesures n'éliminent pas le risque, mais modifient la dynamique d'attaque, augmentant ainsi le coût opérationnel d'un attaquant.

L'incident est aussi un appel à l'industrie : les fournisseurs d'agents et de marques doivent améliorer leurs processus de validation continue et fournir des outils aux organisations pour imposer des politiques de sécurité. Entre-temps, l'équipement de sécurité et les TI responsables ne devraient pas se fonder sur des mesures publiques visibles comme substitut au contrôle technique. Pour en savoir plus sur les risques techniques et les audits de sécurité des logiciels, des ressources telles que le blog Trail of Bits offrent une analyse détaillée https: / / blog.trailofbits.com, et les projets de sécurité de la chaîne d'approvisionnement comme OWASP contiennent des lignes directrices applicables à ce contexte https: / / owasp.org.