Cloud Intelligence™Cloud Intelligence™

Cloud Intelligence™

Llegó la solución al abuso de API Keys de Gemini, y tiene fecha límite

By John D'EliaJun 17, 20265 min read

Esta página también está disponible en English, Deutsch, Français, Italiano, 日本語 y Português.

TL;DR

  • Google retirará gradualmente las API keys estándar de la API de Gemini en dos etapas: las keys estándar sin restricciones dejan de funcionar el 19 de junio de 2026; todas las keys estándar dejan de funcionar en septiembre de 2026
  • Si tienes keys sin restricciones, te queda poco tiempo para restringirlas o migrar al nuevo tipo de auth key
  • Las nuevas "authorization keys" están vinculadas a una service account, lo que cierra el vector de abuso de keys que abordé en un post anterior
  • Usa nuestro escáner gratuito para detectar tus keys expuestas: github.com/doitintl/gcp-apikey-check

Un poco de contexto

Hace algunas semanas escribí sobre cómo actores maliciosos conseguían API keys de Google sin restricciones ni alcance definido a partir de páginas web o keys publicadas por accidente. Una vez en sus manos, generaban contenido con Gemini a toda velocidad y desaparecían, dejando al dueño desprevenido con una factura enorme de Gemini, típicamente de decenas de miles de dólares y a veces mucho más. Hemos visto varios casos así, y el sub-reddit de googlecloud está lleno de historias de terror.

Hace poco, Google introdujo cambios en las API keys de Gemini recién creadas. Parece que por fin se está moviendo para cerrar la brecha de las keys existentes, lo que afectará a quienes usan la API de Gemini. Los cambios pintan bien, ¡pero el calendario es agresivo!


Qué cambia

Google está migrando la API de Gemini de keys estándar a keys de autorización (auth).

Las keys estándar asocian las solicitudes a un proyecto de Google Cloud para facturación y cuota, pero no identifican a quién hace la llamada. Al no haber identidad del solicitante, se limitan los controles de acceso que pueden aplicarse.

Las auth keys están vinculadas a una service account específica de Google Cloud. Las solicitudes hechas con una auth key se procesan bajo la identidad de esa service account, lo que permite un control de acceso basado en IAM como corresponde. Google indica que las auth keys también contarán con controles de detección de fraude más ágiles.

El calendario de migración:

  • 19 de junio de 2026: la API de Gemini rechazará las solicitudes de keys estándar sin restricciones. Las keys estándar con restricciones de API explícitas seguirán funcionando.
  • Septiembre de 2026: la API de Gemini rechazará las solicitudes de todas las keys estándar. Para esa fecha deberás estar usando auth keys.

Todas las keys nuevas y recién creadas en Google AI Studio ya son auth keys por defecto.


¿En qué ayudan las Auth Keys?

Con una key estándar sin alcance de API, cualquier actor malicioso que la encontrara podía probarla contra la API de Gemini y empezar a generar contenido facturado a tu cuenta. Ese es el ataque que describí en mi post anterior.

Las auth keys cierran esa brecha de varias maneras. Por defecto están acotadas a la API de Gemini, así que una auth key filtrada no puede usarse con otras APIs de Google. Más importante todavía: están atadas a una service account, lo que permite aplicar controles de acceso de IAM. Algo que no era posible con las keys estándar. Las solicitudes hechas con una auth key también quedan registradas en los logs de auditoría, y la detección de secretos filtrados de Google puede reaccionar más rápido porque hay una identidad que revocar.

Dicho esto, las auth keys no son una solución perfecta. Una auth key filtrada o exfiltrada todavía podría usarse para generar contenido e inflar la factura. Aún no sabemos qué tan efectivos son los sistemas anti-fraude de Google en estos casos.

La mejor solución es no usar API keys en absoluto. Si usas Gemini en el backend, considera migrar a la Gemini Enterprise Agent Platform, que utiliza credenciales de IAM de corta duración en lugar de keys estáticas: nada que filtrar, nada que rotar.


Qué hacer

Antes del 19 de junio de 2026: asegura las keys estándar sin restricciones

Ejecuta el escáner para encontrar tus keys sin restricciones en toda tu organización de GCP:

Terminal window
git clone https://github.com/doitintl/gcp-apikey-check
cd gcp-apikey-check
uv sync
# Escanea una organización completa (**recomendado**)
uv run gcpkeyscan.py --org-id YOUR_ORG_ID
# O un solo proyecto
uv run gcpkeyscan.py --project-id YOUR_PROJECT_ID

Para cada key sin restricciones que encuentres, tienes dos opciones:

Opción 1 — Restringir la key (te da margen hasta septiembre): En Google AI Studio, entra a la página de API Keys, ubica las keys marcadas como "Unrestricted", pasa el cursor sobre la etiqueta, haz clic en "Add restrictions" y selecciona "Restrict to Gemini API only."

Opción 2 — Migrar a una auth key ahora (recomendado):

  1. Ve a AI Studio API Keys
  2. Haz clic en "Create API key" — las keys nuevas ya son auth keys por defecto
  3. Actualiza el código de tu aplicación, las variables de entorno y las configuraciones de despliegue con la nueva key
  4. Prueba, prueba y vuelve a probar
  5. Elimina o revoca la key estándar anterior

Consulta la documentación de migración de Google para más detalles si te encuentras con problemas.

Antes de septiembre de 2026: migra las keys estándar restantes

Cualquier key estándar que hayas restringido en el primer paso dejará de funcionar en septiembre. Usa los mismos pasos de migración para crear auth keys de reemplazo y actualizar tus aplicaciones.


El panorama general

Migrar a auth keys es una mejora, pero la buena práctica de fondo no cambia.

Para la mayoría de los workloads en Google Cloud: Workload Identity Federation y Application Default Credentials con roles de IAM son mejores opciones — sin key que filtrar, sin rotación que gestionar y con trazas de auditoría adecuadas por defecto. Si usas la API de Gemini en producción, recomendamos pasar a Gemini Enterprise Agent Platform, que utiliza credenciales de corta duración en lugar de API keys estáticas, además de otras funciones útiles para producción como el soporte del proveedor.

Para aplicaciones de Maps y Firebase: estas keys siguen siendo API keys estándar; aun así, conviene seguir las buenas prácticas y restringir cada key a las APIs específicas que necesita, agregar restricciones de aplicación y nunca combinar keys de Maps o Firebase con Gemini u otras APIs de IA en la misma key. Si puedes, mantén las keys de Gemini en un proyecto aparte como capa extra de seguridad.


Próximos pasos

La fecha límite del 19 de junio ya está encima. Si todavía no has auditado tus keys, hazlo ahora: