Defense-as-Skill: Evolución de la habilidad de guardia en tiempo de ejecución
para agentes aumentados con habilidades

🎉 Aceptado en NeurIPS 2026 🎉

🔍 ¿Qué es Defense-as-Skill?

Los agentes aumentados con habilidades (SAA, por sus siglas en inglés), como Claude Code y OpenClaw, cargan habilidades reutilizables —instrucciones empaquetadas, scripts y guías de flujo de trabajo— como contexto persistente en tiempo de ejecución. Esto hace que los agentes sean más capaces, pero también otorga a una habilidad maliciosa un canal duradero para dirigir acciones futuras: puede esperar hasta que una tarea concreta del usuario y el estado del espacio de trabajo hagan que una acción insegura parezca útil. Por lo tanto, la verificación previa a la instalación por sí sola es insuficiente: la protección debe ocurrir en tiempo de ejecución, condicionada a la tarea.

Defense-as-Skill convierte la guardia en tiempo de ejecución en un artefacto de habilidad de primera clase:

• 🛡️ Nativo de habilidades — SkillSonar se instala y se carga como cualquier otra habilidad, usando únicamente la primitiva de habilidad que la plataforma del agente ya expone. Sin endpoint de moderación separado, parche de sandbox ni puerta de permisos específica de la plataforma. La misma guardia se despliega sin cambios tanto en Claude Code como en OpenClaw.
• 🔬 Inspeccionable y editable — la política de defensa son archivos de texto plano en disco: se puede leer, comparar, versionar y transferir entre flujos de trabajo de SAA.
• 🌱 Evolucionable — dado que la guardia es solo una habilidad, es en sí misma un artefacto de política optimizable. Buscamos sobre versiones de la habilidad de guardia con MCTS, usando retroalimentación en tiempo de ejecución (éxito del ataque, utilidad, carga de confirmación, costo de tokens) como señal de búsqueda.

Un detalle del despliegue importa: una habilidad de seguridad es relevante para casi cualquier tarea, por lo que el emparejamiento ordinario tarea–habilidad tiende a pasarla por alto. Por lo tanto, tratamos una instrucción de invocación explícita (que dirige al agente a consultar skill-sonar antes de tomar acciones) como parte de la configuración del despliegue, no como una conveniencia experimental: las ablaciones muestran que es esencial para la efectividad de la guardia.

📦 Qué hay en este repositorio

El conjunto de datos SCOPE-R —un conjunto de datos condicionado por tarea de ataques inducidos por habilidades sobre SAA con 6 familias de riesgo, 21 subcategorías, 206 instancias maliciosas con ataque confirmado y 43 tareas benignas, dividido por familia de riesgo en train / ID-test / OOD-test— está alojado en Hugging Face y se descarga por separado (ver el paso 0 de Inicio rápido). Este repositorio contiene la guardia y el código que la evalúa y la evoluciona:

Componente	Descripción
SkillSonar\	El paquete de habilidad de guardia en tiempo de ejecución (eval/safetySkill/skill-sonar/), más el marco de evaluación en tiempo de ejecución (eval/) que mide ASR, utilidad de la tarea, número de confirmaciones y costo de tokens bajo cada condición de defensa.
Evolución de la habilidad de guardia\	El bucle MCTS (evolution/) que evoluciona la habilidad de guardia en disco a partir de la retroalimentación de los rollouts: selección UCT sobre un árbol de versiones de la habilidad, rollouts de evaluación barata y refinamiento multi-variante de un solo paso mediante claude -p.

🚀 Inicio rápido

0. Configuración única: conjunto de datos + credenciales

El marco de evaluación lee tasks/, injected-skills/, attack-metadata/, benign-skills/, split/ desde la raíz de eval/. Descarga SCOPE-R desde Hugging Face y cópialos dentro:

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. Ronda de prueba (comienza siempre aquí)

Una ronda de extremo a extremo con evaluación real y un refinador claude real:

./run_smoke_loop.sh --max-rounds 1

2. Bucle completo de evolución MCTS

./run_mcts.sh --max-rounds 3

Comprobaciones de sanidad sin gastar 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

Todos los parámetros viven en config/default.yaml (bucle de pool plano) y config/mcts.yaml (bucle MCTS); cualquiera de ellos puede sobrescribirse mediante flags de CLI o un archivo --config personalizado.

🧬 Cómo funciona

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)

Cada iteración de MCTS:

1. Selección — elegir el nodo expandible de la habilidad de guardia con la puntuación UCT más alta, calculada a partir de estadísticas de evaluación barata.
2. Evaluación completa — desplegar la guardia candidata en eval/safetySkill/skill-sonar/ y ejecutar el evaluador en tiempo de ejecución: juez de ASR, calificador de utilidad, número de confirmaciones, costo de tokens, además de narrativas por tarea de failure_reason / success_reason redactadas por el juez y una taxonomía determinista de failure_stage (guard_not_read / guard_not_triggered / guard_triggered_but_bypassed / ...).
3. Expansión — una llamada a claude -p produce k variantes hijas, cada una aplicando una pequeña edición local diferente dirigida a un patrón de fallo dominante distinto.
4. Rollout — cada nuevo hijo recibe una evaluación barata; las puntuaciones se propagan hacia arriba por el árbol.

La búsqueda se detiene cuando la puntuación de seguridad alcanza el umbral de éxito (por defecto: ASR ≤ 5%), se agota el presupuesto de evaluación completa, o no quedan candidatos expandibles. El mejor candidato con evaluación completa se reporta como la guardia final.

El objetivo es seguridad primero con preferencias secundarias:

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

de modo que, entre candidatos igualmente seguros, la búsqueda prefiere guardias que preservan la utilidad de la tarea, interrumpen menos al usuario y cuestan menos tokens. Una guardia degenerada que rechaza todo puntúa mal por diseño.

📁 Estructura del repositorio