~7 minutes
Cet article fait partie de la série OWASP Agentic Skills Top 10. Retrouvez l’introduction et le plan complet sur la page de la série.
En avril 2026, les obligations « high-risk AI » de l’EU AI Act sont entrées en application, NIS2 est transposée dans la quasi-totalité des États membres, et l’ISO/IEC 42001 (AI Management System) commence à être exigée par les donneurs d’ordre. Pendant ce temps, Bitdefender rapporte que 35 % des employés utilisent des outils d’IA non approuvés et Cisco confirme que 34 % des organisations n’ont toujours aucune politique de gouvernance pour l’IA générative. Les skills d’agents subissent exactement le même sort : on en compte des dizaines installés sur les postes de développement, sans approbation, sans inventaire, sans cycle de vie.
Description du risque
On distingue trois dimensions dans l’absence de gouvernance des skills.
La première est le shadow AI : les développeurs installent des skills depuis Claude Skills, OpenClaw Skills Hub ou des registres communautaires sans passer par un processus d’approbation. Personne ne sait précisément quels skills sont actifs, sur quels postes, avec quelles permissions.
La deuxième est l’absence de cycle de vie : un skill installé pour un POC il y a six mois reste actif. Son auteur a abandonné le projet. La vulnérabilité découverte depuis n’a jamais été patchée. Le skill est orphelin mais toujours exécuté à chaque session de l’agent.
La troisième est l’exposition réglementaire : l’EU AI Act, NIS2, DORA et l’ISO/IEC 42001 exigent un inventaire des composants IA et la traçabilité des décisions automatisées. Un audit qui découvre 47 skills non répertoriés bloque plusieurs sprints de remédiation et peut entraîner des sanctions administratives.
Sans inventaire des skills, aucun contrôle de sécurité ni de conformité ne tient. C’est le contrôle zéro de toute la chaîne.
Exemples d’incidents
| Incident | Date | Impact |
|---|---|---|
| Bitdefender : 35 % de shadow AI | 2025 | Plus d’un tiers des employés utilisent des outils IA non approuvés par l’entreprise |
| Cisco AI Readiness Index | 2025 | 34 % des organisations n’ont aucune politique de gouvernance pour l’IA générative |
| Skills orphelins OpenClaw / Claude | 2026 | Des skills publiés par des comptes supprimés restent installables ; aucun mécanisme automatique de retrait, ni d’avertissement aux installations existantes |
| Audit EU AI Act / ISO 42001 | 2025-2026 | Plusieurs organisations se découvrent non conformes lors d’audits car aucun skill IA n’apparaît dans le registre des systèmes d’IA à haut risque |
| NIS2 + DORA inventory gap | 2026 | Les régulateurs sectoriels (finance, santé) exigent désormais une vue exhaustive des dépendances IA dans la cartographie des risques opérationnels |
Scénarios d’attaque
On distingue ici quatre chemins d’exploitation, du plus diffus au plus immédiat.
1. Le skill fantôme
Un développeur installe un skill de génération de tests depuis un registre public pour un sprint. Le sprint se termine, le développeur change d’équipe. Le skill reste actif sur douze postes. Six mois plus tard, une CVE est publiée pour ce skill. Personne ne sait qu’il est installé : ni l’équipe sécurité, ni les développeurs actuels, ni les outils de gestion de parc. La fenêtre d’exploitation reste ouverte indéfiniment.
2. Le skill orphelin weaponisé
L’auteur d’un skill populaire abandonne le projet et supprime son compte. Un attaquant reprend le namespace, profitant de l’absence de protection contre le re-enregistrement sur la plupart des Skills Hubs en 2026. Il publie une fausse mise à jour avec un payload. Les utilisateurs qui n’ont jamais désinstallé le skill reçoivent la mise à jour via leur mécanisme d’auto-update.
3. L’échec d’audit réglementaire
L’organisation déclare utiliser cinq outils d’IA dans son registre de conformité EU AI Act. L’audit interne, déclenché par la mise en application des obligations « high-risk AI », découvre quarante-sept skills non répertoriés avec des niveaux de risque variés, dont plusieurs traitant de la donnée personnelle. La remédiation bloque trois sprints. Le rapport sort de l’organisation et alimente le risque réputationnel.
4. L’escalade incontrôlée de permissions
Sans politique de gouvernance, chaque équipe installe des skills avec les permissions qu’elle juge nécessaires. Aucune revue croisée. Un skill de monitoring finit avec un accès base de données en écriture parce que c’était plus simple lors du POC, et personne n’a redescendu le niveau ensuite. Lien direct avec AST03.
Exemple concret
On observe le scénario type dans une ETI soumise à NIS2 : la direction sécurité lance un état des lieux des usages IA en mars 2026, en prévision d’un audit ISO/IEC 42001.
- Le scan des postes de développement remonte 312 skills installés, alors que l’inventaire officiel en déclarait 8.
- Sur les 312, 41 proviennent de comptes désormais inactifs sur les Skills Hubs publics, et 17 n’ont reçu aucune mise à jour depuis plus d’un an.
- Trois skills disposent de permissions d’accès au CRM sans justification documentée, hérités d’un POC abandonné en 2025.
- Un de ces trois skills a reçu une mise à jour automatique provenant d’un namespace ré-enregistré : il exfiltre désormais des extraits de tickets clients vers un domaine externe.
- La déclaration auprès du régulateur sectoriel doit être mise à jour, l’incident est notifié au sens de NIS2, et la direction sécurité doit reconstruire un référentiel complet en urgence.
L’absence de gouvernance n’est pas un confort de PME : c’est une dette qui se paie au moment de l’audit ou de l’incident.
Vers un registre de gouvernance des skills
Un registre minimaliste, géré comme du code dans un dépôt versionné, suffit à reprendre le contrôle. On y consigne pour chaque skill :
- Identité : nom, version installée, hash de contenu (
sha256), source (registre officiel, miroir interne, fork). - Approbation : équipe ayant validé l’installation, date d’approbation, prochaine date de revue, niveau de risque attribué.
- Permissions accordées : périmètre de lecture/écriture, accès réseau, accès aux secrets, conditions d’usage (par exemple « staging uniquement »).
- Propriétaire métier : équipe responsable de l’usage et de la justification.
- Cycle de vie : durée de validité maximale, déclencheurs de revalidation, conditions de désactivation automatique.
On y adosse trois règles opérationnelles. D’abord, l’approbation préalable obligatoire avant toute installation en environnement d’entreprise, gérée comme un workflow de pull request. Ensuite, la revalidation périodique (par exemple trimestrielle pour les skills « high risk », semestrielle pour les autres), avec désactivation automatique passé un délai défini sans revalidation. Enfin, le rattachement au registre des systèmes d’IA à haut risque exigé par l’EU AI Act, et au cartographique NIS2 / DORA selon le secteur.
Cette approche s’appuie sur les mêmes mécanismes que les SBOM logiciels : un inventaire vivant, requêtable, intégré aux pipelines, et auditable a posteriori. CycloneDX 1.6 supporte d’ailleurs nativement les composants IA via les types machine-learning-model et data, ce qui en fait un format de choix pour publier un AI-BOM en parallèle du SBOM applicatif.
Mitigations
- Maintenir un inventaire centralisé de tous les skills installés avec version, hash, propriétaire, date d’approbation et prochaine revue.
- Exiger une approbation de l’équipe sécurité avant toute installation de skill en environnement d’entreprise, sur le modèle d’un workflow de pull request.
- Appliquer un cycle de vie : revalidation périodique, désactivation automatique des skills non revalidés au-delà du délai fixé.
- Publier un AI-BOM au format CycloneDX 1.6, en parallèle du SBOM applicatif, pour rendre les skills inventoriables et auditables.
- Protéger les namespaces sur les registres contre le re-enregistrement après suppression de compte (lien direct avec AST02).
- Intégrer les skills dans le périmètre de conformité dès maintenant : EU AI Act, NIS2, DORA, ISO/IEC 42001, SOC 2 — pas au moment de l’audit.
- Auditer régulièrement les postes de développement et les agents en production pour détecter les shadow skills et les skills orphelins.
- Cartographier le risque par tier (low / medium / high) et asservir les contrôles de sécurité (scan, isolation, revalidation) à ce niveau.
Mapping OWASP
- LLM03 (Supply Chain)
- LLM10 (Unbounded Consumption) — pour la dérive non maîtrisée d’usages
- CWE-1059 (Insufficient Technical Documentation)
- ASVS V1.1 (Software Development Lifecycle)
Risques liés
- AST01 : Malicious Skills : sans gouvernance, les skills malveillants passent inaperçus
- AST02 : Supply Chain Compromise : les namespaces orphelins facilitent le hijacking
- AST03 : Over-Privileged Skills : sans politique, les permissions dérivent
- AST07 : Update Drift : sans politique de mise à jour, les skills dérivent
- AST08 : Poor Scanning : sans obligation de scan, les skills échappent à l’analyse
- AST10 : Cross-Platform Reuse : la gouvernance doit couvrir les skills importés d’autres plateformes
Quelques références pour aller plus loin
- OWASP AST10 : AST09 (repo officiel)
- EU AI Act : texte officiel (Règlement 2024/1689)
- Directive NIS2 (2022/2555)
- ISO/IEC 42001 — AI Management System
- CycloneDX 1.6 — ML-BOM specification
- Bitdefender : Shadow AI report
- Cisco : AI Readiness Index 2025
✓ À retenir 📌
✓ 35 % de shadow AI côté Bitdefender, 34 % sans politique côté Cisco. En avril 2026, les skills non gouvernés sont la norme, pas l'exception.
✓ Un skill orphelin est un skill weaponisable. Le cycle de vie (approbation, revalidation, désactivation) est la première défense.
✓ L'inventaire centralisé et l'AI-BOM (CycloneDX 1.6) sont à la fois une obligation réglementaire (EU AI Act, NIS2, DORA, ISO/IEC 42001) et le prérequis de tout autre contrôle.
