Construyendo un Auditor Autónomo para Firebase Rules con Antigravity
Jul 9, 2026
Las Reglas de Seguridad de Firebase son uno de los componentes más críticos de cualquier aplicación. Una sola mala configuración, como allow read, write: if true, puede exponer toda una base de datos o un bucket de almacenamiento.
Aunque las revisiones manuales son valiosas, mantener auditorías de seguridad consistentes se vuelve cada vez más difícil a medida que los equipos crecen, los entornos se multiplican y la frecuencia de implementación aumenta. Con la llegada de Google Antigravity, surgió una nueva oportunidad: usar agentes de IA no solo para generar código, sino también para ejecutar flujos de trabajo completos de análisis y validación.
Con esta idea en mente, desarrollé Firebase Rules Agent, un agente autónomo que audita las reglas de seguridad de Cloud Firestore y Cloud Storage, identifica riesgos de seguridad, genera reportes estructurados y mantiene a los desarrolladores en control durante todo el proceso de toma de decisiones.
El Problema
En muchos proyectos, las Reglas de Seguridad de Firebase evolucionan continuamente. A medida que se introducen nuevas colecciones, rutas y características, es común encontrar problemas como:
- Acceso público accidental.
- Validación de autenticación inconsistente.
- Reglas de autorización excesivamente permisivas.
- Desviación de configuración entre las reglas almacenadas en Git y las desplegadas en producción.
Mi objetivo era construir un agente capaz de realizar estas auditorías de seguridad automáticamente mientras sigue el Principio de Mínimo Privilegio, sin quitar al desarrollador de las decisiones críticas de seguridad.
Un Enfoque Basado en Agentes
En lugar de usar un Modelo de Lenguaje Grande como un simple generador de texto, el agente se comporta como un auditor de seguridad especializado responsable de:
- Inspeccionar las reglas de seguridad de Firestore y Cloud Storage.
- Verificar políticas de seguridad y cumplimiento.
- Detectar configuraciones inseguras.
- Clasificar hallazgos por severidad.
- Generar recomendaciones de remediación.
Arquitectura del Agente
Para resolver este problema, diseñé un flujo de trabajo compuesto por etapas independientes. Cada componente tiene una responsabilidad bien definida, permitiendo al agente analizar tanto archivos de reglas locales como configuraciones de producción en vivo.
1. Sandbox
Antes de enviar cualquier regla al modelo de lenguaje, el agente realiza un paso de sanitización.
Su propósito es eliminar información que no aporta valor al análisis, como comentarios o notas de desarrollo internas.
import * as fs from "fs";
const rules = fs.readFileSync(firestorePath, "utf8");
const sanitized = rules.replace(/\/\/.*/g, ""); // Eliminar comentarios
fs.writeFileSync(
path.join(sandboxDir, "firestore_rules_check.txt"),
sanitized
);
Esta capa reduce la exposición accidental de información sensible mientras asegura que el modelo se enfoque exclusivamente en la lógica de autorización.
2. Orquestador
El punto de entrada del agente es un script de Bash (run.sh) que prepara el entorno de ejecución automáticamente. Detecta el proyecto de Firebase, extrae el PROJECT_ID de .firebaserc, prepara el directorio de reportes y lanza la auditoría.
DATE=$(date +%Y-%m-%d_%H-%M-%S)
REPORT_DIR="reports/audit_$DATE"
mkdir -p "$REPORT_DIR"
npx ts-node scripts/automate-audit.ts "$TARGET_PROJECT"
3. Auditando con Antigravity
Una vez que el entorno está listo, la Antigravity CLI (agy) toma el control.
El agente analiza las reglas sanitizadas, identifica configuraciones inseguras y genera un reporte de seguridad estructurado que contiene hallazgos categorizados y recomendaciones de remediación.
4. Auditoría en Vivo con Firebase MCP
A diferencia de los enfoques tradicionales que solo analizan archivos locales, el agente puede auditar la configuración real de producción usando Model Context Protocol (MCP).
Cuando se ejecuta en modo --live, el agente consume herramientas expuestas por el servidor MCP de Firebase, como firebase_get_security_rules, para recuperar las reglas de seguridad actualmente desplegadas y analizarlas directamente.
{
"mcpServers": {
"firebase-mcp-server": {
"command": "npx",
"args": ["-y", "firebase-tools@latest", "mcp"]
}
}
}
Esto asegura que la auditoría refleje el estado real de producción en lugar de depender únicamente de los archivos disponibles en el repositorio local.
Manteniendo a los Humanos al Mando: Human-in-the-Loop
Aunque el agente automatiza la mayor parte del flujo de auditoría, las decisiones críticas permanecen bajo el control del desarrollador.
Después de que se completa el análisis, Antigravity presenta un resumen de los cambios propuestos y solicita aprobación explícita antes de generar los artefactos finales.
En este punto, el mecanismo Human-in-the-Loop entra en acción. Antes de persistir cualquier reporte, Antigravity muestra un diff detallado y espera confirmación explícita.
Solo después de revisar manualmente la salida propuesta y seleccionar "Yes, allow creation", el agente escribe el reporte de auditoría en el directorio reports/audit_YYYY-MM-DD_HH-MM-SS/.
Este paso de aprobación garantiza que el desarrollador siempre tenga la decisión final, preservando la integridad del flujo de trabajo de gobernanza y previniendo escrituras no intencionadas.
Un Ejemplo Real de Auditoría
Para demostrar al agente en acción, grabé el proceso completo de auditoría, desde la ejecución del comando hasta la aprobación del reporte generado.
En el video adjunto, puedes ver cómo el agente detecta vulnerabilidades de seguridad en tiempo real y presenta los resultados de la auditoría para su revisión manual.
El reporte generado no solo identifica configuraciones inseguras, sino que también explica los riesgos asociados de escalada de privilegios y proporciona recomendaciones concretas de remediación, todo dentro de un flujo de trabajo de aprobación Human-in-the-Loop.
El reporte generado no solo identifica configuraciones inseguras, sino que también explica los riesgos asociados de escalada de privilegios y proporciona recomendaciones concretas de remediación, todo dentro de un flujo de trabajo de aprobación Human-in-the-Loop.
¿Por qué usar un Agente?
La diferencia entre un LLM tradicional y un agente de IA especializado no es simplemente la generación de texto.
Un agente es capaz de ejecutar un flujo de trabajo operativo completo.
En lugar de actuar como un asistente conversacional, participa activamente en la gobernanza de infraestructura combinando razonamiento, uso de herramientas y ejecución controlada.
Conclusión
Este proyecto me demostró que los agentes de IA pueden asumir responsabilidades mucho más allá de la generación de código.
Al combinar Model Context Protocol, un entorno sandbox aislado y un proceso de aprobación Human-in-the-Loop, se vuelve posible automatizar auditorías de seguridad sin sacrificar control, transparencia o trazabilidad.
En lugar de reemplazar a los desarrolladores, los agentes de IA pueden convertirse en colaboradores confiables que automatizan tareas de ingeniería repetitivas mientras dejan las decisiones arquitectónicas y de seguridad firmemente en manos humanas.
Código Fuente
Puedes explorar el proyecto completo, las instrucciones de instalación y los detalles de implementación en el repositorio de Firebase Rules Agent.