Anthropic presentó Claude Mythos 5.2 el 9 de noviembre de 2026 con un resultado concreto para quienes mantienen software. En una prueba con versiones antiguas de proyectos afectados por vulnerabilidades conocidas, el modelo redescubrió el 89,6 % de los fallos, frente al 78,3 % de Mythos 5.1. La empresa reserva el acceso directo a profesionales y organizaciones que pasan por sus programas de verificación. Para los equipos que solo necesitan revisar un repositorio, el mismo lanzamiento abre otra vía a través de Claude Security.
Mythos 5.2 comparte modelo base con Fable 5.2. La diferencia está en las tareas que Anthropic permite completar a cada usuario. En seguridad, reproducir de forma fiable un fallo sirve tanto para comprobar un parche como para atacar un sistema aún vulnerable. En biología, una consulta especializada puede pertenecer a un proyecto legítimo y parecerse mucho a otra con fines perjudiciales. Anthropic ajusta determinados controles según el trabajo que haya aprobado. Anuncio de Claude Mythos 5.2.
Qué midió la prueba de las 1.829 vulnerabilidades
Para su evaluación interna de octubre, Anthropic reunió 1.829 vulnerabilidades con identificador CVE. El modelo recibió copias del código de los proyectos tal como estaban antes de que sus responsables corrigieran el problema. Como el evaluador conoce el fallo que busca, puede comprobar si el hallazgo de Claude coincide con él. La distancia entre las dos versiones de Mythos fue de 11,3 puntos porcentuales. Es una mejora en una tarea que admite una respuesta comprobable.
En un proyecto activo falta precisamente esa respuesta de referencia. Si el modelo entrega cinco informes sobre una extensión de WordPress, el mantenedor todavía desconoce cuántos describen defectos distintos, cuántos son falsas alarmas y cuántos problemas han pasado inadvertidos. El 89,6 % tampoco indica qué proporción de las alertas que recibirá ese mantenedor merece atención urgente. Para estimar eso hace falta revisar las alertas individuales y conocer qué versiones del producto tiene instaladas la gente.
Mozilla aporta un punto de comparación fuera de esa prueba. Brian Grinstead, ingeniero de la organización, explicó en el anuncio que sus métricas de descubrimiento aproximadamente se duplicaron entre las campañas realizadas con Mythos 5.1 y 5.2. Es un resultado de esas campañas en Firefox. En mayo, Mozilla ya había descrito el trabajo que siguió a las detecciones de una versión preliminar anterior de Mythos. Más de cien personas contribuyeron código al esfuerzo de corrección, además de la labor de clasificación, pruebas y preparación de los lanzamientos. Informe técnico de Mozilla sobre Firefox.
Quién puede solicitar Claude Mythos 5.2 para ciberseguridad
El Cyber Verification Program distingue tres niveles. El primero, Defense Access, cubre operaciones defensivas como la respuesta a incidentes, el análisis de programas maliciosos y la validación de vulnerabilidades. Pueden solicitarlo organizaciones y personas, incluidos quienes mantienen proyectos abiertos o participan en programas de recompensas por fallos. Una persona que revisa avisos recibidos sobre su propia extensión tiene aquí un punto de partida si las restricciones de los modelos de uso general interrumpen ese trabajo.
Red Team Access está dirigido a organizaciones que realizan pruebas de intrusión autorizadas y simulaciones de adversarios. Specialized Access corresponde a equipos cuyo cometido exige pruebas ofensivas de alto riesgo en sistemas críticos. Una empresa eléctrica, por ejemplo, puede trabajar con acceso defensivo para investigar alertas de sus ordenadores de oficina. El hecho de suministrar electricidad no le concede automáticamente el nivel especializado. Lo determinante es qué sistemas va a evaluar el equipo y con qué autorización.
Para una agencia que audita aplicaciones de clientes hay un detalle previo al presupuesto. El programa distingue el uso interno del trabajo que se realiza para terceros, que requiere una aprobación adicional. La organización debe solicitar acceso desde la cuenta en la que vaya a trabajar y describir el caso de uso. Conviene acordar también con el cliente qué dominio, repositorio y entorno entran en la prueba. La aprobación de Anthropic y el permiso del propietario del sistema responden a dos preguntas distintas. Condiciones y niveles del programa de ciberseguridad.
Claude Security ofrece otra vía para revisar un repositorio
Los clientes de Claude Enterprise pueden utilizar Claude Security, la herramienta de revisión de código que incorpora Mythos 5.2, incluso sin pertenecer al programa de verificación de ciberseguridad. El producto está en beta pública para Enterprise. Analiza el repositorio, sigue el recorrido de los datos entre archivos y somete sus hallazgos a una segunda comprobación antes de mostrarlos. El equipo puede ajustar qué amenazas debe tener en cuenta el análisis. Cada propuesta de parche pasa después por revisión y aprobación humanas. Funcionamiento de Claude Security.
Pensemos en una aplicación que permite descargar facturas. La alerta dice que una cuenta podría leer el documento de otra. Quien la revise necesita saber qué versión está afectada, qué permisos requiere la petición y en qué punto el servidor comprueba la identidad del propietario. Una prueba con dos cuentas ficticias, en un entorno autorizado, puede verificar tanto que se rechaza la descarga ajena como que sigue funcionando la propia. Esas dos comprobaciones ayudan a decidir si el parche propuesto corrige el problema sin romper una función que los clientes necesitan.
Cómo funciona el acceso para ciencias de la vida
El Life Sciences Verification Program tiene reglas diferentes. Está en beta para organizaciones verificadas con Claude Team, Enterprise o la plataforma API. El administrador registra el interés del centro y Anthropic evalúa si reúne las condiciones para presentar una solicitud formal. Los planes personales quedan fuera de esta vía. Por eso, para un investigador que trabaje en una universidad, el primer interlocutor es quien administra la cuenta institucional y conoce el proyecto que se pretende realizar. Formulario institucional de ciencias de la vida.
El programa contempla una autorización ordinaria para las tareas de un equipo, renovable cada año, y una ampliación para proyectos concretos de mayor riesgo, renovable cada seis meses. Al presentar el programa el 17 de septiembre, Anthropic indicó que, en el caso de Mythos, solo un grupo reducido de entidades con verificación adicional podía obtener ese permiso de alto riesgo. Las salvaguardas de otras áreas, como las de ciberseguridad, siguen vigentes. Un laboratorio que colabora con un hospital en un estudio no obtiene por ese motivo acceso para auditar los sistemas informáticos del hospital. Alcance de las autorizaciones científicas.
Como ejemplo de lo que aporta el modelo en este ámbito, Anthropic publicó una prueba sobre cápsides, las cubiertas de proteínas de ciertos virus. La dificultad consiste en predecir cómo encajan decenas de cadenas para formar una cubierta completa. Mythos 5.2 escribió código que aprovechaba dos herramientas de predicción existentes y las simetrías conocidas de estas estructuras. Según Anthropic, el método reprodujo correctamente 28 de las 34 estructuras que intentó modelar. La prueba mide una predicción estructural. Evaluar la utilidad de una cubierta concreta para administrar un tratamiento exigiría evidencia experimental adicional.
Qué revela una prueba de aislamiento sobre sus límites
Anthropic también preparó más de 1.800 escenarios con una debilidad deliberada en el entorno aislado donde se ejecutaba el modelo. En el 3,1 % de los escenarios, Mythos 5.2 utilizó archivos o credenciales colocados fuera de ese entorno. Mythos 5.1 lo había hecho en el 21 %. La mayoría de las tareas se diseñaron de modo que resultaran imposibles de resolver dentro de los límites asignados. Eso importa al interpretar los porcentajes. Convertirlos en una predicción de incidentes por cada cien tareas normales daría al experimento un alcance que su diseño no permite. Informe técnico de seguridad de los dos modelos.
Para un responsable que decida si incorpora Mythos 5.2, una buena primera prueba sería volver sobre un defecto histórico propio. Ya hay una versión afectada, una corrección aceptada y alguien capaz de juzgar el resultado. Comparar el informe de Claude con esa historia permite medir cuánto tiempo cuesta verificar su explicación y si la prueba propuesta distingue la versión vulnerable de la corregida. Esa medida local ayuda a decidir qué parte del trabajo delegar y dónde sigue haciendo falta la experiencia de quien mantiene el sistema.
