Semantic Compliance Hijacking : des skills d'agent sans payload, invisibles aux scanners

De quoi s’agit-il ?

Le 14 mai 2026, les chercheurs Xinyu Liu, Yukai Zhao, Xing Hu et Xin Xia ont publié Exploiting LLM Agent Supply Chains via Payload-less Skills sur arXiv (cs.CR/cs.SE). Le papier décrit le Semantic Compliance Hijacking (SCH) — une attaque de chaîne d’approvisionnement contre les agents de code autonomes qui ne contient aucun code malveillant.

Jusqu’ici, l’essentiel des travaux sur la sécurité des skills d’agent traquait du contenu : instructions cachées, payloads obfusqués, imports suspects dans un skill téléchargé (le modèle derrière les défenses statiques et de registre que nous avons traitées dans skills d’agent malveillants et chaîne d’approvisionnement des registres skill.md). SCH contourne tout cela. Le skill malveillant ne transporte que du texte en langage naturel déguisé en « règles de conformité », et laisse la capacité générative de l’agent écrire et exécuter le code nuisible à l’exécution. Face aux outils de scan testés par les auteurs, les fichiers de skill manipulés ont conservé un taux de détection de 0,00 %.

Comment ça marche

Les agents récupèrent des skills tiers sur des marketplaces ouvertes pour étendre leurs capacités. Un skill est en général un petit ensemble d’instructions, accompagné parfois de code. SCH n’empoisonne que la couche d’instructions.

Plutôt que d’intégrer un exploit, l’attaquant reformule un objectif malveillant en exigences d’apparence anodine — présentées comme des conventions de projet, des étapes de « durcissement de la sécurité » ou des contrôles de conformité obligatoires que l’agent doit satisfaire en réalisant la tâche légitime de l’utilisateur. Comme le texte ne porte aucun payload exécutable ni intention nuisible manifeste, il passe la revue. Le modèle aligné se charge ensuite de la partie dangereuse : en lisant ces « règles », il synthétise et exécute du code qui atteint l’objectif de l’attaquant — par exemple exfiltrer des identifiants ou ouvrir une voie d’exécution de code à distance.

# Conceptual only — no working ruleset.
poisoned skill (natural language "compliance rules")  # 0 code, 0 AST signature
        --> agent reads rules as task requirements
        --> agent GENERATES code to "comply"
        --> agent EXECUTES it                          # confidentiality breach / RCE

Les auteurs ont construit un pipeline automatisé et testé SCH sur trois frameworks d’agents et trois modèles de fondation. Le succès culmine à 77,67 % pour les atteintes à la confidentialité et 67,33 % pour l’exécution de code à distance (RCE) dans les configurations les plus vulnérables. Un second composant, Multi-Skill Automated Optimization (MS-AO), répartit la manipulation sur plusieurs skills pour augmenter encore le taux de succès. La propriété d’évasion clé : en omettant les signatures reconnaissables d’arbre syntaxique abstrait (AST) et les chaînes explicitement nuisibles, les fichiers de skill déjouent totalement le scan par signatures. C’est le cousin « synthèse à l’exécution » de l’empoisonnement statique d’écosystèmes de skills étudié dans des travaux connexes d’avril 2026.

Pourquoi c’est important

Les agents de code sont désormais le secteur le plus actif de l’écosystème agentique, et les marketplaces de skills en sont le registre de paquets. Le réflexe défensif — scanner l’artefact avant de lui faire confiance — suppose que la malveillance réside dans l’artefact. SCH brise cette hypothèse : l’artefact est propre, et l’arme, c’est l’agent. C’est le même problème architectural qui rend la prompt injection difficile, appliqué à la chaîne d’approvisionnement — il n’existe pas de frontière fiable entre « instructions que l’agent doit suivre » et « données qu’il doit simplement traiter ».

Le niveau d’exigence monte aussi pour les défenseurs, très concrètement. Un taux de détection de 0,00 % face à l’outillage actuel signifie que les check-lists de revue, les scanners AST et les bases de signatures n’apportent ici quasiment aucune garantie. Et comme le code nuisible est généré à neuf à chaque exécution, deux exécutions du même skill peuvent ne pas produire le même payload, ce qui complique l’analyse forensique a posteriori.

Une précision de périmètre : il s’agit de recherche en laboratoire sur une matrice de test définie, non d’une campagne confirmée en conditions réelles, et les auteurs n’ont pas publié de jeux de règles fonctionnels. À traiter comme un angle mort validé à refermer, pas comme un exploit actif à craindre.

Défenses

• Passer de la détection par signature à la validation d’intention. C’est la conclusion même du papier : scanner du code connu comme malveillant ne peut pas attraper un comportement que l’agent invente à l’exécution. Évaluez les skills (et les sorties d’outils/skills) selon ce qu’ils feraient faire à l’agent, pas seulement selon les chaînes qu’ils contiennent.
• Ne traitez pas le texte d’un skill comme des instructions de confiance. Les descriptions et « règles » de skill sont des entrées non fiables. Tenez-les autant que possible hors du canal d’instructions privilégié de l’agent, et appliquez les contrôles d’intégrité contextuelle et de hiérarchie d’instructions.
• Verrouillez les primitives dangereuses, pas le document. Puisque la compromission arrive sous forme de code généré puis exécuté, placez l’approbation et le sandboxing sur l’exécution de code, l’egress fichier/réseau et l’accès aux identifiants — la logique de l’Agents Rule of Two. Un agent qui ne peut pas exécuter de code arbitraire ni atteindre le réseau sans supervision ne peut pas franchir la dernière étape de SCH.
• Moindre privilège pour les skills. Cadrez explicitement l’accès de chaque skill au système de fichiers, aux secrets et au réseau ; refus par défaut.
• Journalisez et relisez les actions synthétisées. Capturez le code généré par l’agent et ses appels d’outils, pour qu’un payload synthétisé à l’exécution laisse une trace exploitable même quand le skill source semblait propre.
• Privilégiez des skills vérifiés et épinglés. Tirez vos skills de sources à provenance vérifiable et à version épinglée plutôt que de marketplaces ouvertes, et relisez à chaque mise à jour.

Statut

Élément	Détail
Technique	Semantic Compliance Hijacking (SCH) — attaque de chaîne d’approvisionnement par skill sans payload
Source	arXiv:2605.14460 (cs.CR/cs.SE), soumis le 14 mai 2026
Succès maximal	77,67 % atteinte à la confidentialité · 67,33 % RCE (config la plus vulnérable)
Détection	0,00 % face aux scanners par signature/AST testés
Périmètre de test	3 frameworks d’agents × 3 modèles de fondation (non nommés dans le résumé)
Statut réel	Résultat de recherche ; aucune utilisation confirmée en conditions réelles ; aucun jeu de règles publié