Une skill est du code, et le code a besoin d'un point de contrôle

Une skill est du code, et le code a besoin d'un point de contrôle

NVIDIA a mis en open source cette semaine un outil nommé SkillSpector. Sa mission est étroite et attendue depuis longtemps : analyser les skills d'agents à la recherche de problèmes de sécurité avant qu'un agent ne les charge. Le projet embarque la détection de 64 motifs de vulnérabilité, un chiffre sur lequel il vaut la peine de s'arrêter, car il implique que quelqu'un s'est assis pour énumérer les façons dont une skill peut mal tourner.

En parallèle, Cloudflare a publié une skill d'audit de sécurité qui exécute des audits en plusieurs phases sur une base de code et produit des constats lisibles par machine, tandis que GitHub a détaillé un classificateur de détection de secrets sensible au contexte, qui a augmenté de 11,5 % l'acceptation pondérée des vrais constats tout en réduisant de 86 % le temps médian d'analyse. Trois équipes différentes, trois angles différents, même conclusion : la couche où les agents reçoivent leurs instructions est devenue une infrastructure, et une infrastructure se fait auditer.

Ce qu'une skill est réellement

Le mot "skill" fait paraître l'ensemble plus doux qu'il ne l'est. Une skill n'est pas un réglage. C'est un ensemble d'instructions et, très souvent, de scripts, de modèles et de définitions d'outils qu'un agent va lire et suivre avec les permissions qui lui ont été accordées.

Cette dernière proposition résume le modèle de sécurité en une phrase. Une skill n'a pas besoin d'exploit, parce qu'elle ne force pas l'entrée. On l'invite, on lui remet les clés et on lui demande de l'aide. Si ses instructions sont malveillantes ou simplement bâclées, l'agent les exécutera comme s'il s'agissait de votre propre intention, car autant qu'il puisse en juger, c'est le cas.

C'est le même problème que les gestionnaires de paquets ont rencontré il y a des décennies, et il a été résolu de la même manière : en supposant la chaîne logistique hostile et en y intégrant des points de contrôle. L'écosystème des agents en est encore au début de ce processus, et c'est pourquoi un projet comme SkillSpector compte bien plus que son nombre d'étoiles ne le suggère.

Pourquoi 64 motifs est le chiffre intéressant

Une liste de 64 motifs de vulnérabilité est une taxonomie, et les taxonomies sont la façon dont un domaine mûrit. Avant d'en avoir une, chaque incident est une surprise. Après, les incidents deviennent des instances de classes connues, ce qui veut dire qu'on peut les tester, les suivre, et finir par les éliminer par la conception.

Certaines de ces classes sont familières dans le logiciel ordinaire : commandes shell non sûres, entrées non validées, identifiants écrits dans des fichiers qui ne devraient jamais les contenir. D'autres sont propres à cette nouvelle couche. Des instructions qui élargissent le périmètre de l'agent sans le dire. Des prompts qui attirent du contenu non fiable et le traitent comme une commande. Des descriptions d'outils qui déforment ce que fait un outil, si bien que l'agent l'appelle pour la mauvaise raison. Des skills qui enchaînent d'autres skills en un chemin que personne n'avait prévu.

C'est dans cette dernière catégorie que réside la difficulté. Une skill est dangereuse exactement à proportion de ce qu'elle peut atteindre, et les agents modernes peuvent atteindre beaucoup : le système de fichiers, le réseau, d'autres agents, les outils qu'une autre skill a enregistrés. Le rayon d'impact d'une mauvaise skill n'est pas la skill. C'est tout ce que l'agent peut toucher, une cible mouvante qui dépend des autres skills chargées avant elle.

Le problème du contexte empoisonné

Le point inconfortable de la sécurité des agents, c'est que la frontière entre données et instructions n'est imposée par rien. Un modèle lit du texte. Il ne sait pas par nature quelles phrases sont des faits à considérer et lesquelles sont des ordres à obéir.

Ainsi, une skill qui récupère une page web, lit un gestionnaire de tickets ou résume un e-mail expose l'agent à du texte qui peut contenir des instructions. Si le modèle les suit, il n'y a aucun exploit au sens traditionnel. Il y a juste un système qui a fait ce que lui disait une chose en laquelle il n'aurait pas dû avoir confiance.

C'est pourquoi l'analyse doit se faire au moment du chargement et non au moment de l'incident. Une fois qu'une skill tourne dans un agent doté de larges permissions, la question intéressante a déjà reçu une mauvaise réponse. Le point de contrôle doit venir en premier, et il doit être automatique, car la revue humaine de chaque skill d'un registre ne passe pas à l'échelle et ne le fera jamais.

L'audit devient un produit

La publication de Cloudflare pointe une seconde tendance. Sa skill d'audit produit des constats lisibles par machine plutôt qu'une liste que quelqu'un doit lire. Cette formulation fait un vrai travail. Des constats qu'un humain doit lire sont des constats qu'un humain survolera. Des constats qu'un pipeline peut consommer peuvent devenir des tickets, des fusions bloquées ou des déploiements refusés sans que personne n'ait besoin de penser à regarder.

Le travail de GitHub sur la détection de secrets suit le même schéma. Les fuites de secrets augmentent avec la quantité de code produite, et la production de code a fortement augmenté. La réponse n'a pas été "embauchez plus de relecteurs". C'était un classificateur sensible au contexte qui réduit le bruit, afin que les alertes que les gens voient réellement soient plus susceptibles d'être vraies. La précision, dans l'outillage de sécurité, détermine si quelqu'un lit encore les alertes après le troisième mois.

Les deux relèvent du même geste à des couches différentes. Plutôt que de demander aux humains d'être plus vigilants, on rend le contrôle automatisé assez bon pour que l'attention humaine ne soit dépensée que là où elle compte. C'est la seule stratégie qui survit au contact du volume.

La question de gouvernance en dessous

Il y a ici une couche de politiques qui avance plus vite que la plupart des équipes ne le réalisent. Les systèmes de gestion de versions commencent à porter des métadonnées de provenance. Les registres de paquets ajoutent de l'attestation. Les organismes de normalisation travaillent sur la façon d'étiqueter les contenus synthétiques et d'identifier un agent. La direction est celle d'un monde où l'origine et l'intégrité d'un artefact doivent être prouvables et non supposées.

Les skills y occupent une place inconfortable, car une même skill peut être utile ou dangereuse selon le contexte. Une skill capable de modifier des fichiers est essentielle pour un agent de codage et catastrophique pour un agent qui lit aussi des e-mails non fiables. La décision de confiance n'est pas une propriété de la skill seule. C'est une propriété de la skill plus l'environnement plus les autres skills qu'elle peut atteindre.

Ce qui suggère que les analyseurs devront à terme faire plus que de la correspondance de motifs. La version vraiment difficile de cet outil vérifie si une combinaison proposée de skills accorde une capacité que personne n'a demandée, et avertit avant la mise en production plutôt qu'après.

Ce que les équipes devraient faire maintenant, sans surréagir

La panique n'est pas la bonne réponse, et traiter cela comme le problème de quelqu'un d'autre non plus.

Les gestes pratiques sont peu glorieux. Traitez les skills tierces comme des dépendances non fiables, parce que c'est exactement ce qu'elles sont. Épinglez les versions et relisez les diffs lorsqu'elles changent. Exécutez les agents dans des environnements où le rayon d'impact est borné, pour qu'une mauvaise skill ne puisse pas atteindre le réseau ou la base de données de production juste parce que l'agent était pratique. Journalisez quelles skills se sont chargées et ce qu'elles ont fait, car la première question difficile après un incident est ce qui a été autorisé à s'exécuter.

L'industrie a déjà parcouru ce chemin. Les écosystèmes de paquets étaient peu sûrs, puis ils ont été rendus pénibles à attaquer, et cette pénibilité est tout l'intérêt. Les skills d'agents se dirigent vers le même équilibre, et les projets publiés cette semaine sont la première tentative sérieuse de construire le point de contrôle. Y arriver avant l'incident coûte moins cher qu'après, et la seule chose nécessaire pour y arriver tôt est la volonté d'être ennuyeux à ce sujet.