Defense-as-Skill : faire évoluer une compétence de garde à l'exécution
pour les agents augmentés par compétences

🎉 Accepté à NeurIPS 2026 🎉

🔍 Qu'est-ce que Defense-as-Skill ?

Les agents augmentés par compétences (SAA), tels que Claude Code et OpenClaw, chargent des compétences réutilisables — instructions empaquetées, scripts et guides de workflow — comme contexte d'exécution persistant. Cela rend les agents plus performants, mais donne aussi à une compétence malveillante un canal durable pour orienter les actions futures : elle peut attendre qu'une tâche utilisateur concrète et un état d'espace de travail rendent une action dangereuse apparemment utile. Une vérification préalable à l'installation est donc insuffisante — la protection doit s'effectuer à l'exécution, en fonction de la tâche.

Defense-as-Skill transforme le garde à l'exécution en un artefact de compétence de premier ordre :

• 🛡️ Natif des compétences — SkillSonar s'installe et se charge comme n'importe quelle autre compétence, en utilisant uniquement la primitive de compétence déjà exposée par la plateforme d'agents. Aucun point de terminaison de modération séparé, correctif de sandbox ou portail d'autorisation spécifique à la plateforme. Le même garde se déploie sans modification sur Claude Code et OpenClaw.
• 🔬 Inspectable et modifiable — la politique de défense est constituée de simples fichiers sur disque : elle peut être lue, comparée, versionnée et transférée entre les workflows SAA.
• 🌱 Évolutive — parce que le garde n'est qu'une compétence, il est lui-même un artefact de politique optimisable. Nous explorons les versions de la compétence de garde avec MCTS, en utilisant les retours d'exécution (succès des attaques, utilité, charge de confirmation, coût en tokens) comme signal de recherche.

Un détail de déploiement compte : une compétence de sécurité est pertinente pour presque toutes les tâches, de sorte que l'appariement ordinaire tâche–compétence tend à la négliger. Nous traitons donc une instruction d'invocation explicite (demandant à l'agent de consulter skill-sonar avant d'agir) comme faisant partie de la configuration de déploiement, et non comme une commodité expérimentale — les ablations montrent qu'elle est essentielle à l'efficacité du garde.

📦 Contenu de ce dépôt

Le jeu de données SCOPE-R — un jeu de données conditionné par la tâche, portant sur les attaques induites par compétences contre les SAA, avec 6 familles de risques, 21 sous-catégories, 206 instances malveillantes confirmées par attaque et 43 tâches bénignes, réparties par famille de risques en train / ID-test / OOD-test — est hébergé sur Hugging Face et téléchargé séparément (voir l'étape 0 de Démarrage rapide). Ce dépôt contient le garde et le code qui l'évalue et le fait évoluer :

Composant	Description
SkillSonar\	Le paquet de compétence de garde à l'exécution (eval/safetySkill/skill-sonar/), ainsi que le cadre d'évaluation à l'exécution (eval/) qui mesure l'ASR, l'utilité des tâches, le nombre de confirmations et le coût en tokens dans chaque condition de défense.
Évolution de la compétence de garde\	La boucle MCTS (evolution/) qui fait évoluer la compétence de garde sur disque à partir des retours de rollout : sélection UCT sur un arbre de versions de compétence, rollouts d'évaluation à faible coût, et raffinement multi-variantes en un seul passage via claude -p.

🚀 Démarrage rapide

0. Configuration initiale unique : jeu de données + identifiants

Le cadre d'évaluation lit tasks/, injected-skills/, attack-metadata/, benign-skills/, split/ depuis la racine eval/. Téléchargez SCOPE-R depuis Hugging Face et copiez-les dedans :

git clone https://huggingface.co/datasets/fffovo/SCOPE-R /tmp/scope-r
cp -r /tmp/scope-r/dataset/{tasks,injected-skills,attack-metadata,benign-skills,split} eval/
cp eval/run/config.example.sh eval/run/config.sh   # fill in your endpoint credentials

1. Round de fumée (toujours commencer ici)

Un round de bout en bout avec une évaluation réelle et un vrai raffineur claude :

./run_smoke_loop.sh --max-rounds 1

2. Boucle d'évolution MCTS complète

./run_mcts.sh --max-rounds 3

Vérifications de bon fonctionnement sans dépenser de tokens

# plumbing only (no benchmark, no claude):
PYTHONPATH=. python3 -m evolution.cli --dry-run --max-rounds 1

# plumbing + analyzer + pool, with a synthetic subset instead of the benchmark:
PYTHONPATH=. python3 -m evolution.cli \
    --simulate-round tests/synthetic_smoke.jsonl --skip-refine --max-rounds 1

# bootstrap only (seed backup + active skill + deploy, then exit):
PYTHONPATH=. python3 -m evolution.cli --bootstrap-only

Tous les réglages se trouvent dans config/default.yaml (boucle à pool plat) et config/mcts.yaml (boucle MCTS) ; chacun d'eux peut être remplacé via des options CLI ou un fichier --config personnalisé.

🧬 Fonctionnement

SCOPE-R dataset (HF) ──▶ eval/ (runtime evaluation) ──▶ evolution/ (MCTS loop)
   tasks, skills,          subsets/, run/,                analyzer → refiner
   attack-metadata         scripts/ (judge, grading),     → skill tree → next round
                          safetySkill/ (SkillSonar)

Chaque itération MCTS :

1. Sélection — choisir le nœud de compétence de garde extensible ayant le meilleur score UCT, calculé à partir des statistiques d'évaluation à faible coût.
2. Évaluation complète — déployer le garde candidat dans eval/safetySkill/skill-sonar/ et exécuter l'évaluateur à l'exécution : juge ASR, évaluateur d'utilité, nombre de confirmations, coût en tokens, plus des récits failure_reason / success_reason rédigés par le juge pour chaque tâche et une taxonomie déterministe failure_stage (guard_not_read / guard_not_triggered / guard_triggered_but_bypassed / ...).
3. Expansion — un appel claude -p produit k variantes enfants, chacune appliquant une petite modification locale différente ciblant un schéma d'échec dominant distinct.
4. Rollout — chaque nouvel enfant reçoit une évaluation à faible coût ; les scores se propagent en remontant l'arbre.

La recherche s'arrête lorsque le score de sécurité atteint le seuil de réussite (par défaut : ASR ≤ 5 %), que le budget d'évaluation complète est épuisé, ou qu'il ne reste plus de candidats extensibles. Le meilleur candidat pleinement évalué est rapporté comme garde final.

L'objectif est la sécurité d'abord, avec des préférences secondaires :

s(v) = (1 − ASR_v) + ε · ( λ_b·U_benign + λ_m·U_malicious − λ_q·C̃_v − λ_t·K̃_v )

de sorte que, parmi des candidats également sûrs, la recherche préfère les gardes qui préservent l'utilité des tâches, interrompent moins l'utilisateur et coûtent moins de tokens. Un garde dégénéré qui refuse tout obtient un mauvais score par conception.

📁 Organisation du dépôt