De clave de facturación a puerta de Gemini: el riesgo creciente de las API keys expuestas en Google Cloud

Hace poco tiempo, una investigación de seguridad sacó a la luz un fallo que revela cómo un elemento aparentemente inofensivo —las claves API de Google Cloud— puede convertirse en una puerta de entrada a funciones avanzadas de inteligencia artificial y, en consecuencia, a datos privados y facturas desorbitadas. El informe, publicado por Truffle Security, muestra que miles de esas claves estaban visibles en código cliente en páginas web y, por un cambio en la forma en que Google habilita sus APIs, empezaron a funcionar como credenciales para los endpoints de Gemini (la API Generative Language de Google).

Tradicionalmente, las claves con prefijo "AIza" se han usado principalmente como identificadores de proyecto para propósitos de facturación, por ejemplo para servicios como mapas embebidos. Truffle Security encontró cerca de 2.900 claves expuestas públicamente en JavaScript de sitios que las utilizaban abiertamente. Lo preocupante no es solo la exposición: es que cuando un proyecto activa la API de Gemini, esas claves dejan de ser meramente tokens de facturación y empiezan a autorizar llamadas a la API de generación de lenguaje sin que los desarrolladores lo adviertan.

El efecto práctico es fácil de explicar y difícil de mitigar después del hecho. Un atacante que raspe la web y recoja una de esas claves puede realizar peticiones a Gemini, consumir cuota de inferencia que se cobrará al propietario de la clave y, en algunos casos, acceder a contenidos privados a través de endpoints como /files y /cachedContents. Es decir, la misma clave que antes solo figuraba en facturas puede ahora permitir descargar archivos subidos o recuperar datos que se habían almacenado en caché.

Además, Truffle Security documentó que la creación de una clave API nueva en Google Cloud suele venir con una configuración por defecto muy permisiva: "Unrestricted", lo que significa que la clave queda asociada a cualquier API habilitada en el proyecto, incluida Gemini. El resultado, en palabras de los investigadores, es que muchas claves que se consideraban seguras porque se usaban solo para facturación pasaron a actuar como credenciales de Gemini y aparecieron en la superficie pública.

Este problema se magnifica cuando se considera el ecosistema móvil: la firma Quokka realizó un barrido de 250.000 aplicaciones Android y halló más de 35.000 claves únicas de Google incrustadas en esas apps. El panorama completo sugiere que no es un caso aislado sino un patrón de exposición masiva que, con la llegada de APIs de IA, cambia el perfil de riesgo de manera significativa.

Ante la difusión del informe, Google respondió que estaba trabajando con los investigadores para mitigar el problema y que había implementado medidas proactivas para detectar y bloquear claves filtradas que intenten acceder a la API de Gemini. Esa comunicación pública de Google puede consultarse junto a los detalles técnicos y recomendaciones en la documentación oficial de Google Cloud sobre claves API y en las páginas que describen su oferta generativa: el informe de Truffle Security, la entrada técnica de Quokka y la documentación de Google Cloud sobre autenticación y la API generativa (API keys y Generative AI).

No está claro si estas claves se han aprovechado de forma extensa en ataques dirigidos, pero ya han aparecido informes anecdóticos que muestran el potencial impacto económico: en Reddit circuló una publicación donde un usuario afirma haber recibido cargos de más de 80.000 dólares en 48 horas tras el robo de una clave de Google Cloud y uso de la API de Gemini. Aunque ese caso individual no ha sido verificado públicamente, ilustra el tipo de abuso que preocupa a la comunidad de seguridad (ver publicación en Reddit).

La lección aquí es doble. Por un lado, los riesgos asociados a las claves API son dinámicos: una pieza de infraestructura considerada de bajo riesgo puede volverse crítica cuando cambian los servicios vinculados al proyecto. Por otro lado, la higiene de seguridad básica —rotación de claves, restricciones por IP o por referrer, y evitar incluir claves en código cliente o repositorios públicos— deja de ser una recomendación y pasa a ser una necesidad urgente.

Si gestionas proyectos en Google Cloud, conviene que revises tus APIs y servicios ya activados y que identifiques claves que estén accesibles desde el cliente (JavaScript público, repositorios públicos o apps móviles). Prioriza la rotación de las claves más antiguas, que son las más propensas a haber sido desplegadas bajo prácticas previas menos estrictas. A su vez, limita su alcance aplicando restricciones sobre qué APIs pueden usarlas y desde qué orígenes se pueden invocar; la documentación de Google Cloud ofrece guías y controles para eso.

Más allá de acciones puntuales, este incidente subraya la necesidad de una vigilancia continua: escaneo de seguridad, detección de comportamientos anómalos en el uso de APIs y bloqueos automáticos cuando se detecta actividad sospechosa. Como señalan varios expertos, la adopción de la IA en infraestructuras cloud agrega vectores nuevos que no existían cuando muchas de estas claves se consideraron inofensivas, por lo que el enfoque de “configurar y olvidar” ya no funciona.

En resumen, lo que parecía un token de facturación puede hoy ser la llave de una API que procesa prompts, almacena resultados y da acceso a contenidos. Revisar proyectos, aplicar restricciones de uso, rotar y eliminar claves expuestas y monitorizar patrones de consumo son pasos imprescindibles para reducir la superficie de ataque. Para quien necesite empezar ya, tanto el análisis de Truffle Security como el de Quokka y la documentación oficial de Google ofrecen puntos de partida claros y técnicos para entender el alcance y poner remedio: Truffle Security, Quokka y documentación de Google Cloud.