El sandbox de Antigravity protege tu portátil, no tu código

¿Antigravity es seguro?

Seguro frente al fallo que todo el mundo se imagina, indefinido frente al que de verdad cuesta dinero: bajo esa palabra viven tres preguntas distintas, y Antigravity las responde de forma muy desigual.

¿Puede destrozarte el portátil o llevarse tus claves? En macOS y Linux, prácticamente no, por diseño y sin que toques nada. ¿Puede ejecutar algo que no pretendías? Solo si eres tú quien ensancha las reglas, y ensancharlas es justo lo que la gente está buscando cómo hacer. ¿Puede escribir una vulnerabilidad en tu producto, commitearla y ver los tests en verde? Sí. Y no hay nada en el producto que apunte a ese caso.

Empecemos por la definición del fabricante: antigravity.google habla de una «plataforma de desarrollo agéntica» cuyos agentes «ejecutan comandos de shell directamente». La superficie de riesgo la enuncia por tanto el propio proveedor, y todo lo que sigue en la documentación es un intento honesto de vallarla.

¿Qué bloquea realmente el sandbox de Antigravity?

Cuatro fronteras, y quien las sostiene es el sistema operativo, no la buena voluntad del modelo.

El preset por defecto une las cuatro cosas. «Los comandos de terminal se ejecutan dentro del Terminal Sandbox aislado, con acceso restringido a tu workspace y a los directorios temporales, y sin acceso a red. Los comandos pueden ejecutarse sin aprobación manual dentro del sandbox.»

Lee esa última frase como el trato que es. La ventana de aprobación, esa que cualquier desarrollador acaba clicando a ciegas a la cuadragésima vez, desaparece porque se vuelve innecesaria para la clase de comando que solo puede dañar un directorio desechable. Sigue siendo mejor trato que un agente que pregunta por todo y te entrena para decir que sí.

¿Por qué el sandbox no está soportado en Windows?

Porque la versión de Windows sigue con el sistema de permisos anterior. La página del sandbox lo dice con todas las letras: «el sistema de permisos actualizado de Antigravity está disponible actualmente en macOS y Linux, donde el sandbox viene activado por defecto». Tanto esa página como la de permisos llevan la misma nota, Windows «pasará al sistema de permisos unificado en una versión futura».

Para un equipo esto no es una nota al pie. Las dos plataformas exponen ajustes distintos bajo nombres distintos: una política escrita en un Mac no se traslada a un portátil Windows ni copiándola con cuidado.

Se puede leer esa tabla como si Windows fuera más estricto, y es medio cierto: preguntar por cada comando no declarado es un control real. La mitad falsa llega cuando la respuesta es que sí. En macOS, una aprobación dada demasiado rápido se ejecuta en una caja sin red y sin visión de ~/.ssh. En Windows, hoy, se ejecuta en tu máquina.

¿Cómo funcionan realmente los permisos de Antigravity?

Tres verbos y un motor de coincidencia. Las reglas son Deny, Ask o Allow, «las reglas en conflicto se evalúan estrictamente por orden de prioridad: Deny > Ask > Allow», y así es como un Deny que escribiste el trimestre pasado sobrevive al Allow que añades hoy con prisa.

Normalmente es en el motor donde se rompen las listas blancas. Este es mejor que la media: una regla command(git) «coincide por prefijo exacto de palabra o token, literalmente, por defecto», regex: toma el relevo cuando necesitas un patrón, y command(*) cuando has decidido dejar de leer. Y entonces llega el pasaje que casi todos los artículos sobre este producto cuentan al revés.

El bypass clásico lo nombra la propia documentación: «ciertas construcciones de shell pueden esconder la ejecución de comandos arbitrarios detrás de un prefijo por lo demás inofensivo», y cita la sustitución de comandos y de procesos, $(...), las comillas invertidas, <(...). Su respuesta es estrechar en lugar de ensanchar: «cuando Antigravity detecta alguna de ellas (o no consigue analizar limpiamente el comando), desactiva la coincidencia por prefijo para toda la línea: el comando se ejecuta sin preguntar solo si una regla coincide con la línea completa, carácter a carácter.»

¿Qué permite de verdad «allow all commands»?

Todo lo que un shell sepa expresar: dentro del sandbox en macOS y Linux, sobre tu host en Windows. Esa es la respuesta honesta a la pregunta más buscada sobre este producto, y la distancia entre esas dos mitades es lo único interesante de la pregunta.

Conviene decirlo sin rodeos, porque vendemos un producto de esta categoría: nuestra propia guarda de comandos también coincide por texto literal. Cualquier lista blanca construida sobre comparación de cadenas, la nuestra incluida, afirma algo sobre los caracteres de un comando y nada sobre su efecto. En nuestro estudio controlado esas guardas produjeron trece falsos positivos a lo largo de treinta tickets; publicamos el número en lugar de redondearlo. La comparación de cadenas sigue siendo la herramienta correcta para una frontera gruesa, y la equivocada para una decisión en la que te juegas la empresa.

De ahí el orden de prioridades. El sandbox es un control porque lo impone el kernel; la lista de reglas es solo una comodidad, que decide cada cuánto te interrumpen. Apagar lo primero para que lo segundo deje de molestarte es cambiar un control por una comodidad.

¿Son seguros los skills de Antigravity?

Nadie lo ha dicho, y ese es justamente el hallazgo. «Antigravity skills» es lo primero que ofrece el autocompletado de Google tras el nombre del producto, en español igual que en francés, alemán, italiano y portugués, normalmente seguido de «antigravity skills github». La gente ya se los está descargando. Y la documentación de skills no dice ni una palabra sobre cómo revisar, evaluar o confiar en uno de terceros.

Esto es un skill, según esa misma página: una carpeta, en <workspace-root>/.agents/skills/<skill-folder>/ para un workspace o en ~/.gemini/config/skills/<skill-folder>/ para todos, que exige un SKILL.md y puede llevar subdirectorios scripts/, examples/ y resources/. No hace falta «decirle explícitamente al agente que use un skill». Él «decide en función del contexto».

Junta esos tres hechos y tienes una supply chain: una carpeta que llega por una pull request, con instrucciones y opcionalmente scripts ejecutables, que el agente lee y aplica sin que nadie se lo pida.

Aquí el sandbox ayuda menos de lo que se supone, y el motivo conviene decirlo con precisión. Retiene los comandos que un skill ejecuta; no retiene las instrucciones que un skill da. Un SKILL.md que empuje con discreción al agente hacia una política CORS permisiva, un control de propiedad olvidado o una línea de log que imprime el token dará un diff limpio, una batería de tests en verde y una ejecución tan correcta como perfectamente aislada. Ese mecanismo lo hemos documentado dos veces, en inyección por fichero de instrucciones en AGENTS.md y CLAUDE.md y en envenenamiento de herramientas MCP, el mismo ataque entregado por la descripción de una herramienta.

Leer SKILL.md enteroAbrir cada fichero de scripts/¿Llamada de red o ruta de credenciales? ParaFijar el commit, no la ramaRevisar el diff en cada actualización

¿Y los servidores MCP y los hooks?

Ambos se configuran en el mismo directorio .agents, y ambos llegan con un valor por defecto sensato.

Los servidores MCP se declaran en ~/.gemini/config/mcp_config.json o .agents/mcp_config.json, y «por defecto, las herramientas MCP no configuradas funcionan en modo Ask y requieren tu aprobación antes de ejecutarse». Es el valor correcto. La reserva es la misma que con los skills: la aprobación recae sobre la llamada, el envenenamiento está en la descripción, y el modelo ya la ha leído cuando a ti te preguntan algo.

Para un equipo de seguridad, los hooks son la mitad interesante. Viven en un hooks.json bajo ~/.gemini/config/ o .agents/ y «permiten ejecutar scripts o comandos de shell personalizados en puntos concretos del bucle de ejecución de Antigravity»: PreToolUse, PostToolUse, PreInvocation, PostInvocation y Stop. Un hook PreToolUse puede devolver "decision": "ask", que «pregunta al usuario pero respeta los ajustes de Always Allow», o "force_ask", que «pregunta siempre al usuario, ignorando los permisos cacheados».

Ese segundo valor es lo único del producto que un clic cansado de hace tres semanas no puede preautorizar en silencio. La regla que de verdad no te puedes permitir perder tiene por tanto su sitio detrás de force_ask, y en ningún otro lado.

¿Un GEMINI.md hace que el agente cumpla tus reglas?

No de la forma que sugiere la existencia del fichero. Las reglas globales «viven en ~/.gemini/GEMINI.md», las de workspace «en la carpeta .agents/rules», y «los ficheros de reglas están limitados a 12.000 caracteres cada uno». Lo que no aparece por ninguna parte en esa documentación es la afirmación de que el agente las vaya a seguir, y esa contención está bien ganada.

Medimos el fichero equivalente en otro agente y publicamos el resultado. Noventa ejecuciones autónomas, treinta tickets de desarrollo, un repositorio, un modelo, y una sola variable manipulada: el canal por el que el agente podía conocer las 49 reglas de negocio y cumplimiento de la plataforma. Una sección de reglas escrita a mano, de forma realista, implementó exactamente 7 especificaciones de 55. Sin ningún fichero de reglas: 7 de 55 también, el mismo resultado. El método y los fallos están en ¿Claude Code sigue tu CLAUDE.md?, y el mecanismo no tiene nada de exclusivo de Anthropic, porque un documento leído una sola vez al arrancar la sesión queda a treinta mil tokens de distancia cuando llega la edición.

“

GEMINI.md es documentación. Una regla Deny y un hook force_ask son controles. No archives en lo primero lo que necesitabas en lo segundo.

¿Google entrena con el código que escribes en Antigravity?

Lo que se recoge lo enuncia la página de ajustes: «Antigravity recopila interacciones para evaluar, desarrollar y mejorar Antigravity y los modelos que lo sustentan.» La FAQ añade que «puedes desactivar la recogida de datos en cualquier momento desde el panel de Settings», y remite todo lo demás a las condiciones de servicio.

La postura de empresa es materialmente distinta, y más vale conocerla antes de que la reclame una revisión de seguridad. Google escribe que «los prompts, respuestas, código y telemetría de clientes empresariales nunca se almacenan fuera de tus entornos privados». Y escribe también que «tu telemetría de cliente y tus interacciones con el modelo se registran directamente en el proyecto de Google Cloud correspondiente a la licencia que elijas», con regiones global, us y eu y VPC Service Controls disponible.

Activada

recogida por defecto en el producto estándar, con interruptor en Settings

Tu proyecto

dónde se registran telemetría e interacciones con licencia de empresa

Sin publicar

periodo de retención, en toda la documentación que pudimos leer

No vamos a inferir un periodo de retención de una documentación que no lo indica, y un cuestionario de proveedores tampoco debería arriesgarse. Si la respuesta le importa a tus auditores, está en las condiciones de servicio y en tu contrato con Google, no en un artículo.

La pasada de diez minutos, en orden

1. Comprueba tu preset, no tus intenciones. En macOS y Linux, confirma que estás en Default y no en Turbo. En Windows, pon la Outside of Folder File Access Policy en Always Ask y activa Sandbox Mode donde el preset propio lo ofrezca.
2. Busca .agents/ antes de fiarte de un repositorio. Cuatro rutas de ahí dentro son política ejecutable que llega por una pull request: rules, skills, mcp_config.json y hooks.json. Merecen revisor, igual que un workflow de CI.
3. No escribas nunca command(*). Escribe los cinco comandos que tu proyecto lanza de verdad. El motor es lo bastante preciso como para que esos diez minutos salgan a cuenta.
4. Saca de la prosa la única regla que no puedes perder. Un hook PreToolUse que devuelve force_ask ignora los permisos cacheados. Una línea en GEMINI.md, no.
5. Resuelve la cuestión de la telemetría una sola vez, en Settings, y deja por escrito qué decidiste y por qué. Alguien lo preguntará.
6. Revisa el diff, porque nada de lo anterior revisa el diff.

Qué vendemos, dicho sin adornos

El punto seis es nuestro producto. Si los otros cinco están en este artículo es porque son gratis y van antes.

VibeDefend se instala en el entorno del agente, no en tu repositorio. Se engancha a la superficie de hooks descrita arriba, pone las reglas relevantes para el fichero que se está editando delante del modelo justo antes de la escritura, y luego analiza lo que sale. Lo que no hace es imponer: la mitad determinista es la guarda sobre la acción, mientras que la regla en el contexto sigue siendo un argumento. En nuestro propio estudio, un agente ignoró una regla que se le había servido trece veces. Preferimos nombrar cuál de las dos es un control antes que insinuar que lo son ambas, y el modelo completo está en seguridad de agentes de código IA.

Preguntas frecuentes

¿Antigravity es seguro?

Seguro frente al daño a nivel de máquina en macOS y Linux; indefinido en todas partes frente a los defectos a nivel de código. Los comandos de shell corren dentro de un sandbox del sistema activado por defecto en esas dos plataformas, con ~/.ssh y .env bloqueados y acceso a red limitado a los dominios aprobados. Pero nada en esa frontera examina el código que el agente escribe: una ejecución perfectamente aislada puede commitear un control de acceso roto.

¿Se puede usar Antigravity con el código de la empresa?

En macOS o Linux con el preset Default, la postura técnica es razonable, incluso mejor que la de varios competidores. En un entorno regulado lo deciden dos preguntas. ¿Tu parque es Windows, donde el sandbox todavía no está? ¿Y estás en la licencia de empresa, donde Google afirma que prompts, respuestas, código y telemetría «nunca se almacenan fuera de tus entornos privados» y se registran en tu propio proyecto de Google Cloud?

¿Tiene Antigravity un modo sandbox?

Sí, y activado por defecto en macOS y Linux. Linux usa namespaces del kernel que «aíslan el sistema de ficheros, ocultan los procesos del host y cortan la red», y macOS perfiles Seatbelt que «restringen el acceso al sistema de ficheros y las conexiones de socket». Con el preset Default, los comandos corren en ese sandbox con acceso limitado al workspace y a los directorios temporales, sin red y sin aprobación manual.

¿Por qué Antigravity dice que el sandbox no está soportado en Windows?

Porque la versión de Windows sigue ejecutando el sistema de permisos anterior. La documentación de Google indica que el sistema actualizado está «disponible actualmente en macOS y Linux, donde el sandbox viene activado por defecto», y que Windows «pasará al sistema de permisos unificado en una versión futura». Mientras tanto Windows expone otros controles: una Terminal Execution Policy, una Outside of Folder File Access Policy y un interruptor Sandbox Mode dentro de un preset propio.

¿Cómo se saltan los permisos en Antigravity, y conviene hacerlo?

Ningún flag que traerse de Claude Code: no existe equivalente de --dangerously-skip-permissions en línea de comandos. Las vías previstas son el preset Turbo y una regla command(*). En macOS o Linux ambas siguen corriendo dentro del sandbox, que es lo que las hace sobrevivibles; en Windows ese suelo no existe hoy. El mejor remedio contra la fatiga de aprobaciones es permitir los cinco comandos que tu proyecto lanza de verdad.

¿Puede Antigravity ejecutar comandos sin preguntarme?

Sí, con el preset Default en macOS y Linux, dentro del Terminal Sandbox. Es el comportamiento documentado y no una mala configuración: «los comandos pueden ejecutarse sin aprobación manual dentro del sandbox», donde el acceso se limita al workspace y a los directorios temporales, sin red. En Windows, los comandos no declarados siguen requiriendo aprobación manual.

¿Es seguro instalar un skill de Antigravity desde GitHub?

Trátalo como una dependencia, porque la documentación no ofrece ningún modelo de confianza. Un skill vive en .agents/skills/ o ~/.gemini/config/skills/, exige un SKILL.md y puede traer una carpeta scripts/, y el agente «decide en función del contexto» si usarlo sin que nadie se lo pida. El sandbox retiene los comandos que un skill ejecuta, no las instrucciones que da, y una instrucción maliciosa produce un diff limpio.

¿Puede un servidor MCP ejecutar herramientas sin aprobación en Antigravity?

No por defecto. La documentación dice que «las herramientas MCP no configuradas funcionan en modo Ask y requieren tu aprobación antes de ejecutarse», con la configuración en ~/.gemini/config/mcp_config.json o .agents/mcp_config.json. El riesgo que queda no es la ejecución sino la descripción de la herramienta, que el modelo lee antes de que a ti te pregunten nada.

¿Cómo se impone una regla en Antigravity?

Con un hook o una regla Deny, no con prosa. Un hook PreToolUse que devuelve "force_ask" «pregunta siempre al usuario, ignorando los permisos cacheados»: es el único punto de decisión que un Always Allow anterior no puede saltarse. Deny también gana a todo lo demás, ya que las reglas en conflicto se evalúan estrictamente como Deny > Ask > Allow.

¿Un GEMINI.md garantiza que el agente siga mis reglas?

No, y la documentación de Google nunca lo afirma. Las reglas viven en ~/.gemini/GEMINI.md o .agents/rules, limitadas a 12.000 caracteres por fichero. En nuestro estudio controlado de 90 ejecuciones sobre un agente comparable, una sección de reglas escrita a mano de forma realista implementó exactamente 7 especificaciones de 55: el mismo resultado que no tener ningún fichero de reglas. Deja ahí las convenciones adivinables, y pon los valores arbitrarios, códigos de error y umbrales donde el agente se los encuentra, en el momento de la edición.