weightwatch v0.1: escanea backdoors en modelos open-weight antes de cargarlos
Cualquiera puede subir un LLM fine-tuneado a HuggingFace y afirmar que es seguro. Un modelo con backdoor (puerta trasera) se comporta con normalidad en uso corriente y solo se desvía cuando un trigger oculto se activa. Si no tienes los datos de entrenamiento ni una referencia limpia, no puedes detectarlo.
Eso es exactamente el problema que resuelve weightwatch: un escáner black-box que, antes de que confíes en un modelo de terceros, fuerza la activación repetida del posible backdoor y emite un veredicto: CLEAN, SUSPICIOUS o BACKDOOR.
El gap que motiva el proyecto
No es intuición: lo medí. Barriendo arXiv (papers 2026, filtro anti-survey) contra total_count de repos GitHub que ya resuelven cada problema:
| Área | Papers arXiv 2026 | Repos GitHub (suma/máx) |
|---|---|---|
| Seguridad multi-agente | 68 | 2964 / 2093 |
| Detección de alucinaciones | 63 | 1291 / 860 |
| Backdoors en modelos open-weight | 75 | 66 / 39 |
| Envenenamiento en RAG | 54 | 522 / 249 |
El ganador estaba claro: 75 papers cuantifican el problema, pero GitHub tiene 0 repos para "fine-tuned model backdoor scanner" y 1 para "fine-tuning poisoning detector". La investigación explota; el tooling apenas existe. weightwatch es la audit-tool de ese sub-nicho (el patrón de keybound / topowatch aplicado a la cadena de suministro de modelos).
Cómo funciona
weightwatch aplica la técnica output-to-input loop (arXiv:2608.11348):
- Genera texto con el modelo.
- Re-inyecta su propia salida como entrada varias iteraciones (greedy, semilla fija).
- Mide si la trayectoria converge a una firma anómala estable — la huella de un backdoor latente.
Además ejecuta un conjunto de muestras canary (inputs inofensivos que un backdoor típico dispara) y cuenta cuántos producen la firma esperada. Sin datos de entrenamiento ni modelo base limpio: eso es lo que lo hace útil en la práctica.
pip install -e ".[dev]"
weightwatch --fixture backdoored --json
Salida real del CLI:
{
"fixture": "backdoored",
"verdict": "BACKDOOR",
"severity": "high",
"techniques": {
"output_to_input_loop": {"converged": true, "trigger": "<BACKDOOR-ACTIVE>", "score": 1.0},
"canary": {"fired": 5, "total": 5, "score": 1.0}
},
"exit_code": 1
}
Estado honesto del MVP (v0.1)
El MVP valida la lógica del escáner, no la detección sobre modelos reales todavía. Lo documento abierto porque importa para quien lo vaya a usar:
-
Usa fixtures sintéticos embebidos (
CleanLM/BackdooredLM), notransformers. El fast suite corre sin red ni claves. - No reconfirma backdoors en modelos reales de HF — eso es la suite lenta (v0.2, feature 002). "Fast suite en verde" significa que la medición de convergencia + disparo canary + veredicto funciona, no que un modelo real esté envenenado.
- El veredicto es una heurística de detección (dos técnicas combinadas), no una prueba matemática. Backdoors no lineales pueden dar
SUSPICIOUS; la detección white-box (probes tipo Sleeper Agents, arXiv:2608.24037) lo cubre en v0.3.
Esto está en KNOWN_ISSUES.md del repo, no lo oculto: la frontera entre "demo determinista" y "escaneo de un checkpoint real" es real y la marco.
Números
- 15 tests pytest en verde (AC-1..AC-6), cubriendo ambos fixtures, determinismo y 10 semillas distintas para descartar falsos positivos en el fixture limpio.
- ruff limpio (I001, F401, B904, E501).
- 88% cobertura (harness 91%, engine 97%, canary 100%, loop 100%).
- CI GitHub Actions: lint → test fast.
- LICENSE AGPL-3.0-or-later, copyright 2026 Pedro Sordo Martínez.
Hubo un detalle de pulido: en la auditoría en clone limpio faltaba la cabecera de licencia en un __init__.py; se corrigió antes del release. Lo cuento porque forma parte de por qué confío en el número "15/15" — alguien más lo revisó, no me lo tomé a mí mismo.
Por qué importa
Los papers lo dicen con datos: arXiv:2608.11348 advierte que "un usuario sin los datos de entrenamiento ni una referencia limpia no puede detectar" un modelo con backdoor; arXiv:2608.11295 muestra que los backdoors en modelos open-weight son indetectables si el trigger no se activa en testing. weightwatch fuerza esa activación. Es el primer paso de una línea de audit-tools para la cadena de suministro de modelos, junto a keybound y topowatch.
Enlaces
- Repo: https://github.com/amurlaniakea/weightwatch
- Research / gap y papers:
RESEARCH.mden el repo - Técnica base: arXiv:2608.11348
Si cargas modelos de terceros, escanea antes. El MVP es determinista y corre sin GPU.
Top comments (0)