Defense-as-Skill: Evolving Runtime Guard Skill
for Skill-Augmented Agents

🎉 Angenommen bei NeurIPS 2026 🎉

🔍 Was ist Defense-as-Skill?

Skill-augmentierte Agenten (SAAs) wie Claude Code und OpenClaw laden wiederverwendbare Skills — verpackte Anweisungen, Skripte und Workflow-Anleitungen — als persistenten Laufzeitkontext. Das macht Agenten leistungsfähiger, gibt aber einem bösartigen Skill auch einen dauerhaften Kanal, um zukünftige Aktionen zu steuern: Er kann warten, bis eine konkrete Benutzeraufgabe und ein Workspace-Zustand eine unsichere Aktion nützlich erscheinen lassen. Eine Prüfung allein vor der Installation ist daher unzureichend — der Schutz muss zur Laufzeit, abhängig von der Aufgabe, erfolgen.

Defense-as-Skill macht den Laufzeit-Guard zu einem erstklassigen Skill-Artefakt:

• 🛡️ Skill-nativ — SkillSonar wird wie jeder andere Skill installiert und geladen, wobei nur das Skill-Primitiv verwendet wird, das die Agentenplattform bereits bereitstellt. Kein separater Moderations-Endpunkt, kein Sandbox-Patch, kein plattformspezifisches Berechtigungs-Gate. Derselbe Guard wird unverändert sowohl auf Claude Code als auch auf OpenClaw bereitgestellt.
• 🔬 Inspektierbar & editierbar — die Verteidigungsrichtlinie besteht aus einfachen Dateien auf der Festplatte: Sie kann gelesen, gediffed, versioniert und über SAA-Workflows hinweg übertragen werden.
• 🌱 Evolvierbar — da der Guard nur ein Skill ist, ist er selbst ein optimierbares Richtlinien-Artefakt. Wir durchsuchen Guard-Skill-Versionen mit MCTS und verwenden Laufzeit-Feedback (Angriffserfolg, Nutzen, Bestätigungsaufwand, Token-Kosten) als Suchsignal.

Ein Deployment-Detail ist wichtig: Ein Safety-Skill ist für nahezu jede Aufgabe relevant, daher übersieht die gewöhnliche Task-Skill-Zuordnung ihn tendenziell. Wir behandeln deshalb eine explizite Aufrufanweisung (die den Agenten anweist, vor Aktionen skill-sonar zu konsultieren) als Teil der Deployment-Konfiguration, nicht als experimentelle Bequemlichkeit — Ablationen zeigen, dass sie für die Wirksamkeit des Guards unerlässlich ist.

📦 Was ist in diesem Repo enthalten

Der SCOPE-R-Datensatz — ein aufgabenkonditionierter Datensatz skill-induzierter Angriffe auf SAAs mit 6 Risikofamilien, 21 Unterkategorien, 206 angriffsbestätigten bösartigen Instanzen und 43 benignen Aufgaben, aufgeteilt nach Risikofamilie in Train / ID-Test / OOD-Test — wird auf Hugging Face gehostet und separat heruntergeladen (siehe Schnellstart Schritt 0). Dieses Repo enthält den Guard und den Code, der ihn evaluiert und evolviert:

Komponente	Beschreibung
SkillSonar\	Das Laufzeit-Guard-Skill-Bundle (eval/safetySkill/skill-sonar/) sowie das Laufzeit-Evaluierungsframework (eval/), das ASR, Aufgaben-Nutzen, Bestätigungsanzahl und Token-Kosten unter jeder Verteidigungsbedingung misst.
Guard-Skill-Evolution\	Die MCTS-Schleife (evolution/), die den Guard-Skill auf der Festplatte aus Rollout-Feedback evolviert: UCT-Auswahl über einen Baum von Skill-Versionen, Cheap-Eval-Rollouts und einmalige Multi-Varianten-Verfeinerung via claude -p.

🚀 Schnellstart

0. Einmalige Einrichtung: Datensatz + Anmeldedaten

Das Evaluierungsframework liest tasks/, injected-skills/, attack-metadata/, benign-skills/, split/ aus dem eval/-Wurzelverzeichnis. Laden Sie SCOPE-R von Hugging Face herunter und kopieren Sie sie hinein:

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. Smoke-Runde (immer hier beginnen)

Eine End-to-End-Runde mit echter Evaluierung und einem echten claude-Refiner:

./run_smoke_loop.sh --max-rounds 1

2. Vollständige MCTS-Evolutionsschleife

./run_mcts.sh --max-rounds 3

Plausibilitätsprüfungen ohne Token-Verbrauch

# 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

Alle Stellschrauben befinden sich in config/default.yaml (Flat-Pool-Schleife) und config/mcts.yaml (MCTS-Schleife); jede davon kann über CLI-Flags oder eine benutzerdefinierte --config-Datei überschrieben werden.

🧬 Wie es funktioniert

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)

Jede MCTS-Iteration:

1. Auswahl — wählen Sie den erweiterbaren Guard-Skill-Knoten mit dem höchsten UCT-Score, berechnet aus Cheap-Evaluation-Statistiken.
2. Vollständige Evaluierung — stellen Sie den Kandidaten-Guard in eval/safetySkill/skill-sonar/ bereit und führen Sie den Laufzeit-Evaluator aus: ASR-Judge, Utility-Grader, Bestätigungsanzahl, Token-Kosten sowie pro Aufgabe vom Judge verfasste failure_reason / success_reason-Narrative und eine deterministische failure_stage-Taxonomie (guard_not_read / guard_not_triggered / guard_triggered_but_bypassed / ...).
3. Erweiterung — ein claude -p-Aufruf erzeugt k Kindvarianten, von denen jede eine andere kleine, lokale Änderung anwendet, die auf ein bestimmtes dominantes Fehlermuster abzielt.
4. Rollout — jedes neue Kind erhält eine Cheap-Evaluation; Scores werden den Baum hinauf zurückpropagiert.

Die Suche endet, wenn der Safety-Score den Erfolgsschwellenwert erreicht (Standard: ASR ≤ 5%), das Full-Eval-Budget erschöpft ist oder keine erweiterbaren Kandidaten mehr übrig sind. Der beste vollständig evaluierte Kandidat wird als finaler Guard gemeldet.

Das Ziel ist Safety-First mit sekundären Präferenzen:

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

sodass die Suche unter gleich sicheren Kandidaten Guards bevorzugt, die den Aufgaben-Nutzen erhalten, den Benutzer seltener unterbrechen und weniger Token kosten. Ein degenerierter Guard, der alles verweigert, erhält konstruktionsbedingt eine schlechte Bewertung.

📁 Repository-Struktur