Les compétences d’IA malveillantes étendent le risque de sécurité en entreprise

Google News a mis en lumière un conflit saisissant autour de l’IA d’entreprise : les agents acquièrent des capacités utiles grâce aux compétences, tandis que les attaquants exploitent ces mêmes extensions. Des recherches récentes ont identifié plus de 3 000 compétences malveillantes parmi près de 900 000 analysées par l’éditeur de sécurité ESET. Cette découverte transforme une fonctionnalité pratique des agents en problème de chaîne d’approvisionnement logicielle.

Cette préoccupation dépasse une seule marketplace ou campagne de malwares. Les compétences d’IA peuvent associer des instructions, des scripts, de la documentation externe et l’accès à des systèmes sensibles. Une compétence compromise peut donc influencer à la fois les décisions d’un agent et les outils qu’il contrôle.

Les entreprises sont désormais confrontées à un compromis entre autonomie et contrôle. Les écosystèmes ouverts accélèrent l’expérimentation, mais leurs signaux de confiance restent moins solides que ceux entourant les paquets logiciels établis. Des chercheurs ont déjà montré que la popularité d’un dépôt, l’approbation d’une marketplace et l’analyse statique peuvent toutes échouer simultanément.

Ce que Google News a mis en lumière concernant les compétences d’IA malveillantes

Le changement important tient à l’ampleur du phénomène, et non à la première apparition d’une extension malveillante.

Les recherches H1 2026 d’ESET ont couvert l’activité de menace observée de décembre 2025 à mai 2026. L’entreprise a déclaré avoir analysé près de 900 000 compétences d’IA et trouvé des dizaines de milliers d’exemples suspects. Plus de 3 000 ont été classés comme malveillants.

Une compétence d’IA est un paquet réutilisable qui indique à un agent comment accomplir une tâche, utiliser des outils et traiter les informations associées. Certaines compétences ne contiennent guère plus que des instructions. D’autres relient l’agent à des scripts, des services, des fichiers, des outils en ligne de commande ou des ressources web évolutives.

La population analysée s’est fortement développée pendant la période de recherche. Selon des informations fondées sur ces résultats, ESET a analysé environ 60 000 compétences uniques en mars et près de 900 000 en mai. Les détections suspectes sont passées d’environ 10 000 à plus de 25 000 durant cet intervalle.

Les détections malveillantes sont passées d’environ 600 à plus de 3 000. Ces chiffres ne permettent pas d’établir que chaque dépôt présente le même taux d’infection. Ils montrent toutefois que les équipes de sécurité doivent évaluer un volume croissant de comportements d’agents tiers.

Le résumé public du rapport sur les menaces d’ESET décrit les compétences comme de petits composants fonctionnels utilisés par les agents. L’entreprise a trouvé des instances malveillantes et suspectes dans les dépôts qu’elle a examinés.

Les chercheurs ont observé des capacités associées à l’exécution de commandes, à l’injection de code, à l’accès aux fichiers, au chargement d’identifiants, à l’obfuscation et aux téléchargements externes. Ces fonctionnalités ne sont pas automatiquement malveillantes. Elles deviennent dangereuses lorsque l’objectif déclaré de la compétence ne les justifie pas.

Une compétence de développement légitime peut nécessiter un accès au shell pour compiler une application. Un assistant documentaire peut avoir besoin d’autorisations pour lire certains fichiers. La question de sécurité est de savoir si ces autorisations restent limitées, visibles et liées à un objectif métier approuvé.

Les malwares traditionnels arrivent souvent sous la forme d’un exécutable, d’une pièce jointe ou d’un paquet compromis. Les compétences d’IA malveillantes ajoutent un autre format de distribution. Des instructions nuisibles peuvent apparaître dans un langage ordinaire qu’un agent traite comme des directives opérationnelles.

Cette conception complique la détection. Lors de son examen, une compétence peut ne pas contenir de binaire malveillant reconnaissable. Elle peut plutôt diriger l’agent vers une page externe, obtenir plus tard de nouvelles instructions ou détourner des outils légitimes déjà présents.

L’article de Google News est important parce qu’il relie ces constats distincts en une histoire de risque pour l’entreprise. La menace ne se limite plus aux agents personnels expérimentaux. Les compétences entrent dans les flux de travail des ingénieurs, spécialistes du marketing, analystes, designers et équipes commerciales.

Ces utilisateurs peuvent installer des extensions sans considérer cette action comme un déploiement logiciel. Un court fichier texte paraît moins dangereux qu’un programme d’installation. Pourtant, l’agent qui lit ce fichier peut déjà avoir accès aux e-mails, au stockage cloud, au code source ou aux connaissances internes.

L’écart entre l’apparence et l’autorité crée la tension centrale. Les compétences ressemblent souvent à de la documentation, mais elles peuvent fonctionner comme une logique de workflow exécutable. Les entreprises ne peuvent pas les gouverner en toute sécurité comme de simples prompts inoffensifs.

Pourquoi la sécurité des agents d’IA ressemble désormais à la défense de la chaîne d’approvisionnement

Une compétence devient une dépendance d’entreprise lorsqu’un agent s’appuie sur elle pour agir au sein des systèmes de l’entreprise.

La sécurité de la chaîne d’approvisionnement logicielle suit l’origine des composants, les personnes qui les maintiennent, les versions déployées et la manière dont les mises à jour atteignent la production. Les compétences d’IA malveillantes exigent bon nombre des mêmes contrôles. Elles introduisent également des risques comportementaux que l’analyse conventionnelle des paquets n’a pas été conçue pour interpréter.

Une compétence peut coordonner plusieurs outils fiables sans exploiter de vulnérabilité logicielle. Elle peut indiquer à un agent de localiser un identifiant, de transformer un fichier et d’envoyer le résultat ailleurs. Chaque appel d’outil individuel peut sembler légitime lorsqu’il est examiné isolément.

Le risque augmente avec l’autorité de l’agent. Un assistant limité à la rédaction de texte présente une exposition moindre qu’un agent connecté à un shell, un navigateur, un dépôt de code et un compte cloud. Les agents d’entreprise se rapprochent de plus en plus de ce second modèle.

Cela crée un effet multiplicateur. La compétence fournit les instructions, tandis que l’agent fournit les autorisations, le raisonnement et l’exécution. Un attaquant n’a pas besoin d’intégrer chaque capacité dans l’extension malveillante.

La marketplace ClawHub d’OpenClaw est devenue une première étude de cas. Des chercheurs ont documenté des compétences malveillantes qui visaient des identifiants et des actifs en cryptomonnaie. Certaines diffusaient des malwares établis, tandis que d’autres manipulaient des transactions pilotées par des agents.

L’Unit 42 de Palo Alto Networks a examiné l’activité de la marketplace entre février et mai 2026. Son analyse de la chaîne d’approvisionnement a identifié cinq compétences malveillantes non bloquées après l’introduction de nouvelles mesures de filtrage.

Deux diffusaient des voleurs d’informations macOS connectés à une infrastructure de commande et de contrôle. Une autre utilisait des fichiers volumineux pour contourner les seuils des scanners. Des compétences supplémentaires visaient la manipulation financière au moyen de comportements propres aux agents autonomes.

L’Unit 42 a signalé les cinq compétences à ClawHub. La marketplace les a retirées et a banni les comptes associés. Cette réponse a réduit l’exposition immédiate, sans éliminer le problème de distribution sous-jacent.

Des découvertes antérieures avaient déjà conduit ClawHub à intégrer VirusTotal et ClawScan. Ces services ont ajouté un filtrage proactif et une analyse au niveau du code. OpenClaw a également annoncé un travail avec Nvidia sur l’analyse des compétences et la documentation.

Cette séquence est instructive. Une marketplace a ajouté des défenses après l’apparition de campagnes malveillantes, mais les chercheurs ont continué à trouver des compétences capables d’évasion. Cela rappelle le concours de longue date autour des extensions de navigateur, des registres de paquets et des applications mobiles.

Les compétences d’agents ajoutent une complication supplémentaire, car leur contenu effectif peut s’étendre au-delà de l’artefact téléchargé. Une compétence locale peut demander à l’agent de lire de la documentation en ligne. Cette page externe peut changer sans modifier la compétence examinée.

Les équipes de sécurité ne peuvent donc pas se fier uniquement à une décision prise au moment de l’installation. Un résultat sûr décrit ce qu’un scanner a observé à un instant précis. Il ne garantit pas que chaque dépendance restera inchangée.

L’inventaire d’entreprise devient également plus difficile lorsque les employés peuvent ajouter directement des compétences. Une entreprise peut approuver une plateforme d’agents sans savoir quelles extensions communautaires les utilisateurs installent ensuite. Cela crée des comportements d’IA fantôme au sein d’un produit officiellement approuvé.

Cette distinction est importante pour la réponse aux incidents. Les enquêteurs doivent savoir quelle compétence s’est exécutée, quelles instructions elle a chargées, quels outils elle a appelés et quelles informations elle a consultées. Les journaux d’applications ordinaires peuvent ne pas capturer cette chaîne complète.

Les organisations maintiennent déjà des nomenclatures logicielles pour certains systèmes. Les déploiements d’agents nécessitent un registre associé couvrant les modèles, outils, compétences, sources d’instructions externes, autorisations et versions. Sans cette cartographie, les intervenants ne peuvent pas déterminer l’exposition de manière fiable.

Un registre interne consultable peut également faciliter les enquêtes après la découverte d’une extension risquée. Les équipes qui organisent des preuves techniques locales au moyen d’une base de connaissances d’ingénierie peuvent conserver les décisions de revue, la responsabilité et le contexte de remédiation.

Ce registre ne remplace pas la sécurité à l’exécution. Il aide à établir qui a approuvé une dépendance et pourquoi. L’exigence plus large reste un contrôle continu de ce que les agents peuvent lire, invoquer et transmettre.

Le compromis central oppose l’autonomie des agents au contrôle de l’entreprise

Les compétences rendent les agents plus capables en réduisant la supervision répétée, ce qui laisse également aux instructions malveillantes la possibilité d’opérer.

Un agent d’entreprise devient utile lorsqu’il peut accomplir un travail en plusieurs étapes. Il peut recueillir les exigences, examiner des fichiers, interroger un service, générer un artefact et livrer le résultat. Exiger une approbation après chaque action mineure supprimerait une grande partie de cette valeur.

Accorder une large autonomie résout le problème d’utilisabilité, mais élargit le rayon d’impact potentiel. Une extension compromise peut réutiliser les mêmes connexions qui rendent l’agent productif. L’attaquant hérite indirectement de l’accès via le workflow autorisé de l’agent.

Il ne s’agit pas simplement d’une opposition entre plateformes ouvertes et fermées. Un catalogue organisé peut toujours distribuer un composant compromis. Une compétence privée peut toujours devenir dangereuse après l’évolution de son dépôt, du compte de son mainteneur ou d’une dépendance externe.

Les marketplaces ouvertes augmentent l’exposition, car la publication et l’installation peuvent impliquer peu de friction. Elles rendent également possibles la recherche, le retrait et la revue par la communauté. Restreindre chaque agent aux compétences développées en interne réduirait certains risques, mais créerait de nouvelles charges de maintenance.

La question décisive est de savoir si l’autorité respecte le principe du moindre privilège. Une compétence de page d’atterrissage ne devrait pas nécessiter un accès illimité aux clés SSH ou aux identifiants cloud. Une compétence de synthèse ne devrait pas exécuter silencieusement des scripts shell téléchargés.

Ce principe paraît familier parce qu’il l’est. Le moindre privilège guide la sécurité des identités et des applications depuis des décennies. Les systèmes agentiques compliquent son application, car un agent peut assembler plusieurs actions individuellement autorisées en une séquence dangereuse.

Les compétences opèrent également à un niveau sémantique. Leurs instructions décrivent des objectifs et des procédures en langage naturel. Les contrôles de sécurité traditionnels excellent dans l’identification de motifs de code connus, de hachages de fichiers et d’indicateurs réseau.

Ils sont moins efficaces lorsque le comportement dangereux s’exprime sous la forme de directives opérationnelles plausibles. Une instruction peut demander à l’agent d’obtenir un prérequis, de valider un compte ou de synchroniser une configuration. L’intention nuisible n’émerge qu’à travers le contexte.

Les conseils d’OWASP sur les compétences agentiques distinguent cette couche comportementale de la couche de connexion aux outils. Les outils définissent les actions disponibles, tandis que les compétences orchestrent ces actions en workflows.

OWASP identifie les compétences malveillantes, la compromission de la chaîne d’approvisionnement, les privilèges excessifs, les instructions externes non fiables, l’isolation insuffisante et la dérive des mises à jour parmi les principaux risques. Cette liste montre pourquoi un seul scanner ou une seule politique ne peut pas couvrir l’ensemble du problème.

Une architecture sécurisée nécessite plusieurs frontières. La marketplace doit établir la provenance. La plateforme d’agents doit appliquer les autorisations. Les contrôles d’exécution doivent observer les actions, tandis que l’organisation doit maintenir un inventaire et une attribution des responsabilités.

L’approbation humaine reste utile lorsqu’elle encadre un risque significatif. L’envoi d’un brouillon ordinaire vers un dossier interne peut être automatisé. Le téléversement de fichiers confidentiels ou la modification d’une infrastructure de production devrait exiger une autorisation plus forte.

Le défi consiste à éviter les invites dénuées de sens. Les utilisateurs approuvent régulièrement des demandes qu’ils ne comprennent pas, surtout lorsque les interruptions deviennent fréquentes. Une boîte de dialogue d’approbation ne peut pas compenser des autorisations par défaut trop étendues ou des modifications invisibles de dépendances.

Les acheteurs en entreprise doivent également distinguer l’utilité d’une skill de sa fiabilité. La popularité démontre l’adoption, pas la sécurité. Un grand nombre d’étoiles peut fournir une preuve sociale sans rien indiquer sur le comportement actuel d’instructions externes.

La même prudence s’applique aux badges des marketplaces. Une approbation peut confirmer qu’une soumission a passé une revue. Elle ne garantit pas que les ressources liées, la propriété du dépôt ou les packages en aval resteront stables.

Ce compromis façonnera l’adoption en entreprise. Les équipes de sécurité qui bloquent toute extension pousseront l’expérimentation vers des environnements non gérés. Celles qui autorisent des installations sans restriction créeront un graphe de dépendances croissant qu’elles ne pourront pas inspecter.

Le juste milieu praticable est une autonomie gouvernée. Les utilisateurs peuvent accéder à des capacités approuvées, tandis que les actions à haut risque restent isolées et observables. Les skills reçoivent des autorisations liées à leur finalité, et non toutes les autorisations offertes à l’agent hôte.

L’autonomie gouvernée exige également une capacité de révocation. Lorsqu’une skill devient dangereuse, les administrateurs doivent pouvoir localiser chaque installation, la désactiver, invalider les identifiants exposés et examiner l’activité associée. Le simple retrait d’une marketplace est insuffisant.

Les scanners statiques perdent la course à la confiance

L’avertissement le plus fort est venu d’une skill de recherche d’apparence inoffensive qui aurait atteint plus de 26 000 agents après avoir passé les scanners disponibles.

Les chercheurs d’AIR Security ont créé une skill appelée brand-landingpage. Elle semblait aider des utilisateurs non techniques à concevoir une landing page avec l’outil de design Stitch de Google. La skill offrait une fonctionnalité réelle, ce qui rendait la proposition crédible.

Les chercheurs l’ont soumise à une collection open source populaire réunissant 156 skills et environ 36 000 étoiles GitHub. La contribution a été acceptée après plusieurs jours. AIR a ensuite fait la promotion de la skill via une publicité Instagram ciblant les spécialistes du marketing, les designers et les commerciaux.

La skill empaquetée ne contenait initialement aucune charge utile malveillante évidente. Elle dirigeait plutôt les agents vers une documentation d’installation sur un domaine contrôlé par les chercheurs. Ce domaine redirigeait d’abord les visiteurs vers le service Stitch légitime.

AIR a ensuite modifié les instructions externes. La page révisée indiquait aux agents de télécharger et d’exécuter un script. Pour l’expérience, la charge utile collectait des adresses e-mail afin que les utilisateurs concernés puissent être avertis.

Les chercheurs ont déclaré qu’aucun agent n’avait été endommagé. Ils ont également affirmé que la technique aurait pu atteindre des conversations privées et des systèmes internes connectés. Ces impacts plus étendus étaient des issues possibles, et non des pertes documentées issues de l’expérience.

Le récit d’AIR sur le test de skill contrôlé indique que les scanners de Cisco, Nvidia et skills.sh ont marqué la soumission comme sûre. Le résultat a mis en évidence une limite structurelle de la revue statique.

Un scanner peut inspecter les fichiers actuels d’une skill tout en manquant des contenus futurs hébergés ailleurs. La documentation externe agit comme une dépendance mutable. Son propriétaire peut modifier les instructions après que la marketplace et les utilisateurs ont établi leur confiance.

Cette méthode ressemble aux mises à jour malveillantes différées dans des écosystèmes logiciels établis. La différence réside dans le mode de diffusion. L’attaquant peut modifier un langage ordinaire que l’agent interprète ensuite comme une orientation procédurale faisant autorité.

L’analyse statique conserve son utilité. Elle peut identifier du code malveillant connu, des commandes obscurcies, des URL suspectes, des autorisations excessives et des dépendances de packages dangereuses. L’erreur consiste à considérer un scan propre comme une décision de confiance durable.

Les tests comportementaux ajoutent une couche supplémentaire. Un sandbox peut exécuter la skill dans un environnement d’agent restreint et observer les tentatives d’accès aux fichiers, de téléchargement, d’exécution de commandes et de communication réseau. Cette approche peut révéler un comportement dissimulé derrière un texte plausible.

Le sandboxing a toutefois lui aussi ses limites. Un attaquant peut retarder l’activation, réagir à des signaux environnementaux ou fournir des instructions inoffensives aux systèmes d’analyse connus. Un test ne peut pas non plus anticiper chaque interaction entre une skill et les outils internes d’une entreprise.

La surveillance continue est donc importante après l’installation. Les systèmes de sécurité doivent détecter lorsqu’une skill contacte un nouveau domaine, demande des données plus étendues, modifie son mode d’exécution ou invoque des outils au-delà de son objectif attendu.

L’épinglage de contenu peut réduire la dérive des instructions externes. Une entreprise peut conserver la version examinée de la documentation ou exiger des hachages cryptographiques pour les composants téléchargés. L’agent ne devrait pas faire automatiquement confiance à ce qu’une URL mutable sert ultérieurement.

Les contrôles réseau fournissent un autre point de vérification. Les skills qui n’ont pas besoin d’un accès à Internet ne devraient pas le recevoir. Les autres peuvent être limitées à des domaines, méthodes et destinations approuvés.

La visibilité à l’exécution doit aller au-delà du trafic réseau. Les défenseurs ont besoin d’une trace reliant la demande de l’utilisateur, la skill sélectionnée, les instructions récupérées, les décisions du modèle, les appels d’outils et les mouvements de données qui en résultent. Sinon, chaque action perd son contexte comportemental.

L’expérience d’AIR ne prouve pas que toute skill populaire est dangereuse. Elle démontre que des signaux de confiance courants peuvent converger vers une conclusion erronée. La réputation, l’acceptation par la marketplace et le scanning ont tous soutenu le même artefact conçu de manière malveillante.

C’est l’angle sceptique que les dirigeants d’entreprise devraient retenir. Les fournisseurs de sécurité introduisent des scanners spécifiques à l’IA, mais aucun scanner ne peut offrir une assurance permanente pour des workflows mutables. Les affirmations des produits devraient être évaluées au regard de tests d’évasion en conditions réelles et de taux d’échec transparents.

La couverture de Google News peut accroître la sensibilisation, mais la sensibilisation n’établit pas un contrôle technique. Les acheteurs ont besoin de preuves que les plateformes d’agents peuvent contraindre les actions après qu’une skill a passé la revue. La prévention et le confinement doivent fonctionner ensemble.

Qui subit la pression liée à l’expansion du risque

Les plateformes d’agents, les fournisseurs de sécurité et les acheteurs en entreprise partagent désormais la responsabilité d’une dépendance qu’aucun ne peut gouverner seul.

Les opérateurs de marketplaces subissent la pression la plus immédiate. Ils doivent équilibrer une croissance communautaire rapide avec la vérification des éditeurs, la revue des artefacts, les contrôles de mise à jour et la réponse aux incidents. Une friction accrue lors des soumissions peut ralentir la croissance, mais des contrôles faibles nuisent à la confiance.

Les développeurs de plateformes d’agents contrôlent l’environnement d’exécution. Ils décident si les skills s’exécutent avec les autorisations de l’hôte, dans des conteneurs ou via des outils restreints. Leur architecture détermine jusqu’où une instruction malveillante peut atteindre.

Les fournisseurs de sécurité font face à un test différent. Ils doivent identifier les comportements nuisibles exprimés par du code, du langage naturel, des sites web mutables et des outils administratifs légitimes. Les signaux existants provenant des endpoints et du réseau restent précieux, mais le contexte sémantique devient essentiel.

Les équipes de sécurité d’entreprise ne peuvent pas externaliser l’ensemble du problème. Elles choisissent les plateformes qui entrent dans l’organisation et les connexions que ces plateformes reçoivent. Elles déterminent également si les employés peuvent installer des skills communautaires sans revue.

Les développeurs restent un groupe à haut risque, car les agents de codage disposent souvent d’un accès au shell et aux dépôts. Une skill malveillante pourrait cibler le code source, les identifiants de packages, les clés de signature, les tokens cloud ou la configuration de déploiement.

Les utilisateurs non techniques présentent une exposition différente. Une skill de marketing ou de vente peut accéder aux e-mails, aux dossiers clients, aux actifs de marque, aux notes de réunion et aux systèmes de contenu. Son interface conviviale peut masquer l’autorité de l’agent sous-jacent.

Les équipes achats doivent donc poser des questions qui dépassent la précision du modèle. Elles devraient demander comment la plateforme découvre les skills installées, enregistre les versions, gère les instructions externes et sépare les environnements utilisateurs.

Elles doivent aussi comprendre la révocation. Les administrateurs peuvent-ils désactiver une skill sur chaque endpoint ? Peuvent-ils identifier quels identifiants étaient disponibles pendant sa période d’installation ?

Les équipes de conformité se préoccuperont des preuves. Si un agent transmet des informations clients via une skill non approuvée, l’organisation doit pouvoir reconstituer ce qui s’est passé. Une transcription générique de chatbot peut ne pas expliquer chaque appel d’outil en aval.

Les équipes de réponse aux incidents font face à des exigences similaires. Elles ont besoin de journaux immuables et d’une chronologie fiable. Elles doivent également savoir si une skill supprimée a créé une persistance ailleurs, comme un processus planifié ou une configuration modifiée.

Les conclusions de Unit 42 illustrent ce problème. Les chercheurs ont observé des mécanismes de persistance associés à une activité malveillante sur des marketplaces. La suppression de la fiche visible n’a pas automatiquement neutralisé chaque charge utile déployée ni chaque canal de commande.

Les entreprises devraient considérer les identifiants d’agents comme potentiellement exposés après une installation malveillante confirmée. Cela implique de révoquer les tokens pertinents, d’examiner l’activité d’authentification, de vérifier les fichiers modifiés et d’analyser les connexions sortantes.

Le risque n’est pas réparti uniformément entre tous les déploiements. Un agent de recherche isolé utilisant des données synthétiques entraîne des conséquences limitées. Un agent autonome connecté à des systèmes de production crée un problème de contrôle bien plus important.

Cette distinction devrait guider la politique. Les organisations peuvent classer les agents et les skills selon les données accessibles, les outils disponibles, l’autonomie, la portée réseau et l’impact métier. Les combinaisons à risque plus élevé reçoivent une revue et une surveillance plus strictes.

La pression atteint également les programmes de gouvernance de l’IA. Beaucoup de programmes se concentrent sur le choix du modèle, les conditions de confidentialité, l’exactitude des résultats et l’utilisation acceptable. Les skills IA malveillantes introduisent des dépendances opérationnelles qui relèvent davantage de la sécurité applicative que de la gouvernance des modèles.

Les comités de gouvernance ont besoin d’une responsabilité technique, et pas seulement de principes écrits. Quelqu’un doit approuver les sources de skills, maintenir l’inventaire, définir les limites d’autorisation et répondre lorsqu’une dépendance de confiance change.

L’approche gagnante ne reposera pas sur un seul département. L’ingénierie de plateforme peut appliquer les contrôles de déploiement. La sécurité peut surveiller les comportements, tandis que les responsables métier définissent les tâches acceptables et l’accès aux données.

Sans cette coordination, les organisations créeront deux voies insatisfaisantes. Les agents approuvés resteront trop contraints pour être utiles, tandis que les employés installeront des alternatives moins contrôlées. Les deux résultats affaiblissent la supervision de l’entreprise.

Trois signaux montreront si les défenses rattrapent leur retard

La prochaine phase sera mesurée à travers les contrôles des marketplaces, les preuves d’exécution en entreprise et les tests de détection indépendants.

Le premier signal sera de savoir si les principaux registres de skills adoptent une provenance vérifiable et un versionnage immuable. Une marketplace devrait identifier l’éditeur, conserver les artefacts examinés et exposer chaque modification. Les instructions externes ont également besoin de contrôles d’inventaire et d’intégrité.

Si les registres mettent largement en œuvre ces mesures, les attaquants rencontreront davantage de friction lorsqu’ils remplaceront du contenu de confiance. Cela renforcerait l’idée que les écosystèmes ouverts de skills peuvent mûrir sans abandonner les contributions de la communauté.

Si les registres continuent de s’appuyer sur la popularité et le scanning ponctuel, l’évaluation actuelle du risque se renforcera. Il faut s’attendre à davantage de charges utiles différées et de prises de contrôle de dépendances à mesure que les skills de valeur accumulent des utilisateurs.

Le deuxième signal concerne la capacité des plateformes d’agents d’entreprise à fournir des autorisations applicables au niveau de chaque skill. Les administrateurs ont besoin de limites concernant les fichiers, les outils, les identifiants, les commandes et les destinations réseau. Ces limites doivent accompagner le skill dans tous les déploiements.

Des traces d’exécution claires sont tout aussi importantes. Un analyste sécurité doit pouvoir relier une action au skill et aux instructions externes qui l’ont provoquée. Les journaux doivent résister aux manipulations locales et permettre des recherches à l’échelle de l’organisation.

Si les plateformes offrent ces contrôles, un skill malveillant devient plus facile à contenir. Il peut toujours pénétrer dans l’environnement, mais sa capacité à atteindre des actifs sans rapport serait réduite. Cela atténuerait les scénarios d’entreprise les plus graves.

Si les plateformes exposent chaque skill à l’ensemble des autorisations de l’agent, le risque reste concentré au niveau du terminal. Une extension négligée peut hériter d’un accès à de nombreux systèmes sans rapport les uns avec les autres.

Le troisième signal est constitué de tests indépendants contre des attaques évolutives et différées. Les évaluations des scanners devraient inclure les changements d’instructions externes, les redirections depuis des domaines de confiance, les charges utiles dormantes, les prises de contrôle de dépôts et des outils légitimes utilisés dans des séquences dangereuses.

L’expérience menée sur 26 000 agents a fourni un tel test. Les futures évaluations nécessitent des méthodes reproductibles, des échantillons transparents et des divulgations distinguant les comportements suspects des malwares confirmés.

Une détection cohérente par des outils indépendants indiquerait que le marché développe des référentiels de sécurité communs. De fortes divergences montreraient que les fournisseurs définissent encore différemment les comportements malveillants.

Les organisations ne devraient pas attendre des normes parfaites. Elles peuvent commencer par inventorier les skills installés et associer chacun à un responsable, une source, une version, des autorisations et des dépendances externes.

Elles peuvent isoler les agents disposant d’autorisations élevées, limiter l’accès réseau et exiger une approbation pour les actions sensibles. Elles peuvent également réanalyser les skills lorsque leurs dépendances changent, et pas uniquement lors de leur installation initiale par les utilisateurs.

Les équipes devraient considérer les skills supprimés ou nouvellement signalés comme des déclencheurs d’incident. La réponse doit examiner les identifiants, la persistance, l’accès aux données et les communications sortantes. Supprimer le skill local n’est que la première étape.

L’attention de Google News portée aux skills d’IA malveillants devrait conduire à une question pratique : votre organisation peut-elle expliquer ce que chaque agent d’entreprise est autorisé à faire ? Si la réponse est incomplète, commencez par les agents connectés au code, aux systèmes cloud, aux données clients et aux communications internes. Cartographiez leurs skills, restreignez les autorisations inutiles et conservez les éléments nécessaires pour enquêter sur leurs actions. La sécurité des agents d’IA ne dépendra pas de la découverte d’un scanner parfait. Elle reposera sur la combinaison d’une distribution fiable, d’autorisations limitées, d’une surveillance continue et d’une révocation rapide avant qu’une extension apparemment utile ne devienne un incident d’entreprise.