La ciberseguridad es prueba de trabajo

El UK AI Security Institute publicó una evaluación independiente de Claude Mythos Preview en tareas de ciberseguridad.¹ La cifra principal: Mythos completó una simulación de ataque a red corporativa de 32 pasos en 3 de 10 intentos. Ningún otro modelo ha resuelto la cadena completa. Al día siguiente, Drew Breunig publicó el corolario económico: cada uno de esos intentos costó aproximadamente $12.500 en tokens.² Juntos, estos dos análisis reencuadran la ciberseguridad: ya no es un problema de habilidad, sino de cómputo.

La implicación es incómoda. Defender un sistema ahora requiere gastar más tokens descubriendo vulnerabilidades de los que los atacantes gastarán explotándolas.² La seguridad siempre ha sido asimétrica —los atacantes solo necesitan un camino, los defensores deben cubrir todos. Los agentes de IA preservan esa asimetría pero desplazan el eje. El recurso escaso ya no es la experiencia técnica. El recurso escaso es el presupuesto de cómputo.

Lo que el AISI realmente midió

La evaluación utilizó dos enfoques de prueba: desafíos de captura de bandera (CTF) y simulaciones en entornos cibernéticos (cyber range).¹

El cyber range que importa —“The Last Ones” (TLO)— simula un ataque a red corporativa de 32 pasos. Un humano necesitaría aproximadamente 20 horas para completarlo.¹ Mythos completó la cadena completa en 3 de 10 intentos. En las 10 ejecuciones, Mythos promedió 22 de 32 pasos completados. Como comparación, Claude Opus 4.6 promedió 16 pasos en el mismo escenario.¹

En tareas CTF de nivel experto, Mythos tuvo éxito el 73% de las veces.¹

Los presupuestos de tokens cuentan su propia historia. El AISI probó rangos de hasta 2,5 millones de tokens para CTF no experto, 50 millones para CTF experto y 100 millones para las simulaciones de cyber range.¹ La evaluación señala explícitamente que “los modelos continúan progresando con presupuestos de tokens más altos en todos los rangos probados” y que el AISI espera que “las mejoras de rendimiento continuarían más allá” del techo de 100 millones de tokens que probaron.¹

Más tokens, más progreso. No se observó ninguna meseta.

El AISI fue cuidadoso al delimitar el hallazgo. Los cyber ranges carecían de defensores activos, herramientas defensivas y penalizaciones por activar alertas.¹ La evaluación aplica a “sistemas empresariales débilmente defendidos y vulnerables” —no a entornos de producción reforzados con SOC e IDS. Mythos también falló en el escenario “Cooling Tower”, centrado en tecnología operacional.¹

Esas limitaciones importan. Pero la trayectoria importa más. Los modelos anteriores no podían completar la cadena completa en estos escenarios.¹ Ahora uno completa una intrusión corporativa de 32 pasos en 3 de 10 intentos, y la curva de rendimiento se inclina hacia arriba con más cómputo. La pregunta no es si la IA puede penetrar redes empresariales. La pregunta es cuándo la tasa de éxito cruzará el umbral donde automatizarlo se vuelve económicamente racional.

La economía: $12.500 por intento

El análisis de Breunig convierte los hallazgos del AISI en dólares.² A 100 millones de tokens por intento, una sola ejecución de Mythos en TLO cuesta aproximadamente $12.500. Diez intentos en TLO cuestan $125.000.²

Esas cifras suenan grandes en aislamiento. Suenan pequeñas en relación con lo que un compromiso de red corporativa de 32 pasos le cuesta al defensor. El modelo logra una tasa de éxito del 30% a una fracción del costo, se ejecuta bajo demanda, y la tasa de éxito mejora con el presupuesto. Ejecuta la misma cadena de ataque 100 veces en lugar de 10, y el número esperado de penetraciones exitosas salta de 3 a 30 —un aumento de 10x a aproximadamente $1,25 millones en tokens. Caro para un investigador individual. Un error de redondeo para un estado-nación.

La tesis central de Breunig: “para endurecer un sistema necesitas gastar más tokens descubriendo vulnerabilidades de los que los atacantes gastarán explotándolas”.² La seguridad se convierte en una carrera de presupuesto de tokens. En el planteamiento de Breunig, los defensores deben superar el gasto de los atacantes en descubrimiento automatizado de exploits, o pierden por defecto.

Propone un modelo de tres fases: Desarrollo, Revisión y Endurecimiento.² Desarrollo construye el sistema. Revisión detecta clases de errores conocidas. Endurecimiento es la fase nueva —descubrimiento autónomo de exploits ejecutándose continuamente hasta que el equipo agota el presupuesto. La seguridad de un sistema se convierte en una función de cuántos tokens el equipo quema intentando romperlo antes del despliegue.

“No ganas puntos por ser ingenioso”, escribe Breunig. “Ganas pagando más”.²

La Ley de Linus gana una dimensión de tokens

Breunig extiende la Ley de Linus —“con suficientes ojos, todos los errores son superficiales”— para incluir tokens.² Suficientes ciclos de revisión automatizada, con suficiente presupuesto de cómputo, sacarán a la luz vulnerabilidades que la revisión humana pasó por alto durante décadas.

La evidencia respalda la extensión. El trabajo de Carlini en Anthropic, que cubrí en When Your Agent Finds a Vulnerability, encontró una vulnerabilidad del kernel de Linux de 23 años usando un script bash de 10 líneas y Claude Code. Project Glasswing escaló ese enfoque con Mythos para encontrar miles de zero-days en todos los principales sistemas operativos y navegadores. La evaluación del AISI ahora proporciona confirmación independiente de esa capacidad.

Simon Willison añade una observación que vale la pena señalar: la revisión de seguridad impulsada por IA incrementa el valor de las bibliotecas de código abierto, porque los tokens gastados en asegurarlas benefician a todos los usuarios colectivamente.³ El código propietario asume sus propios costos de seguridad. El código abierto amortiza esos costos en toda la base de usuarios.

Breunig hace referencia al producto de revisión de código de Anthropic a $15-20 por revisión como un punto de datos sobre precios actuales.² También cita los incidentes de cadena de suministro de LiteLLM y Axios en el contexto de la seguridad de dependencias —ejemplos del tipo de vulnerabilidades que subrayan la necesidad de revisión automatizada.²

La fórmula se cristaliza: “El código sigue siendo barato, a menos que necesite ser seguro”.² Cada línea de código en un sistema de producción lleva una deuda de seguridad implícita. Esa deuda antes se ocultaba a plena vista —enterrada en los salarios de los equipos de seguridad y en la esperanza probabilística de que la revisión manual detectaría los errores críticos. La seguridad basada en tokens hace que el costo sea explícito y medible.

Lo que las limitaciones realmente significan

Las limitaciones del AISI merecen una lectura cuidadosa, no un descarte.

La ausencia de defensores activos cambia el cálculo significativamente. Una cadena de ataque de 32 pasos contra un sistema sin monitoreo, sin alertas y sin respuesta a incidentes es un problema fundamentalmente diferente al de la misma cadena contra un SOC con personal. Las redes empresariales reales tienen EDR, segmentación de red, detección de anomalías y analistas humanos. Cada alerta que dispara un atacante automatizado es una oportunidad para que la defensa responda.

La ausencia de penalizaciones por ruido significa que el modelo puede intentar enfoques de fuerza bruta que un atacante humano evitaría. Un adversario real que dispara cientos de alertas IDS en una hora es investigado. Los escenarios del AISI no modelaron ese ciclo de retroalimentación. En una red real, el ruido es costoso —para el atacante. El sigilo restringe el espacio de búsqueda. Elimina esa restricción y el problema se vuelve estrictamente más fácil.

El fracaso en Cooling Tower también es instructivo. Mythos resolvió el escenario TLO enfocado en TI pero falló en el de tecnología operacional.¹ Los entornos OT tienen protocolos diferentes, restricciones diferentes y modos de fallo diferentes. El AISI señala que el modelo se atascó en porciones de TI de ese escenario, así que el fracaso no necesariamente indica poca capacidad específica en OT —pero las capacidades del modelo claramente no son uniformes entre dominios. La penetración de redes de TI y los ataques a sistemas de control industrial son problemas diferentes, y sacar conclusiones sobre la preparación en OT a partir de esta evaluación requiere cautela.

Pero las limitaciones también tienen fecha de caducidad. Los presupuestos de tokens escalan. Las capacidades de los modelos mejoran entre evaluaciones. La tasa de éxito del 30% contra redes sin defensa es el piso, no el techo. El propio AISI espera que el rendimiento mejore más allá de los presupuestos probados.¹ Los defensores que descartan los hallazgos porque los escenarios carecían de defensa activa están apostando contra la Ley de Moore aplicada a la inferencia.

Implicaciones operativas para profesionales

Para cualquiera que ejecute agentes de IA en producción —y yo ejecuto agentes autónomos durante la noche a través del Ralph Loop con 95 hooks como infraestructura de seguridad— el marco de prueba de trabajo cambia la forma de pensar sobre la defensa.

Los hooks de seguridad son un gasto mínimo, no uno suficiente. Mis 95 hooks controlan lo que los agentes pueden hacer: bloquean force pushes, validan credenciales, imponen sandboxes. Esos hooks evitan que mis propios agentes causen daño. No hacen nada contra un atacante externo que gasta 100 millones de tokens sondeando los sistemas con los que esos agentes interactúan. La infraestructura de hooks es necesaria pero no suficiente.

Las pruebas ofensivas automatizadas se vuelven obligatorias. El modelo de tres fases de Breunig —Desarrollo, Revisión, Endurecimiento— implica que cada pipeline de despliegue necesita una fase adversarial donde agentes de IA intentan romper el sistema antes de que se lance. No una prueba de penetración de casilla de verificación. Un ejercicio de agotamiento de presupuesto de tokens. Ejecuta descubrimiento automatizado de exploits hasta que se agote el presupuesto, corrige lo que surja, repite.

El Ralph Loop ahora tiene un corolario de seguridad. Escribí sobre la degradación iterativa de seguridad en el contexto del rendimiento —agentes que pasan todas las pruebas mientras introducen ralentizaciones de 446x. El mismo patrón aplica a la seguridad. Un agente que escribe código correcto, funcional y bien probado puede aun así introducir vulnerabilidades sutiles que solo salen a la luz bajo revisión adversarial automatizada. La solución es la misma: añadir la puerta que falta. Los benchmarks de rendimiento detectan regresiones de rendimiento. El red-teaming automatizado detecta regresiones de seguridad.

Las dependencias de código abierto merecen presupuestos de tokens. La observación de Willison sobre el beneficio colectivo aplica directamente a la gestión de dependencias. Cada biblioteca de código abierto en un stack de producción está recibiendo revisión de seguridad automatizada de alguien, o no lo está. Breunig cita los incidentes de cadena de suministro de LiteLLM y Axios en el contexto de la seguridad de dependencias —casos donde las vulnerabilidades persistieron en bibliotecas ampliamente utilizadas.² Los profesionales deberían evaluar sus árboles de dependencias con una nueva pregunta: ¿quién está gastando tokens en la seguridad de esta biblioteca?

La matemática incómoda

El marco de prueba de trabajo hace explícita la economía de la seguridad de una manera que los modelos basados en experiencia nunca lograron. Bajo el modelo anterior, la calidad de la seguridad era función de a quién contratases y cuán hábil fuera. Bajo el nuevo modelo, la calidad de la seguridad es función de cuántos tokens gastas intentando romper tus propios sistemas.

El talento sigue importando —alguien necesita interpretar resultados, priorizar correcciones y tomar decisiones arquitectónicas. Pero la fase de descubrimiento, la parte donde se encuentran las vulnerabilidades, es cada vez más un problema de cómputo. Y los problemas de cómputo tienen una propiedad conocida: la entidad con el presupuesto mayor gana.

El paralelo con la prueba de trabajo de las criptomonedas es instructivo, aunque imperfecto. Los mineros de Bitcoin queman electricidad para asegurar la cadena. Los defensores queman tokens para asegurar el sistema. En ambos casos, la garantía de seguridad es proporcional al cómputo invertido. En ambos casos, un atacante con un presupuesto mayor puede superar la defensa. La diferencia: la dificultad de minería de Bitcoin se ajusta automáticamente. Los presupuestos de tokens de seguridad requieren juicio humano sobre cuánto es suficiente.

Para organizaciones bien financiadas, el camino es claro. Añade descubrimiento autónomo de exploits al pipeline de despliegue. Establece un presupuesto de tokens proporcional al perfil de riesgo del sistema. Agota el presupuesto. Corrige lo que surja. Despliega.

Para todos los demás, el camino es menos cómodo. Si no puedes permitirte gastar más tokens defendiendo de los que los atacantes gastarán atacando, necesitas depender de infraestructura compartida —revisión de seguridad de código abierto, escaneo provisto por proveedores, defensa colectiva. El equivalente en seguridad de la inmunidad de rebaño. Y como la inmunidad de rebaño, solo funciona si suficientes participantes contribuyen. Aprovecharse de la revisión de seguridad de código abierto sin contribuir tokens de vuelta es una estrategia que funciona hasta que deja de funcionar.

La evaluación del AISI demostró que los agentes de IA pueden completar ataques a redes corporativas. Breunig argumenta que la defensa es un problema de gasto. Willison identificó la única ventaja estructural que tienen los defensores: la infraestructura compartida amortiza costos entre todos los que la usan.

La pregunta para cada profesional es la misma que los sistemas de prueba de trabajo siempre han planteado: ¿cuánto cómputo estás dispuesto a quemar?

Citas