La ciberseguridad es prueba de trabajo: ataques con IA a $12.500 por intento

La ciberseguridad se está convirtiendo en un problema de cómputo, no de habilidad. La evaluación del UK AISI mostró que Claude Mythos completó una simulación de ataque a red corporativa de 32 pasos en 3 de 10 intentos a $12.500 por ejecución. La tesis de Drew Breunig: los defensores deben gastar más que los atacantes en descubrimiento automatizado de exploits, o pierden por defecto.

El UK AI Security Institute publicó una evaluación independiente de Claude Mythos Preview en tareas de ciberseguridad.¹ El número titular: 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 replantean la ciberseguridad: ya no es un problema de habilidad, sino de cómputo.

La implicación es incómoda. En el planteamiento de Breunig, defender un sistema ahora requiere gastar más tokens descubriendo exploits de los que los atacantes gastarán explotándolos.² La seguridad siempre ha sido asimétrica: los atacantes solo necesitan un camino, los defensores necesitan 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.

Qué midió realmente el AISI

La evaluación utilizó dos enfoques de prueba: desafíos capture-the-flag (CTF) y simulaciones en cyber ranges.¹

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

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 en cyber ranges.¹ La evaluación señala explícitamente que “los modelos continúan progresando con presupuestos de tokens mayores 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. Sin meseta observada.

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 range “Cooling Tower”, enfocado en tecnología operacional.¹

Esas salvedades importan. Pero la trayectoria importa más. Los modelos anteriores no podían completar la cadena completa en estos ranges.¹ 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 sistemas débilmente defendidos y vulnerables (el AISI demostró que sí puede). La pregunta es cuándo la tasa de éxito contra entornos reforzados cruza el umbral donde se vuelve económicamente racional automatizar.

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.²

Esos números suenan grandes por sí solos. Suenan pequeños 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 (asumiendo intentos independientes e idénticamente configurados contra un objetivo estático) y el número esperado de penetraciones exitosas salta de 3 a 30 por aproximadamente $1,25 millones en tokens. Costoso para un investigador individual. Un error de redondeo para un actor estatal.

La tesis central de Breunig: “para reforzar un sistema necesitas gastar más tokens descubriendo exploits de los que los atacantes gastarán explotándolos”.² La seguridad se convierte en una carrera de presupuesto de tokens. Breunig argumenta que 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 Reforzamiento.² Desarrollo construye el sistema. Revisión detecta clases de bugs conocidas. Reforzamiento es la fase nueva: descubrimiento autónomo de exploits ejecutándose continuamente hasta que el equipo agote el presupuesto. La seguridad de un sistema se convierte en 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 adquiere una dimensión de tokens

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

La evidencia respalda la extensión. Como se documenta en When Your Agent Finds a Vulnerability, el trabajo de Carlini en Anthropic reportedly encontró una vulnerabilidad del kernel de Linux de 23 años usando un script bash de 10 líneas y Claude Code.⁴ Como se documenta en Project Glasswing, Anthropic escaló ese enfoque con Mythos para descubrir lo que describen como miles de zero-days en sistemas operativos y navegadores principales.⁵ La evaluación del AISI ahora proporciona confirmación independiente de la capacidad subyacente.

Simon Willison añade una observación que vale la pena destacar: la revisión de seguridad impulsada por IA aumenta 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 referencia el 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 seguridad de dependencias, ejemplos del tipo de vulnerabilidades de cadena de suministro 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 equipos de seguridad y la esperanza probabilística de que la revisión manual detectara los bugs críticos. La seguridad basada en tokens hace el costo explícito y medible.

Qué significan realmente las salvedades

Las salvedades del AISI merecen una lectura cuidadosa, no su 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 distinto a 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 un atacante automatizado dispara 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 ranges del AISI no modelaron ese ciclo de retroalimentación. En una red real, el ruido es costoso para el atacante. La 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 range TLO enfocado en IT pero falló en el range de tecnología operacional.¹ Los entornos OT tienen protocolos diferentes, restricciones diferentes y modos de falla diferentes. El AISI señala que el modelo se atascó en las porciones de IT de ese range, por lo 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 IT y los ataques a sistemas de control industrial son problemas diferentes, y extraer conclusiones sobre la preparación en OT a partir de esta evaluación requiere cautela.

Pero las salvedades también tienen fecha de vencimiento. Los presupuestos de tokens escalan. Las capacidades de los modelos mejoran entre evaluaciones. La tasa de éxito del 30% contra redes no defendidas 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 ranges carecían de defensa activa están apostando a que el escalado de inferencia se estancará antes de alcanzar sus defensas, una apuesta que los propios datos del AISI, dentro de los rangos probados, no respaldan.

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, aplican 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, Reforzamiento) implica que cada pipeline de despliegue necesita una fase adversarial donde agentes de IA intentan romper el sistema antes de que se envíe. No una prueba de penetración de formulario. Un ejercicio de agotamiento de presupuesto de tokens. Ejecuta descubrimiento automatizado de exploits hasta que el presupuesto se agote, 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 cada prueba mientras introducen ralentizaciones de 446x. El mismo patrón aplica a la seguridad. Un agente que escribe código correcto, funcional y bien probado aún puede introducir vulnerabilidades sutiles que solo emergen bajo revisión adversarial automatizada. La solución es la misma: añadir la compuerta faltante. 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 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 contratabas y cuán hábiles eran. 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 los agentes automatizados sacan vulnerabilidades a la superficie, es cada vez más un problema de cómputo. Y dentro de los rangos que el AISI probó, los problemas de cómputo favorecen a la entidad dispuesta a gastar más.

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 gastado. En ambos casos, un atacante dispuesto a gastar más cómputo obtiene ventaja. 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 a seguir es claro. Añadir descubrimiento autónomo de exploits al pipeline de despliegue. Establecer un presupuesto de tokens proporcional al perfil de riesgo del sistema. Agotar el presupuesto. Corregir lo que surja. Desplegar.

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. Beneficiarse gratuitamente 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 mostró 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 los 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?

FAQ

¿Qué significa “la ciberseguridad es prueba de trabajo”?

La frase replantea la ciberseguridad: ya no es un problema de habilidad, sino de cómputo. La evaluación del UK AISI mostró que Claude Mythos puede completar un ataque a red corporativa de 32 pasos en 3 de 10 intentos a aproximadamente $12.500 por intento. Defender un sistema ahora requiere gastar más tokens descubriendo exploits de los que los atacantes gastarán explotándolos. La calidad de la seguridad se convierte en función de cuántos tokens quemas intentando romper tus propios sistemas antes del despliegue.

¿Cómo se desempeñó Claude Mythos en tareas de ciberseguridad?

Mythos completó la simulación completa de ataque a red corporativa “The Last Ones” de 32 pasos en 3 de 10 intentos, promediando 22 de 32 pasos en todas las ejecuciones. En tareas capture-the-flag de nivel experto, Mythos tuvo éxito el 73% de las veces. El AISI señaló que el rendimiento continúa mejorando con presupuestos de tokens mayores, sin meseta observada hasta el techo de 100 millones de tokens probado.

¿Cuáles son las limitaciones de la evaluación del AISI?

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 range de tecnología operacional “Cooling Tower”. Las redes empresariales reales tienen EDR, segmentación de red, detección de anomalías y analistas humanos que la evaluación no modeló.

¿Qué deberían hacer los profesionales ante estos hallazgos?

Despliega hooks PreToolUse como capa mínima de seguridad. Añade pruebas ofensivas autónomas al pipeline de despliegue como ejercicio de agotamiento de presupuesto de tokens. Evalúa las dependencias de código abierto con una nueva pregunta: ¿quién está gastando tokens en la seguridad de esta biblioteca? El marco de prueba de trabajo significa que cada sistema en producción necesita una fase adversarial donde agentes de IA intenten romperlo antes del despliegue.

Citations