Varios clientes de Google Cloud denuncian que sus claves de API quedaron comprometidas y se usaron para correr cargas inferenciales sobre los modelos de video e imagen más caros del catálogo de Google, dejándolos con facturas por decenas de miles de dólares y semanas de negociaciones para tratar de probar que no son responsables del consumo. El reporte original de The Register recopila al menos tres casos detallados y documenta el patrón que se repite en hilos de Reddit y comunidades de desarrolladores.
¿Qué está pasando exactamente?
El patrón es consistente: usuarios que durante meses o años pagaron cuentas mensuales de pocos dólares a Google Cloud por servicios como Maps ven cómo, en cuestión de minutos, su tarjeta queda cargada con USD 3.000, 5.000, 10.000 o más en llamadas a Nano Banana (generación de imágenes con Gemini) y Veo 3 (video generativo).
Google le dijo a The Register que se trata de un problema "industrial" y no de un fallo de seguridad específico de la compañía. Atribuye la mayoría de los incidentes a credenciales expuestas en repositorios públicos como GitHub, escaneados por actores maliciosos.
Pero el ángulo incómodo es otro: los propios desarrolladores afectados estaban siguiendo las instrucciones oficiales de Google para Maps cuando dejaron esas claves expuestas. La instrucción histórica era cargar la clave en el front-end. Y hace unos tres años, sin aviso explícito a los clientes, Google permitió que esas mismas claves accedieran también a la API de Gemini.
¿Cuánto pierden los desarrolladores afectados?
Rod Danan, CEO de Prentus (plataforma de preparación para entrevistas de trabajo), usa la API de Google Maps para su producto. Por años, su factura nunca superó los USD 50 al mes.
"Es simplemente 'Boom, te acabamos de cobrar 3.000 dólares'. Y uno entra a la aplicación pensando '¿qué está disparando esto? ¿Cuál es la fuente?' Determinar eso, honestamente, no es nada simple", dijo Danan.
Mientras buscaba el origen del cargo, pasaron cinco minutos y aparecieron otros USD 5.000 facturados. Para cuando logró cortar el acceso, su tarjeta tenía USD 10.138 en cobros, casi todos por generación de video con Veo 3 y tokens de salida de imágenes con Gemini, servicios que él nunca había usado y que no tienen relación con su producto.
Google le dijo que no encontró evidencia de fraude y hasta el momento se ha negado a devolver el dinero.
"Tienes esta clave de Google Maps que todos usan, y la guía de Google es que la cargues en el front end. Eso hicimos. Y de pronto cambian las llaves para que la clave de Maps, que está expuesta públicamente, pueda usarse para Gemini, y no le comunican eso a los clientes", explicó Danan.
¿Y los topes de gasto no protegen?
Acá está el segundo escalón del problema. Isuru Fonseka, desarrollador con sede en Sydney y diez años construyendo aplicaciones sobre Google Cloud, tenía un tope de gasto duro fijado en USD 250 y, según asegura, nunca expuso públicamente su clave (estaba dentro de Firebase).
Despertó el 29 de abril con varios correos de su proveedor de tarjeta de crédito rechazando transacciones por montos altos. Cuando entró a GCP, vio cargos de USD 500, USD 1.000 y USD 2.000 pasando uno tras otro. Algunos fueron rechazados, otros se aprobaron.
"Esta fue la parte más frustrante. Hay un mecanismo extraño donde pueden detectar lo suficiente como para cobrarte la tarjeta, pero no lo suficiente como para mostrarte en qué se está usando. El daño total quedó en torno a AUD 17.000 (USD 12.000)", relató Fonseka.
Aunque su tope estaba en Tier 1 (USD 250), cuando revisó la cuenta tras el ataque vio que el sistema lo había escalado solo a Tier 2 o Tier 3, donde el límite llega hasta USD 100.000.
Google confirmó la mecánica a The Register: el sistema "promueve automáticamente al siguiente tier" cuando el patrón de uso lo gatilla, lo que en la práctica significa que un atacante con la clave puede empujar la cuenta al tier siguiente con uso suficiente y disparar el techo de gasto.
¿Por qué pasó esto con Maps?
El investigador de seguridad Joe Leon, de Truffle Security, publicó en febrero un análisis que advirtió que las claves de Maps de Google ya no eran seguras de compartir. El detalle técnico:
- Durante años, la instrucción para integrar Maps en un sitio era cargar un widget con la clave API en HTML público.
- Hace tres años, Google empezó a permitir que esas mismas claves accedieran también a los modelos de Gemini.
- Una búsqueda automatizada de Leon sobre millones de páginas web encontró 3.000 claves Google con prefijo "A-I-Z-A" que originalmente se desplegaron para Maps y ahora pueden acceder a Gemini.
"Ahora esa misma clave puede usarse tanto para acceder a Maps como a Gemini. Ese es el núcleo de lo que descubrí", explicó Leon.
Google reaccionó parcialmente desde febrero. Hoy obliga a configurar restricciones de API al crear nuevas claves y ya no es posible generar una credencial que acceda simultáneamente a Maps y Gemini. También lanzó un nuevo tipo de API key específica para Gemini, con prefijo "A-Q".
¿Qué pueden hacer los desarrolladores chilenos y LatAm?
Para integradores y startups que usan Google Cloud desde Chile, el ataque tiene implicancias prácticas:
1. Auditar claves AIZA existentes: si la clave fue creada antes de marzo de 2026, asumir que puede acceder a Gemini aunque solo se haya pedido para Maps. Regenerar y restringir. 2. Aplicar restricciones de referrer y HTTP: una clave de Maps debe limitarse a un dominio específico vía "HTTP referrer". Sin esa restricción, queda usable desde cualquier IP. 3. Separar credenciales por servicio: una clave para Maps, otra para Gemini, otra para Vertex. Nunca reusar. 4. No confiar en los topes de gasto: el caso Fonseka deja claro que GCP escala los tiers automáticamente. La defensa real es controlar el blast radius vía service accounts con scopes mínimos. 5. Pagar con tarjeta virtual con tope bajo: para proyectos personales o startups en etapa temprana, una tarjeta virtual con tope mensual de USD 100-200 puede ser la última línea de defensa cuando los controles de GCP fallan.
Comparativa: políticas de spending caps entre nubes
| Proveedor | Hard cap real | Auto-upgrade de tier | Tiempo de soporte para anomalías |
|---|---|---|---|
| Google Cloud | Soft (escalable) | Sí, automático | Hasta 36 horas |
| AWS | Sin hard cap nativo | No | 24-72 horas (Business) |
| Azure | Hard cap en suscripciones MOSP | No | 24-48 horas |
| OpenAI Platform | Hard cap real por org | No | 12-24 horas |
Tanto Danan como Fonseka siguen negociando con Google. Ambos descartaron pedir contracargo a su tarjeta de crédito porque temen que eso resulte en suspensión de su proyecto en Google Cloud, del que dependen sus aplicaciones en producción.




