Fireworks AI: brecha expone chats de Notion AI

Un ataque a un proveedor de IA terminó exponiendo chats de Notion

Fireworks AI confirmó que un atacante vulneró a su proveedor de nube para llegar a un sistema de desarrollo de la compañía y acceder a datos de clientes. Uno de los afectados confirmados es Notion, que reportó que la brecha alcanzó a alrededor del 1% de sus clientes e incluyó transcripciones de chats de Notion AI.

Para cualquier founder que construye sobre APIs de terceros, la lección es incómoda: tu perímetro de seguridad termina donde empieza el de tu proveedor. Y en IA, ese proveedor casi nunca está solo: tiene a su vez un cloud, un equipo de I+D y un conjunto de credenciales que, si caen, arrastran los datos de todos los que están encima.

¿Qué pasó en el ataque a Fireworks AI?

Fireworks AI es la plataforma que usan los desarrolladores para acceder y ejecutar modelos de IA abiertos sin montar su propia infraestructura de GPU. Según TechCrunch, la compañía asegura tener decenas de miles de clientes en el mundo, entre ellos la firma de legal tech Harvey y la empresa de IA Cursor.

Leíste lo que hace la IA. ¿Y en tu negocio?

Un agente de IA puede quedarse con parte de tu día: ordenar lo pendiente y pedirte el OK antes de actuar. El Kit «tu mano derecha con IA» trae un video de 11 minutos y una ficha para dejar al tuyo trabajando. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

El vector del ataque no fue la plataforma de producción, sino un eslabón anterior. De acuerdo con el boletín de seguridad de la compañía recogido por The Hacker News, un proveedor de nube externo que alojaba las máquinas de investigación y desarrollo de Fireworks sufrió un incidente el 23 de octubre. Al día siguiente, el tercero no autorizado usó ese acceso para llegar a las máquinas de desarrollo de Fireworks y ejecutar una carga de trabajo no autorizada que derivó en el impacto sobre datos de clientes.

Fireworks detectó la actividad ese mismo día, cerró las vulnerabilidades críticas conocidas y afirmó que, al 25 de octubre, no había detectado evidencia adicional de acceso exitoso sobre la plataforma que usan sus clientes. La investigación sigue abierta.

Dos brechas en cinco semanas

El detalle que más debería preocupar a un equipo de producto es que este no fue un evento aislado. Yahoo Finance describe dos intrusiones conocidas en aproximadamente cinco semanas.

La primera se detectó el 6 de octubre y se notificó en un aviso publicado el 10 de octubre. En ese caso, según The Hacker News, el atacante usó credenciales internas de Fireworks para acceder a variables de entorno —incluidas claves de API y tokens guardados como secretos— dentro de trabajos de evaluación en un número limitado de cuentas de clientes. En ese momento la compañía sostuvo que no había evidencia de acceso a modelos, datasets, datos de entrenamiento, información personal ni tráfico de inferencia.

La segunda brecha entró por otro camino: no por credenciales internas, sino por el entorno de un proveedor externo antes de alcanzar la infraestructura de desarrollo. Es decir, el mismo proveedor fue atacado dos veces con métodos distintos en poco más de un mes.

¿Qué datos se llevaron exactamente?

Según el boletín de Fireworks reportado por The Hacker News y BleepingComputer, el acceso incluyó:

Metadatos de recursos: identificadores de recursos de Fireworks, nombres visibles, descripciones y fecha de creación.
Información de facturación: direcciones de facturación y envío, historial de facturas y pagos, saldo de la cuenta y consumo de créditos.
Secretos, datasets y pesos de modelo incompletos para un conjunto limitado de cuentas.

Dos matices importantes. Primero, Fireworks no almacena números de tarjeta, por lo que esos datos no se vieron afectados. Segundo, la compañía señaló que sus productos Inference, Training SDK y Nexus son de retención cero por defecto y no mostraron impacto detectado, según Yahoo Finance.

El dato más delicado viene de Bloomberg, que reportó que Fireworks comunicó el segundo incidente a sus clientes el 9 de noviembre y que, en algunos casos, decenas de miles de archivos contenían datos de clientes. Bloomberg también confirmó que la compañía está trabajando con clientes afectados, incluidos Notion y Cursor.

El caso Notion: qué se llevaron y cómo reaccionó

Notion se enteró por aviso de Fireworks. El 3 de noviembre desconectó sus sistemas del proveedor, borró los datos que tenía almacenados allí y cortó toda conectividad entre ambos, según su propia divulgación citada por TechCrunch.

Esta semana la compañía confirmó que los atacantes se llevaron transcripciones de chat de clientes de Notion AI que usaban la función Insights. La definición que dio Notion es literal y vale la pena leerla con atención: la transcripción incluye cualquier entrada o salida del modelo que se haya escrito en el chat. Es decir, no solo las preguntas del usuario, también las respuestas generadas.

Dos alivios parciales: buena parte de esos datos era no atribuible —no estaban etiquetados con quién los escribió ni de qué espacio de trabajo venían— y las transcripciones no contenían resultados de llamadas a herramientas. Notion desactivó la función Insights mientras investiga y dejó de servir modelos de pesos abiertos a través de Fireworks.

La recomendación de Notion a los afectados es concreta: si pegaste información sensible, contraseñas, claves de API u otras credenciales en un chat durante la ventana del ataque, rótalas de inmediato.

¿Qué es el LLMjacking y por qué es un negocio para los atacantes?

Fireworks sostiene que el grupo criminal detrás del ataque tiene motivación financiera y un objetivo específico: vender tokens obtenidos del acceso no autorizado a modelos de lenguaje a gateways de enrutamiento ilícitos. El comprador consume capacidad de cómputo de IA sin pagar por ella, y la factura la termina pagando el dueño legítimo de las credenciales.

Ese modelo tiene nombre: LLMjacking. BleepingComputer recoge que investigadores de Google Threat Intelligence Group y Mandiant reportaron que estos ataques pueden generar costos de hasta US$1 millón por llamadas fraudulentas hechas con claves de API robadas. The Hacker News añade que Google advirtió que los actores de amenaza están apuntando cada vez más a infraestructura de IA en Norteamérica, Sudamérica y Asia-Pacífico, en sectores como servicios financieros, retail, tecnología y transporte.

La consecuencia práctica: en este tipo de incidentes hay dos daños simultáneos. Uno es la fuga de datos. El otro es la factura de inferencia que alguien más está consumiendo con tus claves.

Por qué esto importa más allá de Fireworks

El caso expone algo estructural de la economía del software con IA. Un producto como Notion no construye sus modelos: los consume. Y para consumirlos contrata a un proveedor, que a su vez depende de un cloud, que a su vez aloja máquinas de desarrollo con credenciales. Cada capa agrega velocidad de salida al mercado y agrega también un punto de fallo que no controlas.

Hay un segundo riesgo que suele pasarse por alto: los pesos de modelo y datasets. Cuando un proveedor de inferencia aloja modelos ajustados o datos propietarios de un cliente, una brecha deja de ser un problema de privacidad y se convierte en un problema de propiedad intelectual. Para una startup que entrenó un modelo vertical con datos propios, eso puede ser el activo completo.

Y un tercer punto, el más incómodo: el atacante no necesitaba comprometer a Notion. Le bastó comprometer a un proveedor de un proveedor.

¿Qué significa esto para tu startup?

1. Haz el inventario de qué datos le entregas a cada proveedor de IA. No todo lo que mandas a un endpoint de inferencia es igual. Separa en tres columnas: datos públicos, datos de negocio y datos sensibles (PII, secretos, credenciales, código propietario). Si en la tercera columna hay algo, exige retención cero por contrato y verifica que sea real, no solo una línea en la documentación.

2. Revisa qué dice tu contrato sobre notificación de incidentes. En este caso, el incidente en el cloud ocurrió el 23 de octubre y la comunicación a clientes llegó el 9 de noviembre, según Bloomberg. Pregúntate cuánto tardaría tu proveedor en avisarte y qué obligación tiene de hacerlo. Si la respuesta no está escrita con un plazo en horas, no existe.

3. Trata a tu proveedor de IA como un subencargado, porque lo es. Si tu producto procesa datos personales de usuarios europeos o latinoamericanos, el cloud que usa tu proveedor de inferencia también los procesa. Necesitas que esté declarado en tu cadena de encargados y cubierto por tus acuerdos de tratamiento de datos.

4. Rota claves y pon límites de gasto hoy. El vector de la primera brecha fueron claves de API y tokens en variables de entorno. Usa claves separadas por entorno, con el mínimo privilegio posible, límites de consumo y alertas de gasto anómalo. El LLMjacking se detecta primero en la factura, no en el log.

5. Diseña una salida de emergencia. Notion cortó la conexión y borró los datos en cuestión de días. Pregúntate si tú podrías cambiar de proveedor de inferencia sin reescribir tu producto. Una capa de abstracción sobre el modelo —aunque sea mínima— es la diferencia entre una migración de una semana y un trimestre perdido.

6. Filtra antes de enviar, no después. Si tu producto permite pegar texto libre en un chat con IA, asume que ese texto puede terminar en un dataset de un tercero. Un filtro básico de secretos y credenciales en el cliente evita el escenario que Notion tuvo que advertir a sus usuarios.

Conclusión

Fireworks AI hizo lo que se espera de un proveedor comprometido: aisló sistemas, revocó credenciales, contrató a Palo Alto Networks’ Unit 42 para el análisis forense y notificó a los clientes afectados. Pero la lección para el ecosistema no está en la respuesta, está en la arquitectura.

La IA como servicio comprimió el tiempo de lanzamiento de miles de startups y, con él, comprimió también la distancia entre el error de seguridad de un tercero y la confianza de tus usuarios. La pregunta que cada founder debería hacerse esta semana no es si su proveedor de inferencia es bueno, sino qué pasaría con su producto si mañana ese proveedor aparece en las noticias.