Claves de API robadas: el riesgo olvidado de los proyectos de IA

Una clave de API es una tarjeta de acceso que un programa presenta a un servicio para ser atendido, y facturado. En un proyecto de IA, estas tarjetas se multiplican rápido: una por proveedor de modelos, una por automatización, una para el prototipo de la semana pasada que sigue funcionando. Cada una abre un contador que paga la empresa. Robada, abre el mismo contador a otra persona.

Este texto de nuestra sección Infraestructura y nube aborda este riesgo desde el ángulo que molesta a las direcciones financieras: la factura. Dónde se filtran las claves en un proyecto de IA, lo que puede costar una clave robada, cómo limitar los daños incluso antes de la filtración y qué hacer en la primera hora.

En resumen

• Las claves de servicios de IA expuestas públicamente se dispararon un 81 % en un año, según GitGuardian.
• Una clave robada sirve para consumir modelos a su costa, e incluso para revender el acceso: se habla de LLMjacking.
• Una clave por uso, permisos restringidos y un límite de gasto convierten una filtración costosa en un incidente acotado.
• Una clave que ha sido visible en algún sitio se considera perdida: se revoca, se sustituye y se comprueba para qué se ha usado.
• La mejor clave es la que ni el código, ni el navegador, ni el modelo ven nunca.

Por qué los proyectos de IA multiplican las claves expuestas

Porque van rápido y apilan servicios. Un asistente interno llama a un modelo, a un buscador en sus documentos, a una herramienta de automatización; cada pieza pide su clave, y el prototipo que debía durar una semana pasa a producción con la clave pegada donde sacaba del apuro.

El último informe de GitGuardian sobre la dispersión de secretos mide la magnitud del fenómeno:

La última cifra es la más inquietante: una clave filtrada casi nunca se cambia. Sigue siendo utilizable durante años por quien la haya obtenido.

Lo que cuesta de verdad una clave robada

Una clave de correo robada expone datos. Una clave de modelo de IA robada expone también un presupuesto. En mayo de 2024, el equipo de investigación de Sysdig describió un ataque bautizado LLMjacking: unas credenciales de nube robadas, a través de una vulnerabilidad de un sitio no actualizado, servían para usar modelos alojados y revender el acceso, a costa de la víctima. En el peor caso calculado por Sysdig, el consumo superaba los 46 000 dólares al día.

OWASP, la fundación de referencia en seguridad de aplicaciones, clasifica este riesgo en su ranking 2025 de riesgos de las aplicaciones de IA con el nombre de consumo ilimitado, y le da un apodo elocuente:

La defensa que recomienda OWASP no tiene nada de exótico: límites de peticiones, cuotas por usuario y una supervisión que alerte de un consumo inusual. Dicho de otro modo, límites fijados antes del incidente.

Dónde se filtran las claves en un proyecto de IA

Cuatro lugares aparecen una y otra vez.

• El código enviado al navegador o a la aplicación móvil. Un prototipo llama al modelo directamente desde la página: la clave viaja con él, legible por cualquier visitante. Google lo dice sin rodeos en sus buenas prácticas sobre las claves de API: nunca una clave en el código del cliente ni en un repositorio de código, es el servidor quien la añade a la petición.
• El repositorio de código, historial incluido: quitar la clave del archivo no la borra de las versiones anteriores.
• Las herramientas de colaboración: mensajerías, tickets, documentos compartidos. GitGuardian estima que el 28 % de las filtraciones se producen únicamente fuera de los repositorios de código.
• Las instrucciones y los documentos que se dan a un modelo: una clave que lee un agente de IA es una clave que puede repetir. Nuestro artículo sobre la caja fuerte de secretos detalla cómo un agente puede usarla sin verla nunca.

Limitar los daños antes de la filtración

Nunca se puede garantizar que una clave no se filtre. En cambio, sí se puede decidir de antemano lo que permitirá hacer el día que se filtre.

En concreto:

• Una clave por uso. El día que una se filtra, se corta sin detener los demás proyectos, y el registro dice enseguida cuál está afectado.
• Restricciones en cada clave. En Google Cloud, por ejemplo, una clave puede limitarse a ciertos servicios o a ciertas aplicaciones, y Google lo resume así: una clave restringida reduce el impacto de una clave comprometida. Compruebe lo que permite cada uno de sus proveedores.
• Límites y alertas. Un presupuesto por uso, una alerta al 50 o al 80 % de ese presupuesto y una parada automática al alcanzar el límite cuando el proveedor lo ofrece. Nuestro artículo sobre la factura de la IA, los tokens y el enrutamiento explica cómo prever ese presupuesto uso por uso.
• La limpieza periódica. Las claves que ya nada utiliza se eliminan, y las demás se renuevan a intervalos regulares.
• La detección en origen. Desde febrero de 2024, GitHub bloquea por defecto el envío de secretos reconocidos a los repositorios públicos; GitHub decía entonces haber detectado más de un millón de secretos divulgados en repositorios públicos en las ocho primeras semanas del año.

Los permisos de un agente, por su parte, se recortan como los de un empleado: nuestra guía sobre la gobernanza de la IA en la empresa detalla ese recorte.

La primera hora tras una filtración

Cuando una clave se ha visto donde no debía estar, la cuestión no es saber si alguien la ha obtenido. Se actúa como si así fuera.

El orden importa: revocar primero, aunque un servicio se detenga unos minutos. Una clave todavía válida mientras se busca cómo sustituirla limpiamente sigue costando. Si con la clave se han podido leer datos personales, se plantea también la cuestión de una notificación a la autoridad de protección de datos competente (la CNIL en Francia), en el plazo de 72 horas que el RGPD prevé en caso de violación de datos personales.

Por dónde empezar

1. 01Haga una lista de sus claves de IA

   Proveedor, uso, persona responsable, fecha de creación.

2. 02Elimine las que ya nada utiliza

   Y cambie las que han circulado por mensajería o en el código.

3. 03Separe los usos

   Una clave por proyecto o por agente, con solo sus permisos.

4. 04Fije un límite y una alerta

   En cada cuenta de proveedor de modelos.

5. 05Escriba el procedimiento de la primera hora

   Con el nombre de quien tiene derecho a revocar.

Las claves de los programas corresponden a una caja fuerte de secretos; las contraseñas de las personas, a un gestor de contraseñas de equipo. Ambos forman parte de la base de infraestructura común a sus proyectos. El resto de la sección cubre las decisiones cercanas: las cinco partidas que inflan una factura de nube, servidor dedicado, VPS o nube, Kubernetes y las pymes, la supervisión, el plan de recuperación ante desastres, NIS2 en Francia, las copias de seguridad de un servidor propio, n8n autoalojado en producción, las herramientas que conviene sacar primero del SaaS, el coste de una salida del SaaS a tres años, la migración a la nube sin romperlo todo, la dependencia de la nube estadounidense, el hardware para hacer funcionar un modelo de IA en casa, Postgres gestionado o propio y la elección de un correo de empresa.

Para una caja fuerte a su nombre que sus IA usan sin ver las claves, consulte nuestra Caja fuerte IA; para límites por uso y un presupuesto seguido, la IA a su justo coste; para alojar estas herramientas en su casa, nuestra oferta de salida del SaaS.

Preguntas frecuentes

Fuentes

1. Sysdig, LLMjacking: Stolen Cloud Credentials Used in New AI Attack, mayo de 2024 (nueva pestaña)sysdig.com
2. OWASP, LLM10:2025 Unbounded Consumption (nueva pestaña)genai.owasp.org
3. Google Cloud, Best practices for managing API keys (nueva pestaña)docs.cloud.google.com
4. GitHub, Keeping secrets out of public repositories, febrero de 2024 (nueva pestaña)github.blog
5. CNIL, contraseñas: una nueva recomendación, octubre de 2022 (nueva pestaña)cnil.fr