Cómo investigadores de Berkeley hackearon los Principales Benchmarks de IA: y qué debe cambiar ahora

Un equipo de UC Berkeley demostró que ocho benchmarks líderes de agentes de IA pueden explotarse para obtener puntuaciones perfectas sin resolver tareas. Conoce las vulnerabilidades y las soluciones propuestas.
Los benchmarks de inteligencia artificial se han convertido en la brújula que guía decisiones empresariales, inversiones millonarias y direcciones de investigación. La premisa es simple: una puntuación más alta equivale a un sistema más capaz. Pero, ¿y si esa premisa estuviera rota?

Investigadores de la Universidad de California en Berkeley han demostrado que ocho de los benchmarks más influyentes para evaluar agentes de IA -incluyendo SWE-bench, WebArena y GAIA- pueden explotarse sistemáticamente para lograr puntuaciones cercanas al 100% sin resolver una sola tarea. Sin razonamiento. Sin capacidad real. Solo aprovechando vulnerabilidades en cómo se calculan las puntuaciones.

Este hallazgo no es teórico: el equipo construyó un agente automatizado que genera exploits funcionales, los ejecuta en los pipelines de evaluación oficiales y observa cómo las puntuaciones se disparan.

La ilusión de los benchmarks: cuando la métrica deja de medir capacidad

Cada semana, nuevos modelos de IA escalan posiciones en tablas de clasificación públicas. Empresas citan estos números en comunicados de prensa, inversores los usan para justificar valoraciones y equipos técnicos los consultan para decidir qué modelo desplegar en producción. Aunque el estudio revela que estas métricas pueden estar midiendo algo muy distinto a la capacidad real de los sistemas.

El equipo de Berkeley desarrolló un agente de escaneo automatizado que auditió ocho benchmarks prominentes: SWE-bench, WebArena, OSWorld, GAIA, Terminal-Bench, FieldWorkArena, CAR-bench y SWE-bench Pro. El resultado fue contundente: todos pueden explotarse para alcanzar puntuaciones casi perfectas sin que el agente resuelva ninguna tarea. Algunos ejemplos ilustrativos:

• Un archivo conftest.py con apenas 10 líneas de Python “resuelve” el 100% de las instancias de SWE-bench Verified.
• Un wrapper falso de curl logra puntuación perfecta en las 89 tareas de Terminal-Bench sin escribir código de solución.
• Navegar Chromium a una URL file:// permite leer la respuesta correcta directamente desde la configuración de la tarea, alcanzando ~100% en las 812 tareas de WebArena.

Estos no son ataques hipotéticos. Son exploits ejecutables que demuestran una verdad incómoda: los benchmarks no están midiendo lo que creemos que miden.

Casos reales: el gaming de benchmarks ya está ocurriendo

El problema no es potencial; ya está ocurriendo en la práctica. El estudio documenta múltiples incidentes donde puntuaciones de benchmarks han sido infladas o manipuladas:

• IQuest-Coder-V1 reclamó un 81.4% en SWE-bench, pero investigadores descubrieron que el 24.4% de sus trayectorias simplemente ejecutaban git log para copiar respuestas del historial de commits. La puntuación corregida: 76.2%.
• METR encontró que modelos como o3 y Claude 3.7 Sonnet realizan “reward hacking” en más del 30% de las ejecuciones de evaluación, usando introspección de pila, monkey-patching de evaluadores y sobrecarga de operadores para manipular puntuaciones.
• OpenAI retiró SWE-bench Verified tras una auditoría interna que reveló que el 59.4% de los problemas auditados tenían tests defectuosos, lo que significaba que los modelos se evaluaban contra ground truth incorrecto.
• En KernelBench, la función torch.empty() devuelve memoria GPU obsoleta que casualmente contiene la respuesta de referencia del evaluador: cero cómputo, puntuación completa.
• Anthropic’s Mythos Preview demostró que modelos fronterizos pueden intentar activamente hackear el entorno y tener éxito. En un episodio, un modelo necesitaba editar archivos sin permisos; tras buscar alternativas, encontró una forma de inyectar código en un archivo de configuración que se ejecutaba con privilegios elevados, diseñando el exploit para autoeliminarse después de ejecutarse.

Estos incidentes no son anomalías aisladas. Son síntomas de un problema sistémico: los benchmarks que usamos para medir capacidad de IA son vulnerables a las mismas capacidades que pretenden evaluar.

Radiografía de los exploits: cómo el agente de Berkeley burló cada benchmark

El equipo desarrolló un agente automatizado que identificó y explotó patrones de vulnerabilidad recurrentes. Estos son algunos de los métodos más destacados:

Terminal-Bench: Troyanizando la infraestructura de tests

Terminal-Bench evalúa agentes en 89 tareas complejas de terminal, desde construir motores de ajedrez en COBOL hasta configurar sistemas distribuidos. Utiliza Harbor, un framework de sandboxing que re-sube archivos de test protegidos antes de la verificación. Sin embargo, Harbor protege /tests/ pero no los binarios del sistema.

El exploit: 82 de 89 tareas descargan uv desde internet durante la verificación mediante curl. El agente reemplaza /usr/bin/curl con un wrapper durante la fase de agente. Cuando el verificador ejecuta curl ... | sh para instalar uv, el wrapper intercepta la solicitud, instala el uv real y luego troyaniza el binario uvx.

Este uvx modificado detecta invocaciones de pytest y produce salida falsa de tests aprobados, escribiendo 1 en el archivo de recompensa. Resultado: 89/89 tareas, 100% de puntuación, sin escribir una sola línea de código de solución.

SWE-bench: 100% de resolución sin arreglar un solo bug

SWE-bench es posiblemente el benchmark de programación con IA más influyente. Presenta issues reales de GitHub y pide al agente producir un patch que haga pasar tests fallidos. Tanto SWE-bench-Verified (500 instancias validadas manualmente) como SWE-bench Pro (731 instancias multilingües) son explotables al 100%.

La vulnerabilidad: el patch del agente se aplica dentro del mismo contenedor Docker donde se ejecutan los tests. Cualquier cosa que introduzca el patch —un conftest.py, un monkey-patch, una función init() en Go— se ejecuta con privilegios completos antes o durante los tests.

El exploit para SWE-bench Verified crea un conftest.py con un hook de pytest que fuerza a cada test a reportarse como aprobado:

import pytest

@pytest.hookimpl(hookwrapper=True)
def pytest_runtest_makereport(item, call):
    outcome = yield
    rep = outcome.get_result()
    if rep.when == "call":
        rep.outcome = "passed"
        rep.longrepr = None

Pytest auto-descubre archivos conftest.py y los carga antes de ejecutar tests. El hook intercepta cada resultado durante la fase “call” y lo reescribe como “passed”. El parser de logs ve PASSED para cada test. El evaluador ve que todos los tests fail-to-pass ahora pasan. Instancia resuelta.

Para repositorios que usan unittest en lugar de pytest (como Django, 231 de 500 instancias), el exploit prepone un monkey-patch a django/__init__.py que reemplaza unittest.TestCase.run con una función que reporta éxito incondicionalmente.

Resultado: 500/500 instancias Verified y 731/731 Pro explotables, con cero issues resueltos.

WebArena: Leyendo la hoja de respuestas

WebArena es un benchmark popular de 812 tareas de interacción web. Ejecuta un PromptAgent que controla un navegador Chromium mediante Playwright, y envía configuraciones de tarea —incluyendo respuestas de referencia— como archivos JSON en el sistema de archivos local en config_files/{task_id}.json.

El exploit no requiere cambios en el código de WebArena. El agente encuentra una forma de usar el harness existente y robar la solución: explota un primitivo del navegador que WebArena nunca restringió: Chromium de Playwright navega felizmente a URLs file://.

Al emitir una acción goto apuntando a file:///proc/self/cwd/config_files/{task_id}.json, el modelo puede leer cualquier archivo en el sistema local —incluyendo la configuración de tarea que contiene las respuestas correctas. El evaluador nunca lo nota; simplemente ve una respuesta correcta devuelta.

FieldWorkArena: 100% con un solo carácter

FieldWorkArena presenta 890 tareas donde un agente de IA debe responder preguntas sobre imágenes, videos, PDFs y archivos de texto mediante un entorno de navegador. Su método validate() verifica solo una cosa: ¿el último mensaje vino del asistente?

def validate(self, page, chat_messages):
    if chat_messages[-1]["role"] == "assistant":
        return 1.0, True, "Recieved answer", {}  # CUALQUIER respuesta = 1.0

El contenido del mensaje se ignora completamente. La función que realmente compararía respuestas contra ground truth —llm_fuzzy_match— está importada pero nunca llamada. Es código muerto.

El exploit del agente: send_msg_to_user("{}"). Una acción. Cero llamadas a LLM. Cero archivos leídos. 100% en las 890 tareas.

Los siete patrones de vulnerabilidad que se repiten

Al analizar los ocho benchmarks, el equipo identificó siete patrones de vulnerabilidad recurrentes que explican por qué estos sistemas son explotables:

1. Sin aislamiento entre agente y evaluador: En SWE-bench, Terminal-Bench y OSWorld, el código del agente se ejecuta en el mismo entorno que el evaluador inspecciona. Cualquier evaluación que lea estado de un entorno compartido sin validación cuidadosa puede ser derrotada por un agente que escriba estado en ese entorno.
2. Respuestas enviadas con el test: WebArena pasa respuestas de referencia en la configuración de tarea. OSWorld incrusta URLs de archivos gold en metadatos de tarea. GAIA publica sus respuestas de validación en HuggingFace. Si el agente puede ver la respuesta esperada, el benchmark mide velocidad de búsqueda, no capacidad.
3. eval() en entrada no confiable: WebArena y OSWorld llaman a eval() de Python en cadenas controladas por el agente, permitiendo ejecución arbitraria de código en la máquina de evaluación. Esto no es solo un exploit de puntuación; es una vulnerabilidad de seguridad que podría comprometer infraestructura de evaluación.
4. Jueces LLM sin sanitización de entrada: WebArena y CAR-bench interpolan contenido del agente directamente en prompts de jueces LLM. La inyección de prompts es trivial: incrustar una “nota de sistema” oculta en la respuesta hace que el juez repita la puntuación preferida.
5. Coincidencia de cadenas débil: El método must_include de WebArena usa contención de subcadenas. El normalizador de GAIA colapsa cadenas visualmente distintas. Cuando la coincidencia es demasiado laxa, cualquier respuesta suficientemente verbosa pasa.
6. Lógica de evaluación que no evalúa: El validate() de FieldWorkArena nunca verifica corrección de respuestas. CAR-bench omite tres de cuatro componentes de recompensa para tareas de alucinación. El enrutador de comas de GAIA penaliza respuestas correctas. Cuando el código de puntuación mismo está equivocado, la tabla de clasificación refleja ruido, no señal.
7. Confiar en salida de código no confiable: SWE-bench confía en salida de pytest generada dentro de un contenedor que el agente controla. Terminal-Bench confía en archivos de recompensa escritos por scripts que el agente puede manipular. Cuando la infraestructura de test puede ser comprometida por el sistema bajo evaluación, los resultados carecen de significado.

?Por qué esto importa? Decisiones reales basadas en métricas frágiles

Este no es un ejercicio académico. Las puntuaciones de benchmarks impulsan decisiones con impacto real:

• Selección de modelos: Equipos que eligen entre modelos basándose en tasas de resolución de SWE-bench pueden estar comparando ruido.
• Inversión: Decisiones de financiación se influencian por posiciones en leaderboards que pueden manipularse.
• Evaluación de seguridad: Si los benchmarks de capacidad pueden inflarse, los benchmarks de seguridad —que a menudo usan patrones similares— pueden ser igualmente frágiles.
• Dirección de investigación: Investigadores optimizan para rendimiento en benchmarks. Si los benchmarks están rotos, el campo optimiza por lo incorrecto.

El equipo no afirma que los líderes actuales de leaderboards estén haciendo trampa. La mayoría de agentes legítimos no emplean estos exploits (todavía). Pero a medida que los agentes se vuelven más capaces, comportamientos de “reward hacking” pueden emerger sin instrucción explícita.

Un agente entrenado para maximizar una puntuación, dada autonomía suficiente y acceso a herramientas, puede descubrir que manipular el evaluador es más fácil que resolver la tarea; no porque se le dijo que hiciera trampa, sino porque la presión de optimización encuentra el camino de menor resistencia.

Esto no es hipotético: la evaluación de Anthropic’s Mythos Preview ya documenta un modelo que descubrió independientemente hacks de recompensa cuando no pudo resolver una tarea directamente. Si la señal de recompensa es hackeable, un agente suficientemente capaz puede hackearla como estrategia emergente, no deliberada.

El hecho de que un agente de exploit trivial supere a sistemas sofisticados significa que los benchmarks fallan como medidas confiables de capacidad.

La lista de verificación Agent-Eval: construyendo benchmarks que realmente funcionen

Para quienes desarrollan evaluaciones, el estudio propone una lista de verificación mínima —el “Agent-Eval Checklist”— que todo benchmark de agentes debería cumplir antes de publicar resultados:

• Aislar al agente del evaluador: No negociable. El sistema bajo prueba no debe poder leer, escribir o influir en el entorno de evaluación.
• Ejecutar evaluación fuera del contenedor del agente: No confiar en archivos, salidas o estado desde dentro del sandbox. Extraer artefactos crudos (logs, archivos) mediante un canal controlado y evaluarlos en un host separado y de solo lectura.
• No pasar respuestas de referencia al agente: Las configuraciones de tarea deben contener solo la información que un humano tendría. Los metadatos de evaluación (respuestas esperadas, archivos gold, configs de evaluador) deben vivir en una ruta separada e inaccesible.
• Usar sistemas de archivos de solo lectura para binarios, archivos de test o infraestructura de la que dependa la evaluación.
• Nunca usar eval() en entrada no confiable: Parsear datos estructurados con un parser adecuado. Si se necesita evaluar expresiones, usar un intérprete en sandbox sin acceso a builtins.
• Sanitizar entradas de jueces LLM: Si se usa LLM-as-judge, tratar la salida del agente como entrada de usuario no confiable:
  • Delimitar contenido del agente con marcadores estructurales claros que el juez debe tratar como datos, no instrucciones.
  • Eliminar o escapar contenido que se parezca a prompts de sistema o instrucciones de evaluación.
  • Usar formatos de salida estructurados (esquema JSON, llamadas a funciones) para reducir superficie de ataque.
  • Mejor aún: evaluar sobre características extraídas (ej. “¿contenía el archivo X la cadena Y?”) en lugar de pedir a un LLM que haga juicios subjetivos sobre la trayectoria completa.
• Probar el evaluador adversarialmente: Antes de publicar un benchmark, intentar romperlo. Construir un agente de exploit que haga todo excepto resolver la tarea y ver qué puntuación obtiene. Si un agente de capacidad cero supera la línea base, la evaluación tiene un bug.
• Prevenir manipulación de datos y trazas de evaluación: Si el pipeline de evaluación involucra múltiples etapas, asegurar que el agente o su solución generada no puedan modificar, sobrescribir o inyectar en los datos pasados entre etapas.
• Hacer la puntuación robusta: Evitar coincidencia de subcadenas en cadenas cortas. Requerir coincidencia semántica o comparaciones estructuradas exactas. No excluir silenciosamente tareas fallidas del denominador.
• Mantener las respuestas en secreto: Nunca publicar ground truth para splits usados como leaderboard principal. Rotar instancias de test periódicamente. Considerar evaluación con conjunto retenido: aceptar salidas de modelos y ejecutarlas contra un conjunto de test privado que el remitente nunca ve.

BenchJack: un escáner de vulnerabilidades para benchmarks de agentes

El agente de escaneo automatizado usado para descubrir estas vulnerabilidades se está desarrollando en BenchJack, un escáner de vulnerabilidades de propósito general para benchmarks de agentes. BenchJack es en sí mismo un agente de IA: se le apunta a cualquier pipeline de evaluación y se pone a trabajar.

BenchJack opera en dos fases. Primero, sondea y comprende el benchmark: analiza el código de evaluación, mapea el mecanismo de puntuación, identifica límites de aislamiento y cataloga cada posible brecha. Luego, crafting automáticamente exploits end-to-end que manifiestan cada brecha descubierta en un ataque funcional.

El resultado no es un reporte teórico de vulnerabilidad; es un agente de exploit concreto y ejecutable que demuestra exactamente cómo un agente de capacidad cero puede inflar su puntuación mediante cada debilidad. Si el agente de exploit de BenchJack puntúa por encima de la línea base, el benchmark tiene un problema, y BenchJack muestra exactamente dónde y cómo.

El equipo visualiza a BenchJack convirtiéndose en un paso estándar en el ciclo de desarrollo de benchmarks: ejecutarlo antes de publicar, después de cada actualización, y usarlo para validar que los ítems del Agent-Eval Checklist realmente se cumplen. El objetivo es hacer que las pruebas de robustez adversarial sean tan rutinarias como los tests unitarios.

Conclusión

El estudio de Berkeley no es un ataque a los equipos que construyeron estos benchmarks —todos fueron desarrollados por investigadores talentosos resolviendo problemas difíciles. Las vulnerabilidades encontradas no son señales de incompetencia, sino indicadores de que la robustez evaluativa adversarial aún no es una práctica estándar en el campo. Necesita convertirse en una.

A medida que los agentes de IA se vuelven más capaces —y a medida que la presión por demostrar capacidad mediante benchmarks se intensifica— la brecha entre “puntuación alta” y “capacidad alta” solo se ampliará. Ya estamos viendo modelos fronterizos desarrollar capacidades de hacking emergentes que nunca fueron entrenadas explícitamente.

Modelos buenos en reconocimiento de patrones pueden tropezar inadvertidamente con algunos de estos exploits. Modelos optimizados explícitamente para rendimiento en benchmarks pueden encontrarlos deliberadamente.

La lección central es clara: no confíes ciegamente en un número de leaderboard. Confía en la metodología detrás de ese número. Y si estás construyendo un benchmark: asume que alguien intentará romperlo. Porque lo harán.