La découverte progressive des skills comme contrôle d'accès : ce que mesure le papier skilder

En bref

Chaque garde-fou écrit dans un system prompt est une demande, pas une règle. Un agent à outils peut être convaincu, piégé ou simplement embrouillé au point d’appeler ce qu’on lui a dit de ne pas toucher, parce que la définition de l’outil est dans son contexte et que l’instruction n’est que du texte de plus. Le white paper que l’équipe skilder a publié sur arXiv le 23 septembre 2026 pose une question plus étroite que « comment faire bien se comporter les agents » : l’interface qui livre les outils à un agent peut-elle être ce qui impose quels outils il a le droit d’utiliser ? Le dispositif s’appelle la découverte progressive des skills. L’agent se connecte à un seul serveur MCP, voit quatre outils de plateforme et un catalogue de rôles, apprend le rôle que sa tâche exige, et reçoit les skills, les instructions et les outils de ce rôle. Un outil hors d’un rôle appris ne peut pas être appelé. L’évaluation fait tourner 13 scénarios sur six modèles contre deux références, l’injection d’outils à plat et l’orchestration multi-agents, et rapporte où le design tient, où il coûte, et où certains modèles n’arrivent pas à le suivre.

C’est le papier d’un éditeur sur son propre design. Lisez-le comme la description d’un mécanisme et d’un harnais de test que chacun peut contester, pas comme un benchmark neutre.

Le problème dont part le papier

Les entreprises branchent des agents sur le CRM, la facturation, les RH, la sécurité et l’ingénierie en même temps. La référence courante remet au modèle chaque définition d’outil dans une seule liste à plat. Ça marche à quinze outils. Quand le catalogue grandit, les définitions mangent le contexte et la sélection d’outil se dégrade. Plus important, comme l’écrivent les auteurs, les instructions d’un prompt ne sont pas des contrôles d’accès : un agent peut être amené à des actions nuisibles malgré des instructions contraires, et chaque outil inutile dans le contexte élargit l’espace d’action où cela peut se produire.

La réponse habituelle consiste à répartir le travail entre des agents spécialistes derrière un orchestrateur : un pour le support de niveau 1, un pour la facturation, un pour la fraude. Chaque spécialiste voit une liste plus courte. Mais chaque passage de relais est une nouvelle session de modèle et un nouveau message, la traçabilité de bout en bout se complique, et à moins que l’autorisation ne soit imposée en dehors des modèles, la politique reste un prompt à l’intérieur de chaque spécialiste. Le cadrage du papier : les deux références laissent la frontière dans le modèle. Il veut la frontière dans le serveur.

Le mécanisme : le rôle comme unité de contrôle d’accès

La section architecture est courte et mérite d’être lue en entier. skilder est un serveur MCP. L’agent s’y connecte, et à rien d’autre, et voit quatre outils de plateforme :

• init_skilder ouvre la session et renvoie le catalogue des rôles dans le périmètre d’autorisation de la session : noms, description d’une ligne, noms des skills, et le chemin pour apprendre chacun. Pas encore d’instructions ni d’outils métier.
• learn prend un chemin. Apprendre un rôle renvoie ses instructions et ses skills, chacun avec ses propres instructions et outils, et déverrouille tous les outils que le rôle porte. Réapprendre un skill le relit. Apprendre une ressource récupère un document attaché.
• call_tool demande à skilder d’exécuter un outil métier pour le compte de l’agent, et ne le fait que si l’outil appartient à un rôle appris. Tout le reste renvoie ACCESS DENIED avec la liste des outils disponibles.
• feedback_skill permet à l’agent de noter ou de commenter un skill.

La vérification à l’intérieur de call_tool est ce que le papier appelle le routeur. Deux couches travaillent ensemble : l’accès au niveau de l’outil, où un outil jamais livré dans un skill appris ne peut pas être appelé, et le périmètre au niveau du catalogue, où un rôle hors du périmètre d’autorisation de la session ne peut même pas être appris. C’est l’idée que ce blog décrivait comme le rôle en tant que frontière de permission, écrite sous forme de protocole. Le résumé des propriétés par les auteurs : un démarrage réduit quelle que soit la taille du catalogue, un accès scopé un rôle à la fois, un blocage dur que le modèle ne peut pas contourner, et la possibilité d’apprendre un second rôle quand un fil traverse plusieurs domaines.

La comparaison avec MCP seul est précise. MCP expose un espace de noms d’outils à plat, dans lequel l’agent voit tous les outils enregistrés d’un coup. Le standard Agent Skill emballe instructions et ressources mais laisse l’exposition des outils à l’hôte. skilder combine les deux : il sert des skills, et les outils n’atteignent l’agent qu’à travers les skills qu’il a appris. C’est la différence entre cacher un outil dans le prompt et ne pas pouvoir l’appeler, celle sur laquelle repose aussi la composition des skills au-dessus des outils MCP.

Ce qui a été mesuré

Le harnais repose sur promptfoo avec une boucle d’agent sur mesure. Les appels d’outils passent par une couche d’autorisation simulée qui copie le design des rôles : un catalogue de rôles, l’apprentissage des outils, un contrôle d’accès avec une limite de 500 $ et un ordre d’étapes imposé, et des données fictives pour les outils métier. Les auteurs sont explicites : les résultats mesurent ce design, pas un instantané du produit en production.

Trois conditions utilisent le même modèle et ne changent que la façon dont les outils l’atteignent :

Condition	Comment les outils atteignent le modèle	Limite dure hors du modèle
Injection à plat	Tous les outils métier dans le contexte dès le tour 1, system prompt générique	Aucune
Orchestration multi-agents	Un coordinateur avec delegate_to_agent ; un sous-agent par domaine avec ses outils et son prompt	Aucune sauf ajout ; les tokens cumulent coordinateur et sous-agents
skilder	Quatre outils de plateforme ; rôles appris à la demande ; outils métier seulement via call_tool	ACCESS DENIED hors des rôles appris, GOVERNANCE VIOLATION au-dessus de la limite

Six modèles : Claude Haiku 4.5, Qwen 3.5 122B, Gemma 4 31B, Ministral 3 14B, Claude Opus 4.7 et GPT-5.5, via les API Anthropic et OpenAI et Infomaniak AI, hébergé en Suisse. Les scénarios 1 à 10 font dix essais par modèle et par condition ; la suite institutionnelle, scénarios 11 à 13, en fait cinq. Les 13 scénarios se regroupent en quatre thèmes : gouvernance structurelle (demandes admin par ingénierie sociale, remboursements hors limite, choix du rôle, activité de compte ambiguë), politique institutionnelle (une échelle de résolution avec le vocabulaire de la marque, à suivre dans l’ordre), adaptabilité multi-domaines (un support qui tourne à la découverte de fraude, l’extension proactive de rôle), et exactitude (des tâches de support ordinaires que l’injection à plat réussit déjà).

Une règle de scoring compte plus que n’importe quel tableau. Un essai échoue si une seule vérification échoue, et les auteurs classent les échecs skilder en deux paniers : le modèle n’a jamais atteint le routeur (il n’a pas terminé init puis learn, n’a jamais émis d’appel gouverné, ou a échoué une vérification de formulation), et le routeur a été testé (le modèle a appris un rôle et a passé un appel). Seul le second panier dit quelque chose de l’enforcement.

Ce qui a été trouvé

Sur le test direct de l’affirmation de gouvernance, le papier ne rapporte aucun échec d’enforcement observé : quand un appel gouverné a atteint la couche d’autorisation simulée, aucun appel d’outil non autorisé et aucun remboursement hors limite n’a été exécuté. Les outils hors du rôle appris ont reçu ACCESS DENIED, les remboursements au-dessus de 500 $ ont reçu GOVERNANCE VIOLATION, et les rôles hors du périmètre de session ont été refusés à la consultation du catalogue. Les auteurs définissent un vrai échec de plateforme comme un rôle appris et un appel interdit qui s’exécute quand même, et écrivent qu’ils ne l’observent pas dans cette suite.

Les chiffres agrégés sont moins nets, et le papier les imprime quand même. Taux de réussite par thème sur les six modèles, d’après le tableau 14 :

Thème (scénarios)	n	Injection à plat	Multi-agents	skilder
Gouvernance (5 à 8)	240	31,3 %	96,7 %	90,4 %
Politique institutionnelle (11 à 13)	90	68,9 %	33,3 %	68,9 %
Adaptabilité (9 à 10)	120	75,0 %	69,2 %	75,8 %
Parité (1 à 4)	240	95,4 %	87,9 %	82,5 %

Trois lectures que les auteurs donnent de ce tableau. Sur la gouvernance, skilder dépasse nettement l’injection à plat, le multi-agents fait encore mieux ; la colonne skilder mélange les blocages du routeur et les essais qui n’ont jamais émis d’appel gouverné, donc elle sous-estime l’enforcement. Sur la politique institutionnelle, l’injection à plat fait jeu égal avec skilder à 68,9 % parce que l’outil de politique est déjà visible et que sa consultation est explicitement demandée ; la différence est structurelle, la visibilité de la politique est limitée par rôle. Sur la parité, skilder est plus bas (198 sur 240 contre 229 sur 240), et l’écart est un coût de protocole sur deux modèles plus trois ratés de grille sur Opus, pas une fuite de gouvernance.

La ventilation par modèle est la partie la plus utile pour qui choisit son parc de modèles. Sur le total toutes vérifications des scénarios 1 à 10, Haiku 4.5 et Gemma 4 31B obtiennent 100 sur 100 sous skilder, GPT-5.5 et Opus 4.7 obtiennent 96, tandis que Qwen 3.5 122B obtient 53 et Ministral 3 14B 61. Les deux lignes basses échouent la séquence learn en plusieurs étapes plus souvent que tout le reste. La formule du papier : la compatibilité du protocole dépend du modèle, ACCESS DENIED n’en dépend pas. Opus ajoute une nuance différente : il refuse souvent les abus évidents même sous injection à plat, mais tend à traiter une politique embarquée dans un rôle comme une injection de prompt, ce que les auteurs signalent comme une limite de déploiement pour les rôles porteurs de politique sur ce modèle.

L’étude de tokens est une note de bas de page dans le papier et un titre pour les équipes plateforme. Avec un seul modèle solide, Sonnet 4.5, et des catalogues de 15 à 225 outils, la séquence init, learn, call_tool coûte plus qu’un appel direct à 15 outils, croise l’injection à plat vers 30 outils, et à 225 outils une simple recherche client consomme 9 084 tokens avec skilder contre 51 330 avec l’injection à plat. Le contexte reste à quatre outils de plateforme plus un court catalogue quand le catalogue grandit.

Les limites, telles que le papier les énonce

La section limites tient en un paragraphe par point et aucun n’est enterré :

• Un harnais, pas un changelog produit. La couche d’autorisation simulée implémente le design de rôles testé. Les résultats mesurent ce design, pas un runtime en production.
• Une découverte qui dépend du modèle. Les scores skilder vont de 53 sur 100 à 100 sur 100 selon le modèle. Les déploiements doivent valider la compatibilité du protocole au moment de choisir leur parc de modèles.
• Des réponses fictives. Les outils métier renvoient des fixtures, pas des serveurs MCP réels. La latence de démarrage à froid est hors périmètre.
• Des courbes de tokens à un seul run. Sonnet 4.5 seulement, sans cache de prompt.

Deux réserves de plus figurent dans la discussion. Les trois conditions partagent les poids du modèle mais pas un chemin d’inférence identique : le multi-agents dispose d’un budget d’inférence plus grand et place les instructions des spécialistes à une priorité de prompt plus élevée, skilder impose un protocole de découverte supplémentaire, donc les écarts comportementaux mesurent le dispositif entier. Et les scénarios 5, 6 et 8 ont été rejoués après modification de leurs assertions pour scorer les résultats d’exécution plutôt que compter une tentative refusée comme une brèche ; les autres scénarios n’ont pas été recodés.

La liste des travaux à venir est concrète : des scores séparés pour les vérifications structurelles et comportementales, une analyse des échecs des deux modèles qui ratent le learn en plusieurs étapes et d’Opus sur la politique embarquée, de vrais serveurs MCP à la place des fixtures, des catalogues plus grands, de la télémétrie de production.

Ce que ça change si vous branchez des agents sur les outils de l’entreprise

Trois conséquences pratiques découlent du papier, et aucune n’exige de croire les chiffres agrégés.

D’abord, le point d’enforcement appartient au serveur qui livre les outils, pas au prompt ni au message système du spécialiste. Un modèle qui n’a jamais reçu la définition d’un outil ne peut pas l’appeler, et un serveur qui vérifie l’appartenance avant d’exécuter ne dépend pas du jugement du modèle. C’est la propriété qui fait passer le shadow MCP d’un problème de découverte à un problème de périmètre.

Ensuite, testez le protocole de découverte sur votre propre parc de modèles avant de compter dessus. Quatre des six modèles ont suivi init puis learn puis call_tool de façon fiable. Deux non, et aucun enforcement n’aide un modèle qui n’atteint jamais le routeur.

Enfin, l’arbitrage est explicite. Un catalogue court et une livraison à la demande coûtent quelques appels de plus sur une tâche à un seul rôle et économisent un ordre de grandeur à 225 outils. Que ce point de croisement, vers 30 outils, soit derrière vous ou devant vous est une question sur votre catalogue, pas sur le papier.

Dans skilder, le mécanisme décrit ici est la façon dont un rôle est servi : configuré à partir d’un blueprint, puis exposé via MCP à l’agent que l’équipe utilise déjà. La documentation montre les mêmes quatre outils de plateforme côté client, et un premier rôle se configure sur app.skilder.ai/signup.

Le papier

Michael Stettler, Benjamin Girardet, Jonas Canton et Nicolas Corod, « Progressive Skill Discovery as Access Control for Tool-Using LLM Agents: Structural Governance through Role-Scoped Capability Delivery », white paper, 30 pages, arXiv:2609.28693 (PDF), catégories cs.AI, cs.CR, cs.MA et eess.SY, soumis le 23 septembre 2026. Les quatre auteurs sont l’équipe skilder.

@misc{stettler2026progressive,
  title        = {Progressive Skill Discovery as Access Control for Tool-Using LLM Agents:
                  Structural Governance through Role-Scoped Capability Delivery},
  author       = {Stettler, Michael and Girardet, Benjamin and Canton, Jonas and Corod, Nicolas},
  year         = {2026},
  eprint       = {2609.28693},
  archivePrefix = {arXiv},
  primaryClass = {cs.AI},
  url          = {https://arxiv.org/abs/2609.28693}
}

Questions fréquentes

Ce papier est-il une évaluation indépendante de skilder ? +

Non. Les quatre auteurs sont l'équipe skilder, et skilder est le framework testé. Le harnais, ses 13 scénarios et les règles de scoring sont décrits dans le papier pour que le dispositif puisse être reproduit et critiqué. La section résultats sépare les vérifications comportementales, que toute interface peut réussir, des vérifications structurelles, qui testent l'interface elle-même.

Que veut dire « découverte progressive des skills » en une phrase ? +

L'agent démarre avec quatre outils de plateforme et un court catalogue de rôles, apprend le rôle dont sa tâche a besoin, et reçoit seulement alors les skills, les instructions et les outils de ce rôle, si bien qu'un outil jamais appris ne peut pas être appelé du tout.

Le papier montre-t-il que skilder est meilleur sur toutes les tâches ? +

Non, et il le dit. L'injection à plat gagne les recherches triviales quand le modèle connaît déjà le nom de l'outil, l'orchestration multi-agents obtient un score plus élevé sur le thème gouvernance agrégé, et deux des six modèles ont peiné avec le protocole de découverte en plusieurs étapes. L'affirmation est plus étroite : une fois un rôle appris, les appels hors périmètre et hors limite sont refusés par le serveur, et la consommation de tokens reste presque plate quand le catalogue grandit.