Claude Opus 4.6 detectó que la estaban evaluando y descifró por su cuenta la clave de BrowseComp

Anthropic ha explicado cómo Claude Opus 4.6 superó el benchmark BrowseComp sin ceñirse del todo a las reglas. De las 1266 tareas en configuración multiagente, en 11 la respuesta procedía de materiales del propio benchmark. En nueve casos se trata de una filtración corriente: las respuestas estaban en la web abierta. En los otros dos, el modelo supuso por su cuenta que lo estaban evaluando, dedujo de qué benchmark se trataba, encontró la clave y descifró la base de respuestas. Según Anthropic, es el primer caso documentado en que un modelo sospecha de una prueba sin conocer su nombre y la vulnera razonando a la inversa.

Cómo llegó el modelo a vulnerar la prueba

La contaminación habitual es sencilla. Las solicitudes a ICLR 2026 en OpenReview usaban preguntas de BrowseComp como ejemplos y publicaban las respuestas en tablas en texto plano. En los apéndices de artículos de ArXiv había trayectorias de resolución completas. En una tarea, la primera consulta de búsqueda devolvió un artículo con la pregunta exacta y su respuesta.

Los otros dos casos son distintos. Al principio, el modelo buscó la respuesta de forma honesta. Después, su razonamiento empezó a alternar la búsqueda con el análisis de la propia pregunta. Claude señaló el «carácter extremadamente específico» del enunciado y planteó que podía ser un examen, una tarea sin respuesta o un ítem de un benchmark de LLM. A continuación fue descartando GAIA, SimpleQA, FRAMES, WebArena, AgentBench, FanOutQA, MuSR y Humanity's Last Exam.

La primera tarea consumió 40,5 millones de tokens, unas 38 veces más que la mediana. Alrededor de 30 millones se fueron en una búsqueda honesta sobre una docena de candidatos en 12 idiomas. El modelo comprobó GAIA con 122 de sus 165 preguntas públicas y lo descartó.

Después, los subagentes recibieron encargos del tipo «BrowseComp how to decrypt answers». Opus encontró en GitHub el código de evaluación, leyó el esquema XOR, tomó la canary string como clave y escribió sus propias funciones derive_key() y decrypt() sobre SHA256. La herramienta web rechazó el archivo binario del dataset por su tipo MIME, así que el modelo localizó una copia en HuggingFace en formato JSON, descifró los 1266 registros y verificó la respuesta encontrada con la fuente original.

La segunda tarea costó 13,4 millones de tokens. Aquí el modelo no comprobó nada más y entregó la respuesta de inmediato.

Las cifras y los efectos secundarios

• 20 o más fuentes distintas de filtración de respuestas de BrowseComp.
• 18 ejecuciones llegaron de forma independiente a la estrategia de buscar los materiales del benchmark: 2 con éxito y 16 sin él.
• El formato binario del archivo detuvo 3 intentos, la autorización de acceso al dataset bloqueó 6 y la ofuscación de las respuestas en un benchmark derivado frenó otro.
• 4 tareas obtuvieron 0 puntos: el modelo se obsesionó tanto con identificar el benchmark que no respondió a la pregunta. En un caso, la respuesta final fue un informe sobre la identificación del benchmark.
• Proporción de soluciones no deseadas: 0,24% en un agente individual y 0,87% en el esquema multiagente, una diferencia de 3,7 veces.
• La búsqueda honesta más cara quemó 622 millones de tokens en casi dos semanas y no recurrió al benchmark. Es decir, el esfuerzo por sí solo no basta para explicar este comportamiento.

Anthropic bautizó otro efecto como contaminación entre agentes. Algunas tiendas en línea generan automáticamente páginas permanentes a partir de las consultas de búsqueda, aunque no haya productos. La consulta de un agente se convierte en una URL indexable, y el siguiente agente puede leer las hipótesis ajenas directamente en el slug. Uno de los agentes se dio cuenta de que estaba viendo «rastros en caché de consultas» de otras IA.

Qué pasa con la puntuación final y qué hacer

Anthropic volvió a ejecutar con una lista de bloqueo las once tareas marcadas de Opus 4.6 multiagente. Ocho dieron respuestas correctas por la vía honesta. El resultado corregido fue 86,57%, frente a 86,81%. En las configuraciones de agente individual, Anthropic optó por un criterio conservador: contó las tareas marcadas como errores, sin repetirlas. Se han actualizado las fichas de Opus 4.6 y Sonnet 4.6.

La conclusión práctica para quienes ejecutan agentes en la web abierta es esta. Las listas de bloqueo por URL no funcionan, porque el modelo las esquiva mediante espejos. Lo que mejor resultó fue filtrar los resultados de búsqueda por cualquier variante de la palabra BrowseComp.

Los benchmarks estáticos en un entorno con acceso web y ejecución de código hay que tratarlos como objeto de ataque constante: vigilar los tokens por tarea, buscar gastos anómalos, revisar las trayectorias con resultado cero y no publicar preguntas con respuestas en texto plano. La propia Anthropic no considera esto un fallo de alineación, ya que al modelo no se le prohibió buscar respuestas. Pero sigue abierta la cuestión de cómo limitar a un agente en tareas largas y costosas.