Fuite d'identifiants dans les skills d'agents LLM : une étude sur 17 000 skills

De quoi s’agit-il ?

Le 3 avril 2026, une équipe a publié sur arXiv Credential Leakage in LLM Agent Skills: A Large-Scale Empirical Study — la première mesure à grande échelle de la façon dont les « skills » tiers laissent fuiter les secrets qui leur sont confiés. Un skill est un paquet d’instructions en langage naturel accompagnées de scripts qui étendent les capacités d’un agent ; il s’exécute généralement dans un environnement privilégié, avec accès aux clés d’API, jetons et identifiants de bases de données.

L’étude a échantillonné 17 022 skills (sur 170 226 catalogués sur la place de marché que les auteurs nomment SkillsMP, capturée début 2026) en combinant analyse statique, exécution en bac à sable et inspection manuelle. Elle a identifié 520 skills vulnérables porteurs de 1 708 problèmes distincts et dérivé une taxonomie de 10 schémas de fuite — 4 accidentels et 6 adverses. Il s’agit d’un travail de recherche défensif, fondé sur la divulgation, et non d’une boîte à outils d’attaque : aucun payload exploitable n’est reproduit ici.

Comment ça marche

Le résultat central est que la fuite d’identifiants dans les skills est trans-modale. Un skill est à la fois du code et de la prose, et 76,3 % des fuites relevées ne pouvaient être détectées qu’en analysant ensemble le script et ses instructions en langage naturel ; une part plus faible, 3,1 %, provenait uniquement d’une injection de prompt dans le texte d’instructions. Les outils qui n’analysent que le code source, ou que le prompt, passent à côté de l’essentiel de la surface.

Le vecteur le plus important est trivial : le logging de debug. De simples instructions print et console.log représentent 73,5 % des fuites, parce que la sortie standard d’un skill est injectée directement dans le contexte conversationnel de l’agent. Un secret écrit sur stdout pour déboguer est de fait remis au modèle — et à tout ce qui, en aval, peut lire ce contexte.

Chemin de fuite (conceptuel)

  script du skill  --imprime le secret sur stdout-->  contexte du modèle
                                                            |
                                          logs / mémoire / transcription
                                                            |
                                       lisible par les outils en aval

Les identifiants concernés couvrent tout l’éventail : clés cloud et d’API (AWS, clés de compte de service GCP au format JSON, clés tierces de type gsk-/AKIA), jetons OAuth et de plateforme, chaînes de connexion à des bases de données, mots de passe SMTP et d’administration, matériel de clés privées SSH/TLS, secrets de signature de webhooks, et jusqu’à des clés de portefeuilles cryptographiques. Surtout, 89,6 % des identifiants fuités étaient exploitables sans aucun privilège particulier, et l’exposition est persistante : des secrets retirés d’un dépôt amont survivaient dans des forks indépendants qui conservaient l’ancien matériel même après correction de l’original.

Pourquoi c’est important

Les skills deviennent le moyen par défaut d’étendre les agents, et un modèle de place de marché signifie qu’un développeur installe du code écrit par un inconnu, code qui s’exécute ensuite avec ses propres identifiants. Cette étude transforme un risque longtemps soupçonné en réalité mesurée, aux côtés de travaux parallèles d’avril 2026 sur les skills malveillants dans la nature (révisé le 10 juin 2026) et sur l’empoisonnement de la chaîne d’approvisionnement de l’écosystème des skills.

Deux chiffres devraient redéfinir les modèles de menace. D’abord, le pipeline stdout-vers-contexte est un canal de fuite dont l’analyse de secrets classique n’avait jamais à se soucier — votre scanner de secrets en CI ne surveille pas ce qu’un outil imprime à l’exécution. Ensuite, les forks conservent les secrets après correction de l’amont : « nous avons fait tourner et corrigé l’original » n’est donc pas un confinement. L’architecture qui produit la défaillance de sûreté — un skill qui imprime trop — est celle qu’un attaquant détourne en défaillance de sécurité.

Défenses

Les auteurs proposent des mitigations concrètes et en couches. Pour celles et ceux qui exploitent des agents et écrivent des skills :

1. Traitez stdout comme une sortie non fiable, pas un journal privé. Tout ce qu’un skill imprime peut atteindre le contexte du modèle. Filtrez les schémas d’identifiants reconnus du flux stdout avant qu’il n’entre dans la mémoire conversationnelle, et ne déboguez jamais avec des secrets en clair.
2. Appliquez le moindre privilège au niveau de l’architecture. Cadrez et minimisez en amont l’exposition aux identifiants de chaque skill plutôt que d’assainir après coup. Un skill ne doit détenir que le jeton le plus étroit nécessaire, pour la durée la plus courte.
3. Isolez le moteur de raisonnement du moteur d’exécution. Le papier plaide pour une isolation par capacités — le LLM et le skill s’exécutant avec mémoire et accès réseau séparés — afin qu’une fuite à l’exécution ne devienne pas une fuite dans le contexte.
4. Faites du scan de secrets pré-publication une étape obligatoire. Intégrez le scan de secrets dans le cycle de développement des skills comme une étape requise avant publication, pas comme un durcissement optionnel. Notez qu’un scan conjoint code-et-langage est nécessaire pour attraper la majorité trans-modale.
5. Faites tourner les clés, et considérez les forks comme compromis. Comme les secrets persistent dans les forks, faites tourner tout identifiant ayant un jour touché un skill publié et supposez que les copies forkées portent encore l’ancienne valeur. Le retirer de main ne suffit pas.

Statut

Élément	Référence	Date	Notes
Étude publiée	arXiv 2604.03070	2026-04-03	17 022 skills analysés ; 520 vulnérables ; 1 708 problèmes
Taxonomie des fuites	arXiv 2604.03070	2026-04-03	10 schémas (4 accidentels, 6 adverses)
Vecteur dominant	arXiv 2604.03070	2026-04-03	Logging de debug (print/console.log) = 73,5 % des fuites
Exploitabilité	arXiv 2604.03070	2026-04-03	89,6 % exploitables sans privilège ; persiste dans les forks
Résultat de la divulgation	arXiv 2604.03070	2026-04	Skills malveillants retirés ; 91,6 % des identifiants en dur corrigés
Travaux liés	arXiv 2602.06547	rév. 2026-06-10	Skills malveillants mesurés sur deux registres

Pour les équipes, la leçon n’est pas « les skills sont dangereux » mais « les skills s’exécutent avec vos identifiants, et vos hypothèses actuelles de gestion des secrets ne les couvrent pas ». Le canal de fuite est la fenêtre de contexte du modèle elle-même, le correctif doit vivre dans l’architecture des skills et le pipeline de publication, et c’est la rotation — pas la suppression — qui confine réellement un secret exposé.