Claves de API de LLM expuestas: playbook de respuesta (2026)

Las claves de API de IA y de LLM son ya un objetivo principal de los atacantes. El incidente confirmado de Railway de octubre de 2026 fue a por claves de proveedores de IA, y un anuncio clandestino no verificado afirma vender una base de datos de usuarios y claves de OpenRouter. Se sostenga o no esa afirmación concreta, la respuesta es la misma, así que aquí tienes un playbook de respuesta a incidentes concreto para la sospecha de exposición de claves de API de LLM o de IA. Primero, los hechos, contados con honestidad.

Qué está confirmado y qué se alega

• Confirmado: en el incidente de seguridad de Railway del 21 de octubre de 2026, el intruso intentaba obtener claves de API de proveedores de IA (según se informa, para lanzar ataques de destilación de modelos), y Railway dice que trabajó con OpenRouter y otros proveedores para revocar las claves potencialmente comprometidas (The Hacker News).
• Alegado / sin verificar: un actor de amenazas afirma vender una base de datos de usuarios de OpenRouter (se afirma que de ~250.000 usuarios) y ~207.000 claves en el formato sk-or-v1, con campos de usuario y de clave. Esta afirmación no se ha verificado de forma independiente y OpenRouter no la ha confirmado (cobertura). Trátala como una acusación.

El objetivo de este artículo no es pronunciarse sobre el anuncio de venta. Es que se está cazando claves de IA, así que, si tienes alguna, da por hecho que la exposición es cuestión de tiempo y prepárate.

Por qué las claves de API de IA son un botín tan apetecible

Se convierten directamente en dinero y en capacidad: una clave robada gasta tu presupuesto de LLM y, según el informe de Railway, puede alimentar ataques de destilación que clonan el comportamiento de un modelo a tu costa. Suelen ser de larga duración y con exceso de permisos (sin caducidad, con un alcance amplio) y están dispersas por el código, los logs de CI, las imágenes y las plataformas de terceros, así que una integración comprometida filtra muchas. Es el problema de las identidades de máquina con otro disfraz: el de la IA.

El playbook de respuesta a incidentes

Seis fases. La contención va antes que el análisis forense: una integración rota diez minutos es mejor que horas de gasto del atacante.

1. Preparar (antes de que pase nada)

• Inventaría cada clave de IA o de LLM, dónde está y quién es su responsable.
• Pon a cada clave un tope duro de gasto y de tasa y el alcance más limitado que funcione.
• Escribe ahora el runbook de rotación para que la respuesta sea mecánica bajo presión.

2. Detectar y hacer el triaje

• Confirma la señal de exposición: una clave en un repositorio público, un aviso de brecha de un proveedor o socio, o un uso anómalo. La brecha de la consola de OpenCode, en la que pudieron quedar expuestas claves guardadas de OpenAI, Anthropic y Google, es un ejemplo de la señal de aviso de brecha.
• Descarga los logs de uso y de facturación por clave del proveedor: picos de gasto, IP o regiones desconocidas, modelos que no usas, llamadas fuera de horario.
• Clasifica el radio de impacto: a qué puede llegar esta clave y qué datos pasan por ella.

3. Contener (haz esto primero)

• Desactiva la clave de inmediato: en OpenRouter y proveedores similares, desactívala (no la borres) para conservar el historial de uso para la investigación.
• Emite una clave de sustitución, con alcance limitado y con tope, y despliégala en la integración.
• Baja o congela el tope de gasto de la cuenta mientras trabajas.

4. Erradicar

• Encuentra la exposición de origen (un secreto filtrado en el código o en el CI, búscalo; una plataforma de terceros comprometida; o una clave compartida en exceso) y ciérrala.
• Rota cualquier otro secreto que compartiera la misma vía de exposición (el radio de impacto del paso 2), no solo esa clave.

5. Recuperar

• Verifica que la clave nueva funciona y que la antigua está muerta (prueba una llamada con la clave revocada: debería fallar).
• Restablece los topes de gasto normales cuando la monitorización esté limpia.
• Concilia la factura: reclama o señala al proveedor cualquier gasto no autorizado.

6. Después del incidente

• Documéntalo: cronología, causa raíz, a qué podía llegar la clave y qué cambiaste.
• Convierte las correcciones puntuales en controles permanentes (claves de vida corta, gestor de secretos, topes, responsables).
• Ensáyalo: un simulacro de exposición de claves en el IR Playbook Lab convierte esta página en memoria muscular.

Haz que la próxima filtración no tenga consecuencias

De vida corta, con alcance limitado, con tope, con responsable y fuera del código: esa es toda la partida. Planifica la rotación con el Key Rotation Planner, construye el runbook completo en el Incident Response Plan Builder y, cuando una clave se filtre de verdad, trabájala con la herramienta de respuesta a credenciales filtradas →. Que se filtre una clave gobernada es una molestia; que se filtre una sin gobierno es un titular.

Preguntas frecuentes

¿Sufrió OpenRouter una brecha? No está confirmado: el anuncio de venta de claves es una afirmación no verificada de un actor de amenazas. El suceso confirmado es el incidente de Railway, en el que el objetivo eran las claves de IA.

¿Qué hago ahora? Rota las claves de IA que pudieran haber quedado expuestas (en OpenRouter, desactivar y luego crear una nueva), revisa los logs de uso y fija un tope de gasto duro.

¿El primer paso en cualquier incidente de exposición de claves? Contener primero: desactiva o rota la clave antes de investigar.

¿Cómo evito el próximo? Claves de vida corta, con alcance limitado, con tope y con responsable, guardadas en un gestor de secretos y nunca en el código ni en los logs de CI.