El huracán de la IA ha llegado

Durante el último año, he descrito esto como una niebla de IA: afirmaciones contradictorias, riesgos inciertos y líderes con dificultades para ver qué importaba. Ahora los vientos se han intensificado. 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.

Solíamos llamarlo niebla. La niebla llega y se va.

He dicho durante el último año que la creación pasó a la 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 la cadencia. 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. Ese clima no se puede esperar a que pase.

Todo se reduce a tres problemas: ataques automatizados que avanzan más rápido de lo que un trabajo pendiente a velocidad humana puede absorber, desarrollo agéntico que escribe código y accede a herramientas que nadie ha verificado, y aplicaciones de IA ejecutándose en producción sin inventario, sin políticas y sin 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 se vuelve más estridente: 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 impulso de desconectarse y tratarlo como ruido.

No lo hagas. Esto es diferente.

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

El escrutinio independiente es el argumento ahora

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 diferentes sobre la supervisión y el 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 réplica del profesional: regular el ritmo de lo que viene no protege lo que ya está implementado. Su lectura es que el tiempo 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, con controles aplicados en tiempo real y pruebas en lugar de promesas: responsabilidad a nivel del consejo, red teaming independiente, divulgación de incidentes y controles que funcionen en producción.

El argumento de George sobre el tiempo de ejecución es esencial. Yo lo extendería al desarrollo: gobernar 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 en tiempo de ejecución limitan lo que pueden hacer los sistemas implementados.

De lo contrario, estaremos generando la exposición de 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 solución no puede ser su único validador.

Tres puntos de partida distintos: un laboratorio de frontera, un defensor del tiempo 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 puede darse por sentado. La afirmación arquitectónica que hacemos más allá de ese punto es que el sistema que crea un cambio no debe ser su único validador. Cuando quienes más tienen que ganar diciendo "confíen en nosotros" optan por decir "verifíquennos", eso no es un eslogan; es confirmación.

La independencia aquí es una propiedad técnica, no de marca. Significa que la evidencia la genera algo que el agente productor no puede alterar y que se comprueba 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 juicio, solicitado dos veces.

La evidencia ya no es hipotética

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. Preferiría haberme 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 utilizando estas herramientas deliberadamente y a escala.

El informe de septiembre de Anthropic documenta a GTG-20006, un actor de espionaje vinculado al Estado ruso según la atribución de Anthropic, ejecutando un flujo de trabajo asistido por IA que identificó, modificó, reconstruyó y volvió a desplegar sus propios implantes después de que los productos de seguridad los detectaran. El malware no evolucionó por sí solo: un 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 motivado financieramente 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 al atacante tres cosas a la vez: escala, capacidad de cómputo ajena 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 y presente.

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

Prepararse 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 a confirmarse y distribuirse, no después.

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

Probar y remediar 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 evidencia de producción, son la forma de demostrar que los controles especificados resisten 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 hacia la que converge ahora el sector en cada capa, 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, Deputy CISO de Anthropic, expresó bien la parte 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 donde 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 deben formar parte de la arquitectura de seguridad, no quedar 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 en un puñado de laboratorios la capacidad de construir, inspeccionar y defender sistemas de IA se convierte en un único punto de fallo, independientemente de para qué se diseñó. 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 capaces de 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 usábamos para ocultarla y agregó nuevos riesgos propios.

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

Abiertos. Aliados. Aún en pie.

El 17 de septiembre me uniré a Alon Krifcher, Head of Applied AI de Anthropic, para explicar los cuatro pasos que cierran la brecha entre los ataques y la defensa a velocidad de máquina: descubrir, remediar, validar y prevenir. Reserva tu plaza hoy.

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