Compétences d'agent : examiner le fichier qu'une compétence transmet à la suivante

Les sorties des compétences deviennent les entrées des travaux suivants¶

Les compétences d'agent regroupent des instructions, des scripts et des ressources pour les réutiliser. Leurs sorties peuvent devenir les entrées de travaux ultérieurs. Une synthèse, un tableur ou une base de données locale peut transmettre une erreur antérieure à une décision ultérieure, y compris après la fin de la conversation qui l'a produite. Notre note précédente sur les politiques dans la mémoire des agents portait sur des résumés de politiques stockés. Cette note porte sur les productions générées qu'une étape ultérieure traite comme des preuves.

SkillRelay, une prépublication de Liao et al. déposée le 9 octobre 2026, étudie cette persistance entre sessions distinctes. Dans son modèle de menace, l'attaquant contrôle plusieurs compétences avant l'exécution ; les tâches des utilisateurs et les politiques de projet de confiance restent hors de son contrôle. Les auteurs distinguent un résultat préjudiciable d'une chaîne d'attaque complète passant par la transmission visée. Lire l'article (v1).

La défense proposée par l'article combine la provenance et la revue des opérations proposées. La revue est obligatoire et consultative : après une recommandation défavorable, l'agent peut tout de même confirmer la requête examinée. Ce sont des résultats de benchmark contrôlés, et l'article n'estime pas la fréquence à laquelle les organisations rencontrent cette menace. Nous n'avons pas reproduit ses résultats. Cet article ne reprend pas ses taux d'attaque et de défense ; un lecteur qui les utilise devrait vérifier chaque dénominateur dans l'article.

La déclaration de couverture nomme ce que la revue laisse de côté¶

Le détail d'implémentation le plus utile se trouve dans le code publié. Au commit figé, les lignes 57 à 66 du fichier run.py du garde-fou construisent une déclaration de couverture qui nomme les opérations examinées par le prototype et les effets laissés hors de cette revue. Un fichier coverage.json consigne cette limite pour chaque exécution protégée. Déclaration de couverture au commit figé.

L'implémentation déclare d'autres limites : la provenance est suivie par étape, la médiation réseau est incomplète, et une empreinte calculée après une lecture ne peut pas montrer quels octets ont été lus pendant qu'un autre processus écrivait. Ce sont des limites de prototype que les auteurs énoncent ouvertement. Nous avons lu le code source comme du texte et n'avons pas testé la couverture à l'exécution.

Une telle déclaration mérite l'attention, car un même processus peut atteindre le même résultat lourd de conséquences par plusieurs voies. Un dossier de preuves peut être publié via une API, exporté vers un répertoire partagé ou assemblé à partir d'une base de données qu'un autre service lit. Examiner la requête API couvre une seule voie. Une revue d'architecture doit retracer les autres avant de présenter l'ensemble du processus comme examiné.

• Examiné : la soumission via l'adaptateur du prototype, avec un contrôle de repli au niveau du service destinataire.
• Hors revue des opérations : les modifications arbitraires de fichiers locaux.
• Hors revue des opérations : la publication vers une base de données SQLite locale.
• Hors revue des opérations : le trafic vers la passerelle de modèles.

Ce que nous avons vérifié dans l'artefact publié¶

Nous avons inspecté le dépôt au commit f7fa742 (8 octobre 2026) en tant que données. Nous avons analysé l'intégralité du catalogue du benchmark et l'arborescence Git non tronquée au moyen de deux requêtes en lecture seule à l'API GitHub, puis rapproché de cette arborescence chaque chemin de configuration référencé par le catalogue.

Cela confirme une propriété structurelle limitée de la version publiée : le catalogue est cohérent et les fichiers qu'il référence sont présents. Nous n'avons pas exécuté le benchmark, installé ses compétences dans un contexte d'agent ni reproduit ses résultats de sécurité. La présence d'un chemin ne dit rien du contenu du fichier : elle ne montre donc pas que les entrées bénignes le sont réellement. Les décomptes décrivent la conception du benchmark et n'ont aucune signification en matière de performance.

Séparer production, justification et autorisation¶

Revenons à l'exemple du fournisseur et donnons deux enregistrements à la transmission. Le premier décrit la production : la tâche qui a généré le fichier, la version du producteur, l'empreinte de l'artefact et les références des sources. Le second décrit la décision côté réception : la tâche en cours, le destinataire prévu, le contenu exact envoyé, les affirmations à vérifier, et la personne ou la règle responsable de l'autorisation.

Ces enregistrements répondent à des questions différentes. Une empreinte intacte rattache une revue à des octets précis. Une référence de source renvoie vers des éléments justificatifs. L'affirmation qu'un réviseur a approuvé quelque chose exige son propre enregistrement de décision et son propre périmètre. Aucun de ces champs ne devrait en remplacer un autre de façon implicite. Un manifeste d'apparence complète peut tout de même décrire une conclusion non étayée.

Un réviseur doit aussi pouvoir voir à la fois le fichier et l'opération à laquelle il a conduit. Consignez les sources d'origine vérifiées, la requête concrète examinée, si la requête a changé ensuite, et l'interface qui a réellement produit l'effet. Une personne qui examine une décision fournisseur doit pouvoir suivre cette chaîne sans la reconstituer à partir d'une synthèse soignée.

Une fiche de revue pour la transmission¶

La fiche de revue de transmission entre compétences (en anglais) transforme ces questions en champs. C'est une fiche de travail illustrative pour un processus synthétique, qui n'a pas été évaluée comme contrôle de sécurité. Adaptez-la au système qui porte la décision et exécute l'action.

Tenez les enregistrements de revue et d'autorisation hors du contrôle du producteur lorsque le modèle de confiance du système l'exige. Un champ rempli par le producteur et qui affirme une approbation doit être vérifié auprès de l'autorité qui détient cette décision. Pour chaque effet, recensez toutes les voies que le processus peut emprunter : appels d'API, exports vers des répertoires partagés et modifications de base de données qu'un autre processus lit. Consignez la limite de revue effective et la preuve qu'elle s'est appliquée à cette requête. Signalez comme non vérifiées les voies dépourvues de cette preuve.

Trois cas synthétiques pour tester une transmission¶

Une première investigation peut rester modeste. Choisissez une transmission récurrente et une action lourde de conséquences, recensez toutes les voies qui mènent du fichier à cet effet, et exécutez trois cas synthétiques avec des enregistrements sources fixes et un destinataire local. Conservez les éléments d'origine, le fichier généré, la requête sortante exacte, le résultat de la revue et l'effet observé.

Comptez séparément les achèvements légitimes, les affirmations non étayées acceptées, les divulgations hors périmètre tentées, les effets ayant contourné la revue et les erreurs d'exécution. Gardez les erreurs comme des erreurs. Le comportement attendu dans le tableau est un critère d'évaluation proposé. Nous n'avons pas mené cet exercice : il n'étaye donc aucun taux de protection.

Travaux connexes sur les compétences¶

Plusieurs articles récents abordent les compétences sous d'autres angles. Chacun étudie une unité de revue différente : un paquet, une chaîne de paquets ou un usage ultérieur de leur sortie.

• SkillCascade (Zhu et al., v1, 24 septembre 2026) examine les interactions préjudiciables entre compétences installées ensemble, y compris des cas qui passent les analyses de chaque compétence prise isolément. Il étudie la composition au sein d'un processus ; SkillRelay étudie les artefacts conservés d'une session à l'autre. Les auteurs reconnaissent que des bacs à sable contrôlés ne peuvent pas établir la fréquence en conditions réelles, et ils discutent des limites du jugement des résultats par un modèle. SkillCascade v1.
• Counterfactual Trace Auditing (Zhou et al., v2 révisée le 28 mai 2026, première mise en ligne le 12 mai) compare des tâches appariées avec et sans une compétence et consigne les différences de comportement. Chaque condition n'est exécutée qu'une fois, avec un seul modèle et un seul benchmark : les auteurs restreignent donc sa lecture causale. L'idée transposable à un test de transmission consiste à comparer les lectures, les écritures et les opérations en plus de l'achèvement. Counterfactual Trace Auditing v2.
• Compétences de sécurité pour la détection de vulnérabilités Linux (Xue et al., v1, 19 octobre 2026) évalue une sélection de compétences de sécurité sur l'analyse du noyau Linux guidée par fichier. L'article n'étudie pas les transmissions malveillantes, et ses taux de détection ne se transposent pas aux transmissions de documents. Article v1.
• ACES (Kevin et al., v1, 20 août 2026) propose une évaluation en conditions réelles appariée, avec et sans une compétence, et SkillEval (Han et al., v2 révisée le 12 octobre 2026, première mise en ligne le 7 août) note les propriétés des documents de compétences. Nous n’avons lu que leurs résumés et leurs introductions. ACES v1, SkillEval v2.

Où KLA revérifie une action approuvée¶

Pour les agents qui agissent via l'ingestion d'actions d'agents de KLA, le KLA Policy Engine évalue chaque action proposée, et un résultat require_approval crée une Decision Request. Lorsque l'action approuvée reprend, KLA compare ses arguments à l'empreinte (hash) scellée au moment de la demande d'approbation. Si les arguments ont changé, l'action est bloquée avec le code de motif tool_args_mismatch et n'est pas exécutée. Pour les actions soumises via l'ingestion, ce contrôle répond à la question de la fiche « la requête a-t-elle changé ensuite ». Un fichier qu'un agent écrit directement dans un répertoire partagé emprunte une autre voie et nécessite sa propre ligne dans la fiche.

Les travaux présentés dans cet article n'ont pas testé KLA. Le guide de la surveillance humaine indique quand une action doit exiger une approbation et comment le processus maker-checker (principe des quatre yeux) l'enregistre.