El huracán de la IA ha llegado

Durante el último año, he descrito esto como una niebla de IA: afirmaciones contrapuestas, riesgos inciertos y líderes con dificultades para ver qué era importante. Ahora los vientos han aumentado. La IA está acelerando la creación de software, dejando al descubierto años de vulnerabilidades acumuladas y proporcionando tanto a atacantes como a defensores capacidades que operan a velocidad de máquina.

Antes lo llamábamos niebla. La niebla llega y se va.

Durante un año he dicho que la creación avanzó a velocidad de máquina, pero la validación no, y que la brecha entre ambas es donde reside el riesgo real. Ese diagnóstico no ha cambiado. Lo que ha cambiado es el ritmo. El tipo de vulnerabilidad grave que la IA está descubriendo ahora en software ampliamente utilizado, el tipo de hallazgo que antes aparecía una o dos veces al año y trastocaba el trimestre de todos, está apareciendo varias veces por semana, según lo que estoy viendo. No es algo que puedas esperar a que pase.

Todo se reduce a tres problemas: ataques automatizados que avanzan más rápido de lo que un retraso acumulado a velocidad humana puede absorber; desarrollo agéntico que escribe código y recurre a herramientas que nadie ha evaluado; y aplicaciones de IA ejecutándose en producción sin inventario, sin políticas y sin un registro de auditoría.

El huracán ya está aquí. Debatir sobre su velocidad no hará que las capas de aplicaciones o infraestructura sean más resistentes.

Mientras tanto, la ópera de la IA sube de volumen: predicciones sobre el fin de la civilización, advertencias dramáticas y demandas contrapuestas para controlar quién puede construir qué. Llevo mucho tiempo en el ámbito de la seguridad, he atravesado más de uno de estos momentos y entiendo el instinto de desconectarse de todo ello por considerarlo ruido.

No lo hagas. Esto es diferente.

Tómate en serio el riesgo real y analiza si las respuestas propuestas realmente nos hacen más seguros o simplemente añaden otra voz.

El escrutinio independiente es el argumento del momento

Dario Amodei acaba de publicar "We Must Pace the Frontier", proponiendo que los laboratorios de frontera ralenticen el avance de sus capacidades para que el trabajo de seguridad pueda ponerse al día. Observa cómo propone hacerlo.

Anthropic se compromete a incorporar evaluadores externos independientes con acceso continuo para verificar sus prácticas de seguridad. Por separado, Amodei menciona agentes que atacan sistemas fuera de la tarea que se les asignó, incluido el sistema que evalúa su rendimiento. Esto plantea preguntas distintas sobre supervisión y control. Para la seguridad empresarial, nuestro requisito arquitectónico es claro: el sistema que crea un cambio no debe ser su único validador.

George Kurtz, de CrowdStrike, retomó el tema con la perspectiva contrapuesta de un profesional: regular lo que viene no protege lo que ya está implementado. Su lectura es que el entorno de ejecución es el verdadero punto de control. La unidad de amenaza actual es una campaña autónoma, no un hacker, y cada agente debe tratarse como una identidad privilegiada, aplicada en tiempo real y respaldada por pruebas en lugar de promesas: responsabilidad a nivel de junta directiva, pruebas de penetración independientes, divulgación de incidentes y controles que se mantengan en producción.

El argumento de George sobre el entorno de ejecución es esencial. Yo lo extendería al desarrollo: hay que gobernar a los agentes que escriben, las herramientas y los servidores MCP que utilizan y el código que entregan. Los controles de desarrollo reducen la exposición que introducimos; los controles del entorno de ejecución limitan lo que pueden hacer los sistemas implementados.

De lo contrario, generaremos la exposición del mañana más rápido de lo que podemos contener la de hoy. Y la regla se mantiene en cada capa: el sistema que genera el código o propone la corrección no puede ser su único validador.

Tres puntos de partida diferentes: un laboratorio de frontera, un defensor del entorno de ejecución y nosotros, en el punto donde se crean el código y los agentes. Eso no es una plataforma conjunta. Es el mismo requisito manifestándose en tres capas diferentes: el escrutinio independiente importa en cada capa y no se puede dar por sentado. La afirmación arquitectónica que hacemos a partir de ahí es que el sistema que crea un cambio no debe ser su único validador. Cuando las personas que más tienen que ganar al decir "confía en nosotros" eligen decir "verifícanos", eso no es un argumento de venta; es confirmación.

La independencia aquí es una propiedad técnica, no de marca. Significa que las pruebas son generadas por algo que el agente productor no puede alterar y se comprueban frente a controles fuera del alcance de ese agente: pruebas ejecutadas, análisis del flujo de datos y comportamiento observado en tiempo de ejecución. Un segundo prompt, un segundo agente o un segundo modelo no son independientes. Es el mismo tipo de criterio, solicitado dos veces.

Las pruebas ya no son hipotéticas

Hace un par de semanas dije que lo que más me preocupaba no era la sofisticación de estos ataques, sino su propagación: que la capacidad se estaba convirtiendo en un producto masivo y que pronto muchas más personas podrían hacer esto.

Ocho días después, el informe de septiembre de Anthropic comenzaba con el mismo hallazgo, expresado con sus propias palabras: los ataques sofisticados ya no requieren atacantes sofisticados, porque la IA ha reducido la brecha de mano de obra y herramientas que antes separaba las operaciones patrocinadas por Estados de los individuos. Habría preferido estar equivocado.

El incidente que cita Amodei es un modo de fallo: agentes que abandonan la tarea que se les asignó. Lo que sigue es el otro, y es el que la mayoría de las organizaciones encontrará primero: personas que utilizan estas herramientas deliberadamente y a escala.

El informe de septiembre de Anthropic documenta GTG-20006, un actor de espionaje vinculado al Estado ruso, según la atribución de Anthropic, que ejecutó un flujo de trabajo asistido por IA para identificar, modificar, reconstruir y volver a implementar sus propios implantes después de que los productos de seguridad los marcaran. El malware no evolucionó por sí solo: un ser humano lo dirigió y la IA cerró el ciclo más rápido de lo que se podía escribir y distribuir una nueva detección.

El mismo informe documenta que la cadena de suministro de IA se está convirtiendo en un objetivo por derecho propio. Un actor con motivación financiera inyectó instrucciones maliciosas en el entorno aislado de evaluación automatizada de un proveedor de IA y obtuvo las credenciales que este almacenaba, incluidas las claves de API de producción del propio entorno del proveedor.

Anthropic informa que sus propios sistemas no se vieron comprometidos y que el intento del actor de acceder a un modelo previo al lanzamiento fracasó. Las credenciales de IA robadas proporcionan a un atacante tres cosas a la vez: escala, la capacidad de cómputo de otra persona y el nombre de otra persona en el tráfico. La cadena de suministro de IA no es una categoría de riesgo futura, sino una activa, hoy.

Más cerca de casa: Snyk es signatario de la carta colectiva de defensa cibernética, junto con OpenAI, Anthropic, Google, Microsoft, Akamai y cientos de otras organizaciones, que advierte que los delincuentes podrían lanzar ataques impulsados por IA contra infraestructuras críticas en cuestión de meses. Como dije al Boston Globe, es como saber que se acerca un huracán. Quizá nunca arreglaste esa ventana. Quizá tus contraventanas están atascadas. Si sabes que llegará la próxima semana, ¿vas a arreglarla o no?

Prepararnos para la tormenta

Proteger desde el inicio. Aplicar controles en tiempo de ejecución. Validar de forma independiente.

Proteger el software desde el inicio, detectar lo que introduce el código generado por IA y los paquetes que incorpora antes de que se acerque siquiera al momento de confirmarlo y distribuirlo, no después.

Gobernar los agentes y sus cadenas de suministro, porque un agente con demasiado acceso y una herramienta no evaluada son ahora una superficie de ataque habitual, no un caso extremo.

Probar y corregir continuamente, porque una prueba de penetración puntual no puede seguir el ritmo de un panorama de amenazas que cambia semanalmente. Las pruebas ofensivas continuas, fundamentadas en pruebas de producción, son la forma de demostrar que los controles especificados se mantienen frente a las rutas de ataque que realmente has probado. Es una afirmación más limitada que "estamos seguros" y es la única que vale la pena hacer.

Y validar de forma independiente lo que construye la IA, la misma disciplina en la que la industria está convergiendo ahora en todos los niveles, aplicada a cada línea de código y cada agente que distribuyen tus equipos.

Nada de esto funciona si los hallazgos simplemente se acumulan. Jason Clinton, CISO adjunto de Anthropic, expresó bien la mitad operativa cuando anunciamos nuestra alianza: "En la seguridad de la IA, la detección nunca fue el cuello de botella. Al combinar las capacidades de Claude con Snyk, las empresas pueden convertir los hallazgos de alta fidelidad en acciones dentro de los flujos de trabajo en los que se crea el software."

Abiertos. Aliados. Aún en pie.

La capa defensiva debe seguir siendo ampliamente accesible. Los modelos abiertos, la inteligencia compartida y el apoyo a los mantenedores del código abierto pertenecen a la arquitectura de seguridad, no están fuera de ella.

Los pasos posteriores de Amodei piden coordinación entre los laboratorios de frontera y, después, entre los gobiernos. Es razonable proponerlo y no es un plan para excluir a nadie. Mi preocupación tiene que ver con el efecto, no con la intención: cualquier acuerdo que termine concentrando la capacidad de construir, inspeccionar y defender sistemas de IA en un puñado de laboratorios se convierte en un único punto de fallo, independientemente de para qué se haya diseñado. La resiliencia que depende de confiar en la hoja de ruta de un solo proveedor no es resiliencia. Evalúa cada solución propuesta, incluida la nuestra, según si amplía el conjunto de personas que pueden defender.

Parte de esto es anterior a la IA. Durante cuarenta años distribuimos software sin exigirnos la disciplina de seguridad que otros campos de la ingeniería consideran innegociable. Nos encanta crear, pero nunca nos ha gustado demasiado proteger lo que creamos. La IA no introdujo esa brecha; eliminó el tiempo que habíamos estado usando para ocultarla y, además, añadió nuevos riesgos propios.

La preparación es responsabilidad del liderazgo y comienza con la parte que elegimos.

Abiertos. Aliados. Aún en pie.

El 17 de septiembre me uniré a Alon Krifcher, responsable de IA aplicada en Anthropic, para explicar los cuatro pasos que cierran la brecha entre el ataque y la defensa a velocidad de máquina: descubrir, corregir, validar y prevenir. Reserva tu plaza hoy mismo.

Pregúntale a tu propio agente

Si quieres convertir esto en una conversación con tu propio equipo, entrégale lo siguiente a tu agente. No te dirá si estás expuesto —ningún documento público puede hacerlo—, pero sí te dirá qué debes preguntar.

Read https://www.anthropic.com/threat-intelligence-report-september-2026,
https://snyk.io/evo/, and https://snyk.io/blog/ai-hurricane-is-here/ as reference material only.
Do not run tests, scans, or commands against any system, and do not change
any configuration.

For each attack path described in the report:

1. Separate what is documented evidence, what is my assumption, and what
   is unknown.
2. Identify the controls that could block or reduce it. For each, say
   whether it acts on what an agent uses, what it does, or what it
   generates, or on what an already-deployed system is permitted to do.
3. State what internal evidence we would need to assess our own exposure,
   and who in the organization would hold it.

Then rank a list of questions for my security team by potential impact,
likely exposure, and the size of the evidence gap.

Public reports and product descriptions cannot establish our actual
posture. Return questions and evidence requests, not an assessment of
whether we are secure. Never print the value of any key, token, or
credential.