El 30 de octubre, a las 11:43 UTC, un equipo de seguridad en la nube envió una advertencia a Northflank. Un minuto después, los ingenieros de Northflank la abrieron. Para las 13:05 UTC ya habían aplicado dos parches más.
El mensaje público que la plataforma dirigió a sus clientes ese día tenía once palabras, y es una de las frases más honestas de la respuesta a incidentes moderna: "Asuman que todas las variables de entorno fueron descifradas. Desactiven y roten todas las llaves."
Northflank es una plataforma de hosting para desarrolladores. Subes contenedores, bases de datos y aplicaciones de IA, y ella las ejecuta. Eso significa que, por diseño, también guardaba una copia de casi todo lo que te quitaría el sueño: contraseñas de bases de datos, credenciales de nube, claves de pasarelas de pago, llaves privadas y las claves de API de proveedores de IA que alimentan cada agente, chatbot y copiloto que has lanzado este año.
Los clientes empezaron a reportar uso no autorizado de esas claves de IA casi de inmediato.
Esto no es la historia de una mala semana de una empresa. Es la historia de toda una categoría aprendiendo, a gran velocidad, que su activo más valioso es una cadena de caracteres dentro de una variable de entorno.
Lo que Northflank dijo realmente
La cronología es inusualmente detallada y vale la pena leerla con calma.
- 30 oct, 11:43 UTC — Wiz alerta a Northflank sobre actividad sospechosa.
- 11:44 UTC — los ingenieros la revisan.
- 12:50 y 13:05 UTC — parches adicionales de políticas de red.
- Poco después — se avisa a los clientes asumir variables descifradas y rotar todo.
En sus actualizaciones del incidente, Northflank afirma que el vector de ataque quedó contenido en una hora desde la primera alerta, que las cargas de trabajo en ejecución no se vieron afectadas, que no se accedió a datos de cargas y que la actividad se centró en secretos del plano de control. Los clientes con planos de control desplegados en su propio entorno o dedicados no se vieron afectados. La empresa también corrigió CVE-2026-98432 en toda su flota, rotó sus propias llaves y revocó tokens de acceso, sesiones, integraciones de control de versiones y roles IAM entre cuentas cuando pudo hacerlo en nombre de sus clientes.
Lo que no ha dicho: cómo entraron los atacantes, cuántos clientes se vieron afectados o si algo más allá de las claves de IA fue abusado. Promete un análisis de causa raíz.
Ese vacío es exactamente donde vive el resto de la historia.
Nueve plataformas, un patrón
Wiz reunió las divulgaciones del mes bajo un título deliberadamente sombrío: "Octubre Negro para las plataformas para desarrolladores de IA". Al menos nueve plataformas reportaron incidentes en octubre: Fireworks AI, Andromeda, Zeabur, Lightning AI, OpenCode, Railway, Warp, CommandCode y Northflank. Días después la lista creció con Brev (NVIDIA), Trigger.dev y Chainstack.
Las causas raíz difieren: Railway apunta a una escalada de privilegios en su infraestructura de build, Warp a la dependencia de un proveedor externo, OpenCode a un sistema heredado. Fireworks, Zeabur y Lightning atribuyen sus incidentes al acceso a credenciales.
Pero un detalle se repite en casi todos los informes: los atacantes buscaban variables de entorno almacenadas, y en particular las que dan acceso a modelos de IA.
El informe de Zeabur fue lo bastante detallado como para que la empresa anunciara que cerrará. Railway publicó un informe preliminar. Para el resto, los detalles técnicos siguen pendientes, y mucho del comentario ha tratado cada incidente como un mal día aislado.
No son aislados. Son un mercado.
La economía de una clave de IA robada
Aquí está la parte que casi todos los informes omiten, y es la que debería preocuparte.
Una contraseña de base de datos robada hay que usarla con cuidado, puertas adentro, donde el ruido es bajo. Una clave de API de IA robada puede gastarse desde cualquier lugar, en volumen ilimitado, y el medidor corre a tu nombre.
Wiz rastreó dos claves empresariales usadas desde dentro de infraestructura comprometida de proveedores. Ambas fueron probadas por primera vez en 30 minutos desde el acceso a credenciales reportado: una sola invocación de modelo desde una IP residencial, barriendo las claves de varias organizaciones en un minuto.
Después se abrió el grifo.
- Caso A: unas 800.000 llamadas a Amazon Bedrock en treinta horas, cerca del 90% exitosas, primero desde una dirección residencial y luego durante la noche desde un proveedor de hosting.
- Caso B: unas 1,7 millones de llamadas a Bedrock en trece horas desde una única dirección de hosting, más de un millón exitosas.
A precio de lista, esas dos claves probablemente generaron más de 100.000 dólares de consumo. El perfil de tokens parecía tráfico revendido de agentes de código: entradas pequeñas sin caché, unos cientos de tokens de salida, más una cola larga de prompts enormes compatible con muchos usuarios finales detrás de un revendedor.
Y aquí llegamos a por qué esto sigue pasando. Wiz identificó infraestructura ligada a operaciones abiertas de reventa de LLM, que anuncian acceso con descuento a modelos frontera con pagos en USDT. Una clave robada un lunes puede ser una línea de producto el viernes. Hay demanda, hay precios y hay canal. El robo es monetizable, así que el robo continúa.
Por qué esto es peor para quien construye IA de lo que parece
Tres cosas hacen que esta categoría sea distinta del riesgo de hosting normal.
1. El radio de impacto no es el servidor. Es la factura, los datos y la reputación. Una clave robada puede quemar seis cifras en un fin de semana, exfiltrar lo que tus prompts alcancen y producir salida con tu nombre que tu marca tendrá que asumir.
2. Las claves son identidades sintéticas, y casi ningún inventario las cuenta. Llevamos veinte años construyendo procesos para revisar cuentas humanas. Una clave de API que puede gastar dinero y llegar a datos de producción suele vivir en un panel que nadie audita, creada por alguien que ya cambió de equipo.
3. La rotación no es un clic, es un grafo. "Rotar todos los secretos" es una instrucción de una línea que se ramifica en secretos de integración, de proyecto, globales, cargas de trabajo, webhooks, runners de CI, conectores de terceros y el .env local de cada compañero. La mayoría de los equipos descubre la forma real de su grafo de credenciales durante un incidente, en el peor momento posible.
Qué hacer esta semana
No esperes el análisis de causa raíz de un proveedor del que nunca habías oído hablar. Haz esto ahora.
- Inventaría cada clave de proveedor de IA que posees. OpenAI, Anthropic, Bedrock, Google, Cohere, las pequeñas también. Anota quién la creó, a qué llega, quién la paga y cuándo se rotó por última vez.
- Ponle un techo a cada clave. Claves separadas por entorno, por aplicación y por equipo. Fija límites de gasto duros con tu proveedor y alarmas al 50% del presupuesto. Una factura atípica es una señal de detección, y hoy la mayoría de los equipos la tiene apagada.
- Haz que revocar sea aburrido. Un runbook de rotación que tarda un día es un runbook que nunca se ensayará. Automatiza el cambio y pruébalo un martes por la tarde, no durante un incidente.
- Vigila la forma del uso, no solo el volumen. Llamadas súbitas a modelos en otras regiones, catálogos de modelos sondeados para ver disponibilidad o una ráfaga de prompts sin caché desde un ASN desconocido se parecen mucho a alguien más usando tu cuenta.
- Trata el plano de control de tu hosting como un límite de confianza. Lo que tu PaaS o proveedor de hosting guarda, lo puede perder. Pregúntales si guardan secretos en texto plano, si soportan gestores de secretos externos y si pueden revocar tus integraciones por ti.
La conclusión para nuestros clientes
En aratech construimos sobre infraestructura gestionada porque permite que equipos pequeños se muevan como grandes. Ese intercambio sigue valiendo la pena. Pero no es gratis, y octubre acaba de mandarnos la factura.
La lección no es "deja de usar plataformas". Es que, en un stack nativo de IA, tus claves de API son el perímetro. No son configuración. Son lo que un atacante realmente quiere, son baratas de robar y ya hay un mercado cotizando precios por ellas.
Los equipos que salgan bien de esto serán los que puedan responder una pregunta sin abrir una hoja de cálculo: si nuestro proveedor de hosting llamara al mediodía y dijera "asuman que todo fue descifrado", ¿qué exactamente tendríamos que rotar y cuánto tardaríamos?
Si la respuesta es "horas, y lo hemos practicado", estás bien. Si es "tendría que preguntarle a tres personas", hoy es un buen día para arreglarlo.