La startup de ciberseguridad AISLE, con su modelo pequeño de 3.6B parámetros que cuesta solo 0.11 dólares por cada millón de tokens, reproduce parte de las demostraciones centrales del sistema insignia de ciberseguridad de Anthropic, Mythos. Los límites de las capacidades de ciberseguridad con IA son más “irregulares” de lo que crees.
（Resumen de contexto: cuando Anthropic publica Mythos, ¿sería el momento de la “bomba nuclear” de DeFi?）
（Información de contexto: Mythos de Anthropic es tan potente que asusta a las reuniones de emergencia: Bessent y Powell convocan a Citigroup, Goldman Sachs, Bank of America, y Morgan grande y pequeña; los cinco bancos se enfocan en riesgos financieros）
Tabla de contenidos
Toggle
- ¿Qué mostró Mythos y qué reprodujo el modelo pequeño?
- Por qué un modelo más grande no equivale a un sistema más seguro
- Dónde está (y dónde no está) el foso
Anthropic publicó esta semana un modelo no publicado aún, Claude Mythos Preview, y al mismo tiempo puso en marcha el proyecto Project Glasswing, un plan “Glasswing” compuesto por 12 empresas tecnológicas, como Amazon, Apple, Microsoft, CrowdStrike, Cisco, etc., que utilizan ese modelo para realizar investigaciones de ciberseguridad defensiva.
Debido a que se afirma que Mythos identifica de forma autónoma miles de vulnerabilidades zero-day (vulnerabilidad de día cero, fallas de seguridad que aún no están parcheadas y que ni siquiera los fabricantes pueden conocer) en cada sistema operativo principal y en navegadores, sugiere que se abrirá un nuevo era de defensa de ciberseguridad liderada por IA.
Sin embargo, en menos de una semana, la startup de ciberseguridad AISLE, cofundada por investigadores de DeepMind y Anthropic Stanislav Fort, publicó un informe sistemático en el blog técnico de la empresa.
La conclusión central es directa: en la tarea insignia de demostración de Mythos, un modelo pequeño de código abierto con solo parámetros activos de 3.6B y un costo de 0.11 dólares por cada millón de tokens logra el mismo resultado de detección de vulnerabilidades.
¿Qué mostró Mythos y qué reprodujo el modelo pequeño?
AISLE diseñó tres tandas de pruebas, cada una correspondiente a tareas de ciberseguridad con diferentes dificultades y naturaleza.
La primera tanda son pruebas de falsos positivos de OWASP (Open Web Application Security Project).
Traducción: una pieza de código de consulta Java SQL parece SQL Injection (ataque por inyección en bases de datos), pero en realidad es seguridad lógica. La respuesta correcta es que no hay vulnerabilidad.
Los resultados de la prueba muestran un efecto de scaling (escalado de escala) casi inverso: el modelo pequeño de código abierto GPT-OSS-20b (3.6B parámetros activos, $0.11/M tokens) siguió correctamente la lógica del programa y determinó que no era dañino.
En cambio, Claude Sonnet 4.5, todas las series GPT-4.1/5.4 (excepto o3 y pro), toda la serie de Anthropic hasta Opus 4.5, erraron con confianza como vulnerabilidades de alto riesgo. Solo acertaron muy pocos modelos de la cima — o3, OpenAI-pro, Sonnet 4.6, Opus 4.6.
La segunda tanda es una vulnerabilidad de FreeBSD NFS, el CVE-2026-4747 que se mostró especialmente en el lanzamiento insignia de Mythos: una vulnerabilidad de ejecución remota de código sin autorización con 17 años de historia.
Resultado: los 8/8 modelos evaluados detectaron con éxito, incluido ese modelo pequeño con 3.6B parámetros activos. Todos los modelos identificaron correctamente stack buffer overflow (desbordamiento de búfer en pila), calcularon el espacio restante y lo calificaron como Critical RCE.
La conclusión de AISLE es: esta capacidad de detección ya está “comercializada”.
La tercera tanda es una vulnerabilidad de OpenBSD SACK (27 años de historia), que requiere realmente razonamiento matemático: seguir una cadena de lógica paso a paso que rastrea un desbordamiento de entero con signo (signed integer overflow).
La dificultad aumenta de forma notable y el desempeño del modelo se divide. GPT-OSS-120b (5.1B parámetros activos) reproduce completamente la cadena de explotación; AISLE lo califica como A+; la versión de código abierto Kimi K2 obtiene A-; mientras que Qwen3 32B da una conclusión errónea de “el código es robusto”, calificándolo como F.
Incluso en esta tarea más difícil, un modelo de código abierto con un costo extremadamente bajo logra la misma demostración equivalente a la del sistema insignia.
Por qué un modelo más grande no equivale a un sistema más seguro
El punto real de este informe no es “que un modelo pequeño es suficiente”, sino que la ciberseguridad con IA es, en su estructura, mucho más compleja de lo que el público imagina.
AISLE descompone el pipeline de ciberseguridad con IA en cinco sub-tareas independientes:
- Escaneo de amplio espectro (broad scanning)
- Detección de vulnerabilidades (vulnerability detection)
- Validación y clasificación (triage and validation)
- Generación de parches (patch generation)
- Construcción de explotación (exploit construction)
La naturaleza de scaling de cada sub-tarea es diferente y, por tanto, también lo es la capacidad de modelo necesaria. El anuncio de Mythos presenta estos cinco niveles integrados en un sistema completo, pero en realidad las diferencias en los requisitos del modelo son enormes: algunas sub-tareas ya se saturan por completo con 3.6B parámetros, mientras que otras requieren una capacidad de razonamiento compleja.
Esto hace eco del concepto “Jagged Frontier” (frontera irregular) propuesto en 2023 por investigadores de la Harvard Business School como Dell’Acqua y Mollick: los límites de las capacidades de la IA no son una curva suave, sino dientes de sierra con concavidades y convexidades; en algunas tareas superan muy por encima a los humanos, pero en tareas adyacentes resultan sorprendentemente frágiles.
El estudio muestra que, si los usuarios despliegan IA dentro de su límite de capacidades, la productividad mejora aproximadamente un 40%; si se extiende imprudentemente más allá del límite, el desempeño en cambio disminuye 19%.
Bajo este marco, AISLE propone una inferencia más operativa: “mil detectives que alcanzan para todo buscan en todas partes; en lugar de que un detective genio adivine dónde buscar, se pueden descubrir más vulnerabilidades”.
Un despliegue masivo de modelos de bajo costo para escaneo de amplio espectro puede tener, en el beneficio general, ventajas sobre la programación cautelosa de un único modelo de alto costo. AISLE indica que, desde mediados de 2025, ya ejecuta sistemas de descubrimiento de vulnerabilidades en objetivos reales: encuentra 15 CVE en OpenSSL (entre los cuales una sola versión de seguridad incluye 12, CVSS 9.8 Critical), 5 en curl, y en más de 30 proyectos en total más de 180 CVE externas verificadas.
Dónde está (y dónde no está) el foso
Este análisis, para Anthropic, ni es una crítica integral ni un simple respaldo.
AISLE deja claro que el significado de Mythos es demostrar que la categoría de “ciberseguridad con IA” es real: no se trata solo de un concepto en un laboratorio de demostración, sino de un sistema que puede operar en objetivos reales. Lo que Anthropic está haciendo es maximizar la “densidad de inteligencia por token”, lo cual sigue teniendo un valor difícil de sustituir en tareas que requieren razonamiento profundo.
Pero AISLE también señala un problema más fundamental para toda la industria: el foso está en el sistema, no en el propio modelo.
En el ámbito de la ciberseguridad, AISLE considera que los diseños arquitectónicos que incorporan conocimientos profesionales profundos, por ejemplo: cómo descomponer tareas, cómo programar modelos de distintos costos entre sub-tareas, y cómo mantener la confianza de los mantenedores en entornos de producción, es de verdad el origen de la diferenciación.
Un sistema que puede encontrar vulnerabilidades CVSS 9.8 en OpenSSL, y otro que detecta vulnerabilidades conocidas con patrones en una demostración controlada, no requieren solo un modelo más potente, sino una lógica de ingeniería completamente distinta.
En resumen, el informe de AISLE descubre que los modelos más baratos y abiertos ya pueden reproducir parte de sus demostraciones centrales. El problema real quizá no sea cuál modelo es el más fuerte, sino quién primero logra poner en funcionamiento, en entornos de producción, la arquitectura de estas cinco sub-tareas.
