ISGroup Consultoría de Ciberseguridad

Seguridad de aplicaciones Google y Firebase desarrolladas con IA: Gemini, Antigravity y Jules

Quienes desarrollan en el stack de Google hoy en día pueden utilizar herramientas muy diversas entre sí: Gemini Code Assist en el IDE, Gemini CLI en la terminal, Jules como agente asíncrono en repositorios, Google Antigravity como entorno agent-first, Firebase y Google Cloud como backend e infraestructura. La ventaja es evidente: el código, las pruebas, la interfaz de usuario, las correcciones y las configuraciones pueden avanzar mucho más rápido.

El riesgo surge cuando esa velocidad atraviesa múltiples superficies a la vez. Una modificación puede comenzar con un prompt, pasar por el repositorio, ejecutar comandos en la terminal, ser verificada en el navegador y terminar en Firebase, Cloud Run, Cloud Functions, Cloud Storage o IAM. Antes del go-live, la pregunta no es si las herramientas de Google son útiles, sino qué han cambiado en el producto: código, API, autorizaciones, reglas de Firebase, cuentas de servicio, secretos, almacenamiento, despliegue y datos reales.

Para un equipo Google-native, la seguridad no termina en la revisión de código (Code Review) ni en la evaluación de seguridad en la nube (Cloud Security Assessment). Es necesario observar el comportamiento de la aplicación, el código generado, las configuraciones de Firebase y Google Cloud, y el proceso mediante el cual el agente ha producido o validado los cambios.

[Callforaction-WAPT]

Por qué el ecosistema de codificación con IA de Google debe tratarse como un perímetro único

Gemini Code Assist, Antigravity y Jules no tienen el mismo modelo operativo. Gemini Code Assist trabaja en el contexto del desarrollador y del IDE. Jules puede encargarse de tareas asíncronas, clonar el repositorio en un entorno en la nube, instalar dependencias, modificar archivos y preparar cambios para su revisión. Antigravity, según las comunicaciones de Google sobre Gemini 3, lleva a los agentes hacia una experiencia en la que el editor, la terminal y el navegador son superficies operativas coordinadas.

Esta diferencia importa. Una sugerencia inline que modifica una función tiene un impacto limitado y visible. Un agente que modifica archivos, ejecuta pruebas, instala paquetes y verifica la interfaz en el navegador produce un resultado más amplio: código, dependencias, configuraciones, registros (logs), capturas de pantalla, pruebas y suposiciones sobre el comportamiento de la aplicación. Si el backend es Firebase o Google Cloud, el paso de “funciona” a “es publicable” requiere controles específicos: no basta con que el artefacto sea funcional, hay que verificar qué ha cambiado en los límites de autorización, en los datos, en los puntos finales (endpoints), en las reglas de acceso y en los privilegios en la nube.

Gemini Code Assist: modo agente, contexto y áreas sensibles

Gemini Code Assist puede ayudar con explicaciones, generación de código, refactorización, modo agente y actividades en el repositorio. Cuando trabaja en áreas de aplicación sensibles, la revisión debe centrarse en los puntos que el asistente no puede conocer completamente: reglas de negocio, aislamiento de inquilinos (tenant isolation), roles internos, datos reales, cumplimiento normativo, convenciones empresariales y decisiones arquitectónicas no documentadas.

Los riesgos más concretos surgen cuando una sugerencia afecta a la autenticación, autorizaciones, middleware, rutas, validación de entradas, manejo de errores, registro de logs, dependencias o configuraciones de despliegue. Una modificación puede ser coherente con el prompt pero incorrecta respecto al producto: un control puede trasladarse al frontend, una ruta puede crearse sin autenticación del lado del servidor, una prueba puede confirmar solo el camino feliz (happy path).

Antes de la fusión (merge), los cambios generados o corregidos con Gemini Code Assist deben leerse como diffs de producción. Si afectan a API, datos o roles, se necesitan pruebas negativas: usuarios no autorizados, objetos de otros usuarios, diferentes inquilinos, tokens caducados, solicitudes fuera de secuencia, cargas útiles (payloads) manipuladas y acceso directo a rutas no expuestas en la interfaz de usuario.

Antigravity: editor, terminal y navegador en el mismo flujo de trabajo

Antigravity desplaza la atención de la asistencia individual en el IDE a un flujo más agéntico. Google lo describe como una plataforma en la que los agentes pueden tener acceso directo al editor, la terminal y el navegador. Este modelo es potente porque permite planificar, modificar, ejecutar y verificar de manera más integrada, y es precisamente por eso que el control debe ser más riguroso.

Cuando un agente trabaja entre la terminal y el navegador, un error no permanece confinado en el archivo modificado: puede convertirse en un comando de shell, una instalación de paquetes, una prueba de interfaz, una modificación de configuración, el inicio de un servicio local, una salida con secretos, capturas de pantalla con datos sensibles o un despliegue iniciado demasiado pronto. La revisión debe incluir qué se ha ejecutado, no solo qué se ha escrito.

La instalación, migración, despliegue, eliminación, uso de CLI en la nube, modificación de variables de entorno y configuraciones de Firebase o Google Cloud deberían requerir aprobación explícita. Los comandos ejecutados por el agente deben rastrearse cuando el repositorio contiene datos, claves o accesos a servicios reales. Si el navegador registra sesiones, capturas de pantalla o flujos, es necesario evitar que contengan datos personales, tokens, paneles administrativos e información de clientes innecesaria.

Jules: PR autónomas, máquinas virtuales en la nube y pruebas funcionales

Jules está diseñado para delegar tareas de desarrollo: corrección de errores, pruebas, documentación, funciones y actualizaciones. Trabaja clonando el código en una máquina virtual, instalando dependencias y modificando archivos. Esto reduce el impacto en el entorno local, pero no demuestra que el resultado sea seguro.

Una Pull Request (PR) generada por Jules puede estar bien organizada, compilar y pasar las pruebas, y aun así contener deriva de dependencias (dependency drift), pruebas que confirman el nuevo comportamiento sin desafiarlo, lógica de autorización simplificada, control de errores demasiado permisivo, paquetes añadidos para resolver un problema o configuraciones de entorno cambiadas para que la compilación funcione.

Antes de aceptar una PR generada de forma asíncrona, el equipo debería revisar el diff, el archivo de bloqueo (lockfile), los scripts de instalación/compilación/prueba, los archivos de configuración, las nuevas rutas, el middleware, las pruebas actualizadas y los datos utilizados en el entorno. La máquina virtual no debería recibir secretos de producción ni accesos a sistemas reales innecesarios para la tarea. Si Jules ha corregido o añadido pruebas, es necesario entender si cubren abusos y regresiones de seguridad o solo el camino previsto.

Reglas de Firebase generadas o modificadas con IA

Firebase es a menudo el punto donde un prototipo Google-native se convierte en producto: Autenticación, Firestore, Realtime Database, Cloud Storage, Functions, Hosting e integraciones. El riesgo más común es pensar que un control en la interfaz de usuario equivale a una regla de seguridad.

Firestore, Realtime Database y Cloud Storage deben tener reglas que partan de un “denegar por defecto” (default deny) y abran solo casos explícitos. Si el asistente genera reglas para “hacer que funcionen” la lectura y escritura, hay que verificar la propiedad, el rol, el inquilino, el estado del documento, las notificaciones personalizadas (custom claims) y la separación entre datos públicos y privados. Reglas como el acceso autenticado genérico o rutas demasiado amplias pueden ser suficientes para una demo, pero peligrosas en producción.

La revisión debe incluir pruebas con diferentes usuarios, usuarios anónimos, tokens caducados, documentos de otros inquilinos, archivos privados, cargas, eliminaciones y operaciones fuera de secuencia. Las reglas de seguridad de Firebase deben probarse con emuladores y casos negativos, no solo probarse desde la interfaz: si una regla permite lectura o escritura porque el frontend no muestra el botón, el control está en el lugar equivocado.

Google Cloud IAM y cuentas de servicio

Las herramientas de IA pueden ayudar a escribir código que utiliza Google Cloud, pero las cuentas de servicio e IAM siguen siendo una superficie crítica. El riesgo típico es utilizar roles demasiado amplios para que funcionen Cloud Functions, Cloud Run, almacenamiento, bases de datos, programadores o integraciones.

Una cuenta de servicio no debería tener roles de Propietario (Owner), Editor o roles primitivos por comodidad. Cada carga de trabajo (workload) debería tener una identidad dedicada, permisos mínimos, evitar claves estáticas siempre que sea posible y auditar la suplantación de identidad (impersonation) y los accesos. Si el agente sugiere crear o descargar una clave JSON, el equipo debe preguntarse si existe una alternativa más segura y si esa clave puede terminar en el repositorio, registros, prompts o artefactos.

Para aplicaciones de Firebase y Google Cloud generadas con IA, la evaluación de seguridad en la nube y la revisión de código deben encontrarse: el código muestra cómo se utilizan las cuentas de servicio y las API, mientras que la configuración en la nube muestra qué pueden hacer realmente esos roles. Una vulnerabilidad en la aplicación se vuelve más grave si la cuenta de servicio conectada puede leer almacenamiento, bases de datos o secretos más allá de lo necesario.

Tokens, API keys y secretos en el frontend

Una de las confusiones más frecuentes en las aplicaciones de Firebase es la diferencia entre las configuraciones previstas del lado del cliente y los secretos del lado del servidor. Algunos valores de Firebase están pensados para ser utilizados por el cliente junto con reglas de seguridad robustas. Otros tokens, claves privadas, secretos de webhook, claves de cuentas de servicio y credenciales de proveedores externos deben permanecer del lado del servidor.

Los asistentes de IA pueden generar código que parece funcionar pero coloca valores sensibles en paquetes de frontend, archivos .env expuestos, registros, pruebas o ejemplos. Antes del despliegue, hay que buscar claves en el repositorio, en el historial, en los prompts, en los registros de compilación, en los artefactos y en el código servido al navegador. Las API keys públicas deben limitarse con restricciones apropiadas; los secretos privados deben gestionarse en Secret Manager, leerse solo desde el tiempo de ejecución del lado del servidor y nunca imprimirse. Si una clave ha terminado en un contexto no previsto, eliminarla del archivo no es suficiente: debe rotarse.

Cloud Functions, Cloud Run y API expuestas

Muchas aplicaciones creadas con herramientas de IA de Google utilizan Cloud Functions, Cloud Run o puntos finales de API para conectar el frontend, bases de datos, almacenamiento, pagos, CRM, sistemas de tickets o modelos de IA. Son superficies expuestas y deben probarse como tales.

Los problemas más comunes son puntos finales públicos sin autenticación, invocadores IAM demasiado permisivos, CORS abierto, errores detallados, devoluciones de llamada (callbacks) y redirecciones no incluidas en listas blancas, ausencia de límites de tasa (rate limit), validación de entrada insuficiente, registros con información de identificación personal (PII) o tokens. Un agente puede generar un punto final para completar rápidamente una función sin aplicar la misma disciplina de seguridad presente en el resto del backend.

Antes del go-live, cada punto final debe llamarse directamente fuera del flujo de la interfaz de usuario. Es necesario probar el acceso anónimo, usuarios con roles bajos, diferentes inquilinos, cargas útiles manipuladas, solicitudes repetidas, devoluciones de llamada no previstas, archivos maliciosos y condiciones de error. Si la aplicación es accesible en línea, el WAPT (Web Application Penetration Test) debe verificar el comportamiento real, no solo el código.

Dependencias, SDK y scripts de instalación

Gemini Code Assist, Jules o Antigravity pueden añadir paquetes, actualizar SDK, modificar archivos de bloqueo o cambiar scripts de compilación. Estas modificaciones parecen operativas, pero afectan a la cadena de suministro y deben revisarse con la misma atención que el código de la aplicación.

Cada modificación en package.json, requirements.txt, pyproject.toml, archivos de bloqueo, scripts postinstall, compilación o pruebas debe examinarse para entender por qué se introdujo el paquete, si tiene mantenimiento, qué licencia tiene, qué dependencias transitivas trae, si existen vulnerabilidades conocidas y si el script ejecuta código no previsto.

En el contexto de Google y Firebase, es conveniente prestar atención a los SDK obsoletos, a las bibliotecas que gestionan tokens y sesiones, a los envoltorios (wrappers) no oficiales para servicios en la nube y a los paquetes con nombres similares. Una PR generada por el agente puede aceptarse porque resuelve un error de compilación, pero introducir una dependencia que el equipo no habría aprobado manualmente.

Datos reales en prompts, registros, capturas de pantalla y máquinas virtuales

Los agentes que trabajan entre el editor, la terminal, el navegador y las máquinas virtuales pueden ver más contexto que un simple chatbot: archivos, resultados de pruebas, capturas de pantalla, errores, registros, cargas útiles, tickets, documentación interna y sesiones del navegador. Esto aumenta la utilidad, pero también el riesgo de divulgación de datos.

Para la depuración y validación es mejor utilizar datos sintéticos o minimizados. Las capturas de pantalla de paneles, grabaciones del navegador, registros de Cloud Functions, volcados de Firestore, cargas útiles de webhooks y tickets de clientes no deberían entrar en el contexto del agente si no es estrictamente necesario. Cuando entran, es necesario saber dónde se conservan, por cuánto tiempo y quién puede acceder a ellos.

El control no es solo una cuestión de privacidad. Los datos reales en las pruebas pueden hacer que una modificación pase porque el conjunto de datos es favorable, mientras que falla en casos límite. Para la seguridad se necesitan conjuntos de datos que incluyan diferentes roles, inquilinos, registros no autorizados, archivos privados, usuarios deshabilitados y entradas maliciosas.

Lista de verificación antes del go-live

Herramientas y flujo de trabajo

  • Identifica qué herramientas han contribuido al código: Gemini Code Assist, Antigravity, Jules, Gemini CLI u otras herramientas de Google.
  • Recopila PR, diffs, ramas, comandos de terminal, pruebas ejecutadas, grabaciones del navegador, capturas de pantalla y artefactos.
  • Si un agente ha trabajado en una máquina virtual o de forma asíncrona, verifica qué dependencias ha instalado y qué archivos ha modificado.

Firebase y datos

  • Revisa las reglas de Firestore, Realtime Database y Cloud Storage con un enfoque de “denegar por defecto”.
  • Prueba el acceso con usuarios anónimos, usuarios autenticados, diferentes roles, diferentes inquilinos y archivos no autorizados.
  • Verifica la autenticación, notificaciones personalizadas, invitaciones, restablecimiento de contraseñas, contenidos premium, cargas y eliminaciones.
  • Si entran datos reales, controla los registros, la retención y las copias de seguridad.

Google Cloud e IAM

  • Controla las cuentas de servicio, roles IAM, claves estáticas, suplantación de identidad, invocadores de Cloud Run/Functions, almacenamiento, Secret Manager, Cloud Logging y entornos.
  • Evita roles primitivos por comodidad.
  • Cada carga de trabajo debe tener una identidad y permisos coherentes con lo que debe hacer.

API, frontend y secretos

  • Verifica rutas públicas, CORS, devoluciones de llamada, redirecciones, API keys, tokens en el frontend, secretos del lado del servidor, manejo de errores y límites de tasa.
  • Ejecuta escaneo de secretos en el repositorio, historial, registros, prompts y artefactos.
  • Rota cualquier clave que haya terminado en el lugar equivocado.

Dependencias y pruebas

  • Revisa archivos de bloqueo, SDK, paquetes añadidos, scripts de instalación/compilación/prueba y pruebas generadas.
  • Integra pruebas negativas sobre IDOR/BOLA, aislamiento de inquilinos, abuso de roles, cargas maliciosas, lógica de negocio y sesiones caducadas.
  • Si la aplicación o las API están en línea, ejecuta un WAPT sobre el entorno expuesto.

Cuándo basta una revisión interna y cuándo se necesita una verificación independiente

Una revisión interna puede bastar si las herramientas de IA de Google han producido modificaciones aisladas, no expuestas, sin datos reales, sin reglas de Firebase, sin IAM, sin cuentas de servicio y sin API públicas. Incluso en ese caso, es útil saber qué partes han sido generadas y cuáles han sido controladas por una persona competente.

Se necesita una verificación independiente cuando la aplicación utiliza Firebase o Google Cloud con datos reales, cuando se han modificado reglas de acceso, cuentas de servicio, Cloud Functions, Cloud Run, API, almacenamiento, devoluciones de llamada, redirecciones, dependencias o despliegues. También es necesario cuando Jules o Antigravity han producido PR amplias, ejecutado comandos o validado el comportamiento solo con pruebas funcionales.

El punto no es ralentizar las herramientas de Google. Es separar lo que puede acelerarse de lo que debe verificarse: autorizaciones, datos reales, superficies públicas, secretos, cuentas de servicio, reglas, API y configuraciones en la nube.

Cómo ISGroup verifica una aplicación de Google, Firebase y Cloud creada con IA

El control cambia según lo que Gemini Code Assist, Antigravity o Jules hayan modificado. Si el riesgo está en el código, en las PR, en el middleware, en la validación de entradas, en el uso de secretos o en las dependencias, la Revisión de Código ayuda a identificar vulnerabilidades y regresiones antes de la fusión. Si la aplicación o las API son alcanzables en línea, el Web Application Penetration Testing verifica el comportamiento real desde el exterior. Si el riesgo se refiere a Firebase, Google Cloud, IAM, cuentas de servicio, almacenamiento, Cloud Run o Cloud Functions, el Cloud Security Assessment verifica las configuraciones y los privilegios en el contexto real.

Si la herramienta de IA de Google tocó… Riesgo principal Control recomendado
Código de aplicación, PR de Jules, middleware, validación, manejo de errores, dependencias Vulnerabilidades o regresiones en el código Revisión de Código
Web app, API, Cloud Functions, Cloud Run o rutas expuestas Comportamientos abusables desde el exterior Web Application Penetration Testing
Reglas de Firebase, Cloud Storage, IAM, cuentas de servicio, Secret Manager, config de Google Cloud Configuración errónea en la nube o privilegios excesivos Cloud Security Assessment
Límites de confianza, multi-inquilino, flujos de datos, integraciones, pagos, LLM integrados Suposiciones arquitectónicas débiles Revisión de Arquitectura Segura
Uso continuo de Gemini, Antigravity o Jules en el ciclo de lanzamiento Controles no repetibles en lanzamientos y tuberías (pipelines) Ciclo de Vida de Aseguramiento de Software

La elección del control depende de lo que realmente ha cambiado: código, comportamiento expuesto, Firebase y Google Cloud, arquitectura o proceso de desarrollo. Antes del go-live conviene delimitar ese perímetro y verificar el riesgo efectivo sobre la aplicación.

¿Has usado Gemini Code Assist, Antigravity o Jules en una aplicación que utiliza Firebase o Google Cloud? ISGroup puede ayudarte a verificar el código, las API, las autorizaciones, las reglas de Firebase, las cuentas de servicio, los secretos, el almacenamiento y las configuraciones en la nube antes de que los datos reales y los usuarios entren en producción.

Evidencias a preparar antes de la revisión

Antes de involucrar a un equipo externo conviene preparar el repositorio, las PR, las ramas, los diffs, la lista de herramientas utilizadas, las URL de los entornos, la descripción de los roles, el proyecto de Firebase, el proyecto de Google Cloud, las cuentas de servicio, las reglas, Cloud Functions y Cloud Run, API, depósitos de almacenamiento (buckets), devoluciones de llamada, redirecciones y dependencias principales.

También son útiles los registros y artefactos depurados de datos sensibles, la lista de comandos ejecutados, las pruebas generadas, las grabaciones del navegador si están disponibles, las decisiones ya tomadas sobre riesgos aceptados y las remediaciones planificadas. Estas evidencias permiten distinguir problemas del código de configuraciones erróneas en la nube, vulnerabilidades de la aplicación de brechas de proceso, y riesgos inmediatos de mejoras planificables.

La pregunta que hacerse antes de la publicación

La decisión no debería ser “¿aceptamos o no aceptamos la PR del agente?” en abstracto. Debería ser: qué datos expone, qué reglas cambia, qué cuentas de servicio utiliza, qué puntos finales publica, qué secretos maneja y qué riesgo residual queda después de la remediación.

Gemini Code Assist, Antigravity y Jules pueden acelerar mucho el desarrollo en el stack de Google. La seguridad sirve para evitar que esa velocidad lleve a producción reglas de Firebase demasiado amplias, cuentas de servicio excesivas, API abusables, tokens en el frontend, almacenamiento accesible o PR que no se comprenden realmente. La pregunta final es simple: ¿la aplicación de Google, Firebase y Cloud creada o modificada con IA ha sido verificada como producto expuesto, o solo aceptada porque funciona en las pruebas? Si la respuesta no es clara, el siguiente paso no es ralentizar el desarrollo: es delimitar el riesgo antes de que los datos reales, los usuarios, las cuentas de servicio y las superficies públicas entren en producción.

Preguntas frecuentes (FAQ)

  • ¿Gemini Code Assist hace seguro el código que genera?
  • No. Puede ayudar a producir y revisar código, pero el equipo debe verificar la lógica de la aplicación, las autorizaciones, las dependencias, los secretos, las reglas de Firebase y el comportamiento real antes de la producción.
  • Jules trabaja en una máquina virtual: ¿es suficiente esto para confiar en la PR?
  • No. La máquina virtual aísla la ejecución de la tarea, pero la PR aún puede introducir errores de autorización, deriva de dependencias, pruebas débiles, manejo de errores arriesgado o configuraciones no coherentes con el producto.
  • ¿Es Antigravity más arriesgado que un IDE tradicional?
  • El riesgo cambia porque el agente puede operar entre el editor, la terminal y el navegador. Esto aumenta la productividad, pero requiere control sobre comandos, diffs, pruebas, datos visibles y configuraciones tocadas.
  • ¿Son fiables las reglas de seguridad de Firebase generadas con IA?
  • Deben verificarse. Una regla que hace que la demo funcione puede ser demasiado abierta para la producción. Se necesitan pruebas con diferentes usuarios, inquilinos, roles, archivos privados y operaciones no autorizadas.
  • ¿Cuándo se necesita un Cloud Security Assessment?
  • Cuando el desarrollo asistido por IA ha tocado Firebase, Google Cloud, IAM, cuentas de servicio, Cloud Run, Cloud Functions, Cloud Storage, Secret Manager, devoluciones de llamada, redirecciones o configuraciones de despliegue.

[Callforaction-CSA-Footer]

Fuentes y referencias útiles

In

, , ,