All Articles
6 minUpdated

Claude AI, Yemen y la nueva carrera armamentista de la IA: cómo los agentes de código entran en los conflictos modernos

Most RecentTrendingSeguridad IA

Inteligencia de amenazas · 12 de septiembre de 2026

La guerra se mudó a la ventana de chat

Una célula armamentista del norte de Yemen llevó tres programas de misiles a través de un asistente de código. Los rechazos del modelo no terminaron la historia, solo cambiaron el recorrido.

El 11 de septiembre de 2026 Anthropic publicó un informe de inteligencia de amenazas que cubre de diciembre de 2025 a agosto de 2026. La mayor parte de la cobertura fue para los grupos de ransomware. El caso que más importa ocupa cuatro párrafos y ocurre en Yemen.

Una célula de desarrollo de armas en el norte de Yemen, bajo control hutí, usó Claude para desarrollar software de guiado, navegación y control de vehículos aéreos. No es un experimento mental. Tres programas simultáneos:

Programa 1 Un cohete guiado con una computadora de vuelo de gama telefónica y guiado autónomo hacia el blanco.
Programa 2 Un misil balístico de varias etapas con alcance previsto de más de 2.000 kilómetros.
Programa 3 Un sistema de misiles con varias variantes, incluido un vehículo planeador hipersónico.

No trabajaron en un solo chat. Ejecutaron varias instancias en paralelo y repartieron el trabajo: una para código, otra para investigación, otra para revisión. Cualquier ingeniero que haya montado una tubería multiagente reconoce esa forma al instante, porque es la misma con la que sacamos un producto SaaS en un fin de semana.

Después probaron el cohete guiado en el terreno y falló. Según el informe, en cuestión de horas los operadores estaban de vuelta frente al modelo averiguando por qué. Ese detalle es el artículo entero. El bucle de depuración que hace productivo a un desarrollador junior convierte una prueba fallida en una revisión.

Qué cruzó realmente la restricción

Anthropic bloqueó las cuentas y afirma que no hay pruebas de que se haya desplegado un dispositivo operativo. También admite, sin rodeos, que no todos los intentos de bloquear las solicitudes tuvieron éxito y que la célula ya había construido un conjunto de simulación fuera de línea que no dependía de Claude.

Se imagina el fallo de una protección como una frase mágica que desbloquea una respuesta prohibida. En los casos documentados nunca es así. Es arquitectura. Se repiten cuatro patrones, y cada uno es una decisión de diseño de sistemas, no un prompt ingenioso:

Las cuatro superficies de fallo

1. Descomposición. Un rechazo se dispara con la intención, y la intención vive en la tarea completa, no en las piezas. Un lazo de control, un filtro de Kalman, un driver de actuador y una transformación de coordenadas son problemas de ingeniería corrientes por separado. El ensamblaje ocurre en el portátil del operador, donde ningún clasificador mira.

2. Doble uso. Guiado, navegación y control es un temario universitario. Las matemáticas de un vehículo volador estabilizado son las de un dron de reparto. Un modelo no lee el sitio de lanzamiento en una ecuación diferencial.

3. Transferencia de capacidad fuera de línea. Es lo que más se subestima. Una vez que el modelo ayudó a construir el simulador, el banco de pruebas y la cadena de herramientas, el modelo pasa a ser opcional. La capacidad ya salió de la plataforma y bloquear la cuenta no la devuelve.

4. Acceso prestado. En otras partes del mismo informe, varios grupos recolectaron claves API de aplicaciones móviles, imágenes Docker y repositorios públicos, y luego operaron con la cuenta de otro. Un equipo escaneó 1,8 millones de APK en busca de secretos incrustados. Otro golpeó a unas 30 empresas de IA en cuatro días inyectando instrucciones en entornos automáticos de evaluación para extraer claves de producción.

Relea el último punto, porque ese aterriza en su escritorio y no en el de un equipo de políticas. La protección nunca se cruzó en el modelo. Se cruzó en la clave. Y la clave estaba dentro de un APK publicado por un desarrollador con prisa.

El resto del informe es un problema de desarrolladores

Caso Papel de la IA Escala
Espionaje estatal ruso Desarrollo automatizado de malware y reescritura de cargas al ser detectadas 20+ organizaciones, 300.000+ registros de identidad
Colectivo criminal Escaneo masivo de secretos y compromiso de cadena de suministro en horas 1,8 M de apps escaneadas, más de 1 TB robado
Taller de exploits Enjambres de agentes autónomos para reconocimiento y análisis binario ~50 objetivos, flota de 13 agentes
Hacktivista individual Construyó solo una plataforma completa de doxxing con tuberías de ingesta 14 objetivos vulnerados, 12 a 26 GB

Una sola persona construyó una plataforma de ataque masivo. La distancia entre un servicio de inteligencia estatal y un individuo motivado con una clave API es hoy sobre todo una diferencia de paciencia, no de capacidad.

Qué hago yo al construir sistemas con agentes

Las claves nunca viven en el cliente

Ninguna clave de modelo en un bundle móvil, un build de front, una capa de Docker o un repositorio. Cada llamada pasa por una ruta de servidor. Tokens de vida corta, rotación programada y alertas de gasto anómalo, porque una clave robada aparece antes en la factura que en la brecha.

Todo documento recuperado es entrada hostil

Los ataques a los entornos de evaluación funcionaron por inyección: instrucciones ocultas en contenido que un sistema automático leyó y obedeció. Si su agente lee un PDF, una web, un ticket o un pull request, ese texto es dato no confiable y nunca entra en el canal de instrucciones.

Limite las herramientas, no el prompt

Un prompt es una sugerencia. Una herramienta que solo lee tres tablas y escribe en una cola es una restricción real. Los límites de capacidad viven en la capa de herramientas, con lista blanca de salida para que un agente comprometido no pueda llamar a casa.

Aprobación humana en acciones irreversibles

Pagos, borrados, despliegues, mensajes a clientes. El agente propone, una persona aprueba. La ventaja de la célula yemení era un bucle sin fricción. La fricción es una función cuando la acción no se puede deshacer.

Registre la trayectoria completa

Prompt, llamadas a herramientas, argumentos, resultados, coste e identidad de sesión. Si no puede reconstruir qué hizo su agente el martes pasado, no puede responder a un cliente ni a un regulador.

La dirección del informe es una sola: menos supervisión humana, más autonomía, menor coste por objetivo. Cuando atacar un objetivo marginal se abarata, cada pequeña empresa se vuelve objetivo, y esa empresa suele tener un sitio hecho barato y nunca actualizado.

No escribo esto como analista de políticas, sino como alguien que entrega código a clientes y lee informes de incidentes para saber cómo serán los próximos doce meses de ataques. Los proveedores seguirán endureciendo el modelo, esa es su capa. Su capa es la clave, la herramienta, la regla de salida y el registro de auditoría.

¿Está construyendo algo con un agente dentro?

Soy Zubair Hussain Shah, desarrollador full-stack en Next.js, React y Node. Construyo aplicaciones web, plataformas de e-commerce y funciones de IA, y endurezco la capa de agentes: claves en servidor, herramientas acotadas, recuperación resistente a inyección y trazas de auditoría.

Ver mi trabajo y contratarme →

Fuentes y lecturas

  1. Anthropic, Countering misuse of AI: September 2026.
  2. Anthropic, Threat Intelligence.
  3. Arab News, Yemen's Houthis used Claude AI to build guided weapons.
  4. The New Arab, Anthropic report exposes AI misuse across the MENA region.
  5. OWASP, Top 10 for LLM Applications.
  6. MITRE, ATLAS.
  7. NIST, AI Risk Management Framework.

Por Zubair Hussain Shah. Más artículos en el blog y en GitHub.

Claude AI y Yemen: cómo los agentes de código entraron en la carrera armamentista de la IA (2026) | Zubair Hussain