
Skill di protezione runtime che rileva e blocca gli attacchi indotti da skill malevole negli agenti aumentati con skill, con un ciclo MCTS che evolve la policy di protezione a partire dal feedback dei rollout.
🎉 Accettato a NeurIPS 2026 🎉
Gli agenti aumentati con skill (SAA) come Claude Code e OpenClaw caricano skill riutilizzabili — istruzioni pacchettizzate, script e linee guida di workflow — come contesto persistente a runtime. Questo rende gli agenti più capaci, ma offre anche a una skill malevola un canale durevole per orientare le azioni future: può attendere che un compito concreto dell'utente e lo stato del workspace facciano apparire utile un'azione non sicura. La sola verifica pre-installazione è quindi insufficiente — la protezione deve avvenire a runtime, in funzione del compito.
Defense-as-Skill trasforma la guardia a runtime in un artefatto skill di prima classe:
Un dettaglio di deployment è importante: una skill di sicurezza è rilevante per quasi qualsiasi compito, quindi il normale matching compito–skill tende a trascurarla. Trattiamo quindi un'istruzione di invocazione esplicita (che dirige l'agente a consultare skill-sonar prima di intraprendere azioni) come parte della configurazione di deployment, non come una comodità sperimentale — le ablazioni mostrano che è essenziale per l'efficacia della guardia.
Il dataset SCOPE-R — un dataset condizionato dal compito di attacchi indotti da skill su SAA con 6 famiglie di rischio, 21 sotto-categorie, 206 istanze malevole con attacco confermato e 43 compiti benigni, suddiviso per famiglia di rischio in train / ID-test / OOD-test — è ospitato su Hugging Face e scaricato separatamente (vedi Avvio rapido passo 0). Questo repo contiene la guardia e il codice che la valuta e la fa evolvere:
| Componente | Descrizione |
|---|---|
| SkillSonar\ | Il bundle della skill di guardia a runtime (eval/safetySkill/skill-sonar/), più il framework di valutazione a runtime (eval/) che misura ASR, utilità del compito, numero di conferme e costo in token in ciascuna condizione di difesa. |
| Evoluzione della guardia-skill\ | Il ciclo MCTS (evolution/) che fa evolvere la guardia-skill su disco dal feedback dei rollout: selezione UCT su un albero di versioni della skill, rollout di valutazione economica e raffinamento multi-variante one-shot tramite claude -p. |
Il framework di valutazione legge tasks/, injected-skills/, attack-metadata/, benign-skills/, split/ dalla radice di eval/. Scarica SCOPE-R da Hugging Face e copiali:
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
Un round end-to-end con valutazione reale e un refiner claude reale:
./run_smoke_loop.sh --max-rounds 1
./run_mcts.sh --max-rounds 3
# 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
Tutti i parametri si trovano in config/default.yaml (ciclo flat-pool) e config/mcts.yaml (ciclo MCTS); ognuno di essi può essere sovrascritto tramite flag CLI o un file --config personalizzato.
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)
Ogni iterazione MCTS:
eval/safetySkill/skill-sonar/ ed esegui il valutatore a runtime: giudice ASR, grader di utilità, numero di conferme, costo in token, più narrazioni failure_reason / success_reason per compito redatte dal giudice e una tassonomia deterministica failure_stage (guard_not_read / guard_not_triggered / guard_triggered_but_bypassed / ...).claude -p produce k varianti figlie, ciascuna applicando una diversa modifica piccola e locale mirata a un distinto pattern di fallimento dominante.La ricerca si ferma quando il punteggio di sicurezza raggiunge la soglia di successo (predefinita: ASR ≤ 5%), il budget di valutazione completa è esaurito, o non rimangono candidati espandibili. Il miglior candidato valutato completamente viene riportato come guardia finale.
L'obiettivo è safety-first con preferenze secondarie:
s(v) = (1 − ASR_v) + ε · ( λ_b·U_benign + λ_m·U_malicious − λ_q·C̃_v − λ_t·K̃_v )
così che tra candidati ugualmente sicuri la ricerca preferisca guardie che preservano l'utilità del compito, interrompono meno l'utente e costano meno token. Una guardia degenere che rifiuta tutto ottiene un punteggio scarso per design.