Des skills qui promettent l’autonomie, mais déplacent la frontière de sécurité
Les agents fondés sur des grands modèles de langage ne se contentent plus de répondre à des questions. Ils lisent des fichiers, exécutent du code, appellent des API, manipulent des dépôts Git, consultent des bases de données et interagissent avec des services d’entreprise. Cette capacité d’action passe de plus en plus par des extensions tierces, souvent appelées skills, tools, plugins ou connecteurs MCP selon les écosystèmes.
C’est précisément cette couche intermédiaire que deux nouvelles prépublications sur arXiv, mises en ligne le 12 mai 2026, placent sous le microscope. La première, intitulée Behavioral Integrity Verification for AI Agent Skills, propose de vérifier si une skill fait réellement ce qu’elle déclare faire. La seconde, Counterfactual Trace Auditing of LLM Agent Skills, cherche plutôt à mesurer comment une skill modifie le comportement d’un agent, même lorsque le taux de réussite global d’une tâche semble inchangé.
Il faut être clair sur la nature de ces sources : arXiv publie des préprints, pas des articles évalués par les pairs. Ces travaux doivent donc être lus comme des contributions de recherche préliminaires, non comme une preuve définitive. Leur intérêt est néanmoins important : ils s’attaquent à une zone aveugle de la sécurité des agents IA, celle des artefacts tiers que l’utilisateur installe souvent avec une confiance excessive.
La vérification comportementale : comparer la promesse et le code
Dans Behavioral Integrity Verification for AI Agent Skills, Yuhao Wu, Tung-Ling Li et Hongliang Liu formalisent un problème qu’ils appellent BIV, pour Behavioral Integrity Verification. L’idée est simple à résumer, mais difficile à industrialiser : comparer les capacités déclarées d’une skill avec ses capacités réelles.
Une skill peut se présenter comme un outil de génération de graphiques, de résumé de documents ou d’automatisation de tests. Mais son contenu peut inclure des scripts, des instructions, des dépendances ou des accès qui vont beaucoup plus loin : lecture de fichiers sensibles, appels réseau inattendus, exécution shell, manipulation de credentials. Les auteurs proposent donc une comparaison typée entre ce qui est annoncé dans les métadonnées, les instructions et la documentation, et ce qui ressort d’une analyse du code et du comportement potentiel.
Leur cadre combine deux familles de techniques. D’un côté, une analyse déterministe du code, plus proche des outils classiques de sécurité logicielle. De l’autre, une extraction assistée par LLM pour interpréter les instructions en langage naturel et les relier à une taxonomie de capacités. Le résultat n’est pas seulement un verdict binaire, mais une preuve structurée : quelles capacités sont déclarées, lesquelles sont implicites, lesquelles sont absentes de la description et lesquelles pourraient indiquer une intention malveillante.
Le chiffre le plus frappant vient de leur analyse de 49 943 skills issues du registre OpenClaw : 80,0 % présenteraient un écart entre comportement déclaré et comportement implémenté. Les auteurs estiment que la majorité des écarts relèvent de l’oubli ou d’une mauvaise documentation, avec 81,1 % attribués à la négligence des développeurs, contre 18,9 % à une intention adversariale. Ils signalent aussi que 5,0 % des skills porteraient des chaînes d’attaque multi-étapes prédites. Sur un banc d’essai de 906 skills malveillantes, leur approche atteint un score F1 de 0,946, ce qui suggère une capacité de détection prometteuse, mais encore à valider indépendamment.
L’apport majeur est de déplacer l’audit en amont. Au lieu d’attendre qu’un agent fasse une action risquée à l’exécution, BIV traite la skill elle-même comme un paquet logiciel à certifier. C’est une logique proche de la sécurité de la chaîne d’approvisionnement logicielle : lire la notice ne suffit pas, il faut inspecter ce qui est livré.
L’audit contrefactuel : voir ce que le taux de réussite cache
La deuxième prépublication, Counterfactual Trace Auditing of LLM Agent Skills, part d’un constat différent. Aujourd’hui, beaucoup d’évaluations comparent un agent avec et sans skill, puis regardent seulement si la tâche est réussie. Pour les auteurs Xiaolin Zhou, Jinbo Liu, Li Li, Ryan A. Rossi et Xiyang Hu, cette mesure est trop grossière.
Leur méthode, CTA pour Counterfactual Trace Auditing, crée une paire de traces : une exécution avec la skill et une exécution sans la skill, sur la même tâche. Les traces sont ensuite découpées en phases orientées vers un objectif, alignées, puis annotées avec des Skill Influence Patterns, ou SIP. Ces annotations décrivent l’effet comportemental de la skill : a-t-elle aidé l’agent à récupérer d’une erreur, l’a-t-elle poussé vers une solution superficielle, a-t-elle provoqué de la copie littérale de gabarits, a-t-elle généré des artefacts hors sujet, a-t-elle augmenté la planification ou la consommation de tokens ?
Les auteurs testent CTA sur SWE-Skills-Bench avec Claude, à travers 49 tâches de génie logiciel. Résultat : le taux de réussite moyen ne progresse que de 0,3 point de pourcentage, ce qui pourrait faire croire que les skills ont peu d’effet. Mais l’audit identifie 522 instances de SIP dans les mêmes traces. Autrement dit, les skills changent bel et bien le comportement de l’agent, mais pas toujours d’une manière visible dans le score final.
Cette approche est importante pour les entreprises. Un agent peut conserver un bon taux de réussite tout en devenant plus coûteux, plus fragile, plus bavard, plus dépendant d’un gabarit ou plus susceptible de créer des actions non demandées. CTA propose donc une forme d’observabilité comportementale : non seulement savoir si l’agent a réussi, mais comprendre par quel chemin il est passé.
Un contexte déjà balisé par NIST, OWASP, Anthropic, OpenAI et Microsoft
Ces deux préprints arrivent dans un contexte où les principaux acteurs de la sécurité IA convergent sur un même diagnostic : les agents dotés d’outils brouillent la frontière entre instruction, donnée et action.
Le NIST décrit l’agent hijacking comme une variante de l’injection indirecte de prompt : un contenu apparemment ordinaire, comme un courriel, une page web ou un fichier, contient des instructions malveillantes que l’agent interprète comme opératoires. OWASP classe depuis longtemps l’injection de prompt et l’agency excessive parmi les risques majeurs des applications LLM, et ses travaux récents sur les systèmes agentiques mettent explicitement en avant le détournement d’objectif, l’abus d’outils, les vulnérabilités de chaîne d’approvisionnement et les agents incontrôlés.
Anthropic, dans sa documentation sur les Agent Skills de Claude, prévient que les skills provenant de sources non fiables doivent être auditées, car elles peuvent diriger Claude vers des appels d’outils ou de code qui ne correspondent pas à leur objectif affiché. OpenAI, dans ses recommandations pour la construction d’agents, insiste de son côté sur les approbations humaines, les garde-fous, l’isolation des données non fiables et les évaluations de traces. Microsoft pousse une lecture plus institutionnelle : traiter les agents comme des applications privilégiées, avec identité, permissions limitées, journalisation, politiques d’exécution et gouvernance de cycle de vie.
Ces sources ne sont pas neutres. Anthropic, OpenAI et Microsoft vendent ou opèrent des plateformes agentiques ; leurs recommandations servent aussi leurs propres architectures. Mais elles confirment une tendance de fond : la sécurité des agents ne peut plus reposer uniquement sur le modèle. Elle doit englober les extensions, les permissions, les traces, les registres, les mises à jour et les politiques d’exécution.
Ce que cela annonce : vers un App Store auditable pour agents IA
Si BIV et CTA se confirment, l’avenir des skills pourrait ressembler à un mélange d’App Store, de registre de paquets open source et de pipeline DevSecOps. Avant installation, une skill serait analysée pour vérifier ses capacités réelles : accès fichiers, réseau, shell, credentials, dépendances externes. Pendant ou après l’exécution, ses effets seraient comparés à une trace contrefactuelle afin de détecter les comportements inattendus.
Dans un monde idéal, une skill ne se contenterait pas d’un fichier descriptif. Elle fournirait un manifeste de capacités vérifiable, des permissions minimales, une signature cryptographique, un historique de versions, des résultats d’audit, des tests de non-régression comportementale et une politique de révocation. Les entreprises pourraient bloquer automatiquement les skills dont les capacités dépassent la description, ou exiger une approbation humaine pour les opérations irréversibles.
La difficulté sera de réduire les faux positifs. Une skill de développement logiciel a parfois légitimement besoin de lire des fichiers, de lancer des tests ou d’appeler le réseau. Le problème n’est donc pas l’existence d’une capacité dangereuse, mais son inadéquation au contexte déclaré, son absence de justification ou son usage dans une chaîne d’actions non anticipée.
La leçon la plus importante est peut-être culturelle. Les agents IA donnent l’impression d’une interface conversationnelle, mais les skills les transforment en logiciels exécutables avec autorité déléguée. Installer une skill tierce ne devrait plus être perçu comme ajouter une astuce à un chatbot. C’est plutôt accorder une permission à un composant qui peut agir en votre nom.
Les deux préprints n’apportent pas encore une solution complète. Ils proposent toutefois deux briques complémentaires : certifier ce qui est installé, puis auditer ce que cela change réellement. Pour les équipes de sécurité, c’est probablement le bon niveau d’analyse : ni confiance aveugle dans les descriptions, ni panique face à toute automatisation, mais une traçabilité systématique de la capacité, de l’intention et de l’effet.