Un pequeño startup mexicano se ha convertido en ejemplo ilustrativo de un problema cada vez más frecuente en la era de la IA generativa en la nube: la filtración de una clave API de Google Gemini permitió a atacantes lanzar peticiones masivas a los modelos, generando en apenas 48 horas un cargo superior a 82.000 dólares. El incidente no solo evidencia la fragilidad en la gestión de credenciales por parte de los clientes, sino también decisiones de diseño en Google Cloud que muchos equipos desconocen.
De 180 a 82.314 dólares: cómo una clave API robada disparó los costes
Según el desarrollador que describió el caso en Reddit, la comprometida ocurrió entre el 11 y el 12 de febrero. Durante ese periodo, los atacantes ejecutaron un gran volumen de llamadas a Gemini 3 Pro Image y Gemini 3 Pro Text, consumiendo por completo el límite disponible y generando una factura de 82.314 dólares estadounidenses.
La empresa, compuesta por solo tres personas, gastaba habitualmente alrededor de 180 dólares mensuales en el uso de APIs. El salto de consumo supone un aumento aproximado del 46.000 %, una cifra capaz de comprometer la viabilidad financiera de un proyecto de este tamaño. Tras detectar la actividad anómala, el responsable revocó la clave, deshabilitó el acceso a Gemini API, rotó todas las credenciales y abrió un caso con el soporte de Google solicitando la cancelación o reducción de la deuda.
La respuesta inicial de Google se apoyó en el modelo de responsabilidad compartida: la compañía asegura la infraestructura de la nube, pero la protección de claves, tokens y secretos recae en el cliente. Aunque esta postura es coherente con los marcos de referencia de la industria (por ejemplo, Cloud Security Alliance y NIST), el caso evidencia que, en el contexto de APIs de IA de alto coste, un único error de gestión de credenciales puede convertirse en un incidente económico crítico.
Claves de Google Cloud reutilizadas: de identificadores de proyecto a puertas de entrada a Gemini
En paralelo a este incidente, investigadores de Truffle Security realizaron un escaneo masivo de recursos públicos y detectaron 2.863 claves API activas de Google expuestas. Muchas de ellas se crearon originalmente como simples identificadores de proyecto para servicios como Maps o Firebase, pero hoy permiten acceder a Gemini API sin intervención adicional del propietario.
La raíz del problema está en el formato y modelo de reutilización de las claves API de Google Cloud. Estas claves, reconocibles por el prefijo AIza, son fáciles de localizar mediante análisis automatizado de código fuente, repositorios públicos y páginas web. En varias guías oficiales de Google —por ejemplo, para Maps y Firebase— se indica explícitamente que estos identificadores no son secretos y que su función principal es asociar el consumo a un proyecto concreto.
En el caso de Google Maps, todavía hoy se recomienda a los desarrolladores insertar la clave directamente en el código HTML, accesible para cualquier visitante o motor de búsqueda. El punto crítico es que esas mismas claves pueden empezar a utilizarse automáticamente para acceder a Gemini, sin que el propietario reciba un aviso claro de que un identificador “no secreto” ha adquirido de facto privilegios de credencial sensible.
Cuando un identificador público se convierte en credencial de IA de alto impacto
Tal y como explica Joe Leon, investigador de Truffle Security, un escenario típico es el siguiente: un desarrollador crea hace años una clave API para Google Maps y, siguiendo la documentación oficial, la incluye en el código público del sitio web. Años después, el mismo proyecto habilita Gemini API, y esa clave heredada pasa a actuar como credencial completa para invocar modelos de lenguaje (LLM).
Un atacante que localice esa clave en un repositorio o en el HTML de la página podría:
• Realizar llamadas a Gemini a cargo de la cuenta víctima.
• Acceder a ficheros asociados y cachés de modelos, si la configuración lo permite.
• Generar costes significativos en pocas horas, difíciles de detectar hasta la emisión de la factura.
Respuesta de Google y mitigaciones anunciadas
Truffle Security notificó a Google el problema y aportó como evidencia un sitio público donde una clave incrustada desde 2023 permitía acceso directo a Gemini API. El informe fue inicialmente rechazado en noviembre de 2025 como “comportamiento esperado del sistema”.
Tras demostrar casos similares incluso en recursos propios de Google, la compañía reclasificó el hallazgo como bug de alta severidad y solicitó el listado completo de las 2.863 claves expuestas. Según la comunicación oficial, Google está trabajando en una corrección y ha desplegado ya mecanismos proactivos para detectar y bloquear claves filtradas cuando se usan contra Gemini API. No obstante, mientras el modelo de claves compartidas entre servicios se mantenga, la superficie de riesgo seguirá siendo relevante.
Recomendaciones clave para proteger APIs de Google Cloud y Gemini
Truffle Security aconseja a todos los clientes de Google Cloud auditar sus proyectos con herramientas de secret scanning como TruffleHog, que analizan código fuente, pipelines CI/CD y sitios web en busca de fugas de secretos y claves API. Organizaciones como OWASP y el propio Google recomiendan integrar este tipo de análisis de forma continua en el ciclo de desarrollo.
Desde una perspectiva de ciberseguridad, el caso pone de relieve un patrón emergente: identificadores antaño públicos acumulan progresivamente permisos sensibles a medida que las plataformas incorporan servicios de IA generativa. Lo que ayer era un simple ID de proyecto puede convertirse hoy en la llave de acceso a modelos de alto coste y datos potencialmente confidenciales.
Para mitigar el riesgo, resulta aconsejable que las organizaciones:
• Traten todas las claves API de Google Cloud como secretos por defecto, evitando su inclusión en código público o HTML.
• Revisen periódicamente el alcance y permisos de las claves existentes al activar nuevos servicios, en especial Gemini y otras APIs de IA.
• Integren escaneo automático de secretos en cada fase del CI/CD y revisen repositorios históricos (incluyendo ramas antiguas).
• Configuren presupuestos, alertas y límites de consumo estrictos en Google Cloud para que un uso anómalo se detecte en cuestión de horas.
• Utilicen gestores de secretos (como Google Secret Manager) y apliquen principios de mínimo privilegio y rotación periódica de claves.
La historia de este startup y las evidencias aportadas por Truffle Security muestran que una única “clave no secreta”, mal entendida y mal gestionada, puede escalar hasta convertirse en un incidente económico y de seguridad de primer nivel. Revisar hoy las claves API de Google Cloud, reforzar la gobernanza de secretos e incorporar controles automáticos en el ciclo de desarrollo es una inversión mínima comparada con el coste potencial de la próxima factura inesperada de la nube.
