A sandbox do Antigravity protege a máquina, não o teu código

O Antigravity é seguro?

Seguro contra a falha que toda a gente imagina, indefinido contra aquela que custa dinheiro: debaixo da palavra vivem três perguntas distintas, e o Antigravity responde-lhes de forma muito desigual.

Pode dar cabo do teu portátil ou sair com as tuas chaves? Em macOS e Linux, praticamente não, por desenho e sem que mexas em nada. Pode executar algo que não pretendias? Só se fores tu a alargar as regras, e alargá-las é justamente o que as pessoas procuram saber fazer. Pode escrever uma vulnerabilidade no teu produto, fazer commit e ver os testes a verde? Pode. E não há nada no produto apontado a esse caso.

Comecemos pela definição do fabricante: o antigravity.google fala de uma «plataforma de desenvolvimento agêntica» cujos agentes «executam comandos de shell diretamente». A superfície de risco é, portanto, enunciada pelo próprio fornecedor, e tudo o que se segue na documentação é uma tentativa honesta de a vedar.

O que é que a sandbox do Antigravity bloqueia mesmo?

Quatro fronteiras, e quem as segura é o sistema operativo, não a boa vontade do modelo.

A predefinição junta as quatro coisas. «Os comandos de terminal correm dentro do Terminal Sandbox isolado, com acesso restrito ao teu workspace e aos diretórios temporários, e sem acesso à rede. Os comandos podem correr sem aprovação manual dentro da sandbox.»

Lê essa última frase pela troca que é. A janela de aprovação, aquela que qualquer programador acaba a clicar às cegas à quadragésima vez, desaparece porque se torna desnecessária para a classe de comando que só consegue estragar um diretório descartável. Continua a ser melhor troca do que um agente que pergunta por tudo e te treina a dizer que sim.

Por que razão a sandbox não é suportada no Windows?

Porque a versão Windows continua no sistema de permissões anterior. A página da sandbox di-lo com todas as letras: «o sistema de permissões atualizado do Antigravity está atualmente disponível em macOS e Linux, onde a sandbox está ativada por defeito». Tanto essa página como a das permissões trazem a mesma nota, o Windows «passará ao sistema de permissões unificado numa versão futura».

Para uma equipa isto não é um rodapé. As duas plataformas expõem definições diferentes sob nomes diferentes: uma política escrita num Mac não se transporta para um portátil Windows, nem copiada com cuidado.

Pode ler-se esta tabela como se o Windows fosse mais rigoroso, e é meia verdade: perguntar por cada comando não declarado é um controlo a sério. A metade errada chega quando a resposta é sim. Em macOS, uma aprovação dada depressa de mais corre numa caixa sem rede e sem vista para ~/.ssh. No Windows, hoje, corre na tua máquina.

Como funcionam realmente as permissões do Antigravity?

Três verbos e um motor de comparação. As regras são Deny, Ask ou Allow, «as regras em conflito são avaliadas estritamente por ordem de prioridade: Deny > Ask > Allow», e é assim que um Deny escrito no trimestre passado sobrevive ao Allow que acrescentas hoje à pressa.

Normalmente é no motor que as listas brancas se partem. Este é melhor do que a média: uma regra command(git) «compara por defeito, literalmente, por prefixo exato de palavra ou token», regex: entra quando precisas de um padrão, e command(*) quando decidiste deixar de ler. E depois chega a passagem que a maioria dos artigos sobre este produto conta ao contrário.

O contorno clássico é a própria documentação que o nomeia: «certas construções de shell conseguem esconder a execução de comandos arbitrários por trás de um prefixo à partida inofensivo», e cita a substituição de comandos e de processos, $(...), as plicas invertidas, <(...). A resposta dela é apertar em vez de alargar: «quando o Antigravity deteta alguma destas (ou não consegue analisar o comando de forma limpa), desativa a comparação por prefixo para a linha inteira: o comando só corre sem perguntar se uma regra corresponder à linha completa, caractere a caractere.»

O que é que «allow all commands» permite mesmo?

Tudo o que uma shell saiba exprimir: dentro da sandbox em macOS e Linux, sobre o teu host no Windows. É a resposta honesta à pergunta mais procurada sobre este produto, e a distância entre essas duas metades é o que torna a pergunta interessante.

Vale a pena dizê-lo sem rodeios, porque vendemos um produto desta categoria: a nossa própria guarda de comandos também compara texto literal. Qualquer lista branca construída sobre comparação de cadeias, a nossa incluída, afirma alguma coisa sobre os caracteres de um comando e nada sobre o efeito dele. No nosso estudo controlado, essas guardas produziram treze falsos positivos ao longo de trinta tickets; publicámos o número em vez de o arredondar. A comparação de cadeias continua a ser a ferramenta certa para uma fronteira grosseira, e a errada para uma decisão em que arriscas a empresa.

Daí a ordem das prioridades. A sandbox é um controlo porque é o kernel que a impõe; a lista de regras é apenas um conforto, que decide de quantas em quantas vezes és interrompido. Desligar a primeira para a segunda deixar de te incomodar é trocar um controlo por um conforto.

As skills do Antigravity são seguras?

Ninguém o disse, e é esse justamente o achado. «Antigravity skills» é a primeira coisa que o preenchimento automático da Google oferece a seguir ao nome do produto, em português tal como em francês, espanhol, alemão e italiano, normalmente seguida de «antigravity skills github». As pessoas já as andam a descarregar. E a documentação das skills não diz uma palavra sobre como rever, avaliar ou confiar numa de terceiros.

Uma skill é isto, segundo essa mesma página: uma pasta, em <workspace-root>/.agents/skills/<skill-folder>/ para um workspace ou em ~/.gemini/config/skills/<skill-folder>/ para todos, que exige um SKILL.md e pode trazer subpastas scripts/, examples/ e resources/. Não é preciso «dizer explicitamente ao agente para usar uma skill». Ele «decide em função do contexto».

Junta estes três factos e tens uma supply chain: uma pasta chegada por uma pull request, com instruções e eventualmente scripts executáveis, que o agente lê e aplica sem que ninguém lho peça.

Aqui a sandbox ajuda menos do que se supõe, e a razão merece ser dita com precisão. Ela retém os comandos que uma skill executa; não retém as instruções que uma skill dá. Um SKILL.md que empurre discretamente o agente para uma política CORS permissiva, um controlo de propriedade esquecido ou uma linha de log que imprime o token dará um diff limpo, uma bateria de testes a verde e uma execução tão bem sucedida quanto perfeitamente isolada. Documentámos esse mecanismo duas vezes, em injeção por ficheiro de instruções em AGENTS.md e CLAUDE.md e em envenenamento de ferramentas MCP, o mesmo ataque entregue pela descrição de uma ferramenta.

Ler o SKILL.md até ao fimAbrir cada ficheiro de scripts/Chamada de rede ou caminho de credenciais? PáraFixar o commit, não o ramoRever o diff em cada atualização

E os servidores MCP e os hooks?

Ambos se configuram no mesmo diretório .agents, e ambos chegam com um valor por defeito sensato.

Os servidores MCP declaram-se em ~/.gemini/config/mcp_config.json ou .agents/mcp_config.json, e «por defeito, as ferramentas MCP não configuradas funcionam em modo Ask e exigem a tua aprovação antes de executar». É o valor certo. A ressalva é a mesma das skills: a aprovação recai sobre a chamada, o envenenamento está na descrição, e o modelo já a leu quando te perguntam seja o que for.

Para uma equipa de segurança, os hooks são a metade interessante. Vivem num hooks.json em ~/.gemini/config/ ou .agents/ e «permitem correr scripts ou comandos de shell personalizados em pontos específicos do ciclo de execução do Antigravity»: PreToolUse, PostToolUse, PreInvocation, PostInvocation e Stop. Um hook PreToolUse pode devolver "decision": "ask", que «pergunta ao utilizador mas respeita as definições Always Allow», ou "force_ask", que «pergunta sempre ao utilizador, ignorando as permissões em cache».

Esse segundo valor é a única coisa do produto que um clique cansado de há três semanas não consegue pré-aprovar em silêncio. A regra que mesmo não podes perder tem, por isso, o seu lugar atrás de force_ask, e em mais lado nenhum.

Um GEMINI.md faz o agente cumprir as tuas regras?

Não da maneira que a existência do ficheiro sugere. As regras globais «vivem em ~/.gemini/GEMINI.md», as de workspace «na pasta .agents/rules», e «os ficheiros de regras estão limitados a 12 000 caracteres cada um». O que não aparece em parte nenhuma dessa documentação é a afirmação de que o agente as vai seguir, e essa contenção é merecida.

Medimos o ficheiro equivalente noutro agente e publicámos o resultado. Noventa execuções autónomas, trinta tickets de programação, um repositório, um modelo, e uma única variável manipulada: o canal pelo qual o agente podia conhecer as 49 regras de negócio e conformidade da plataforma. Uma secção de regras escrita à mão, de forma realista, implementou exatamente 7 especificações em 55. Sem ficheiro de regras nenhum: 7 em 55 também, o mesmo resultado. O método e as falhas estão em o Claude Code segue o teu CLAUDE.md, e o mecanismo nada tem de específico da Anthropic, porque um documento lido uma vez no arranque da sessão fica a trinta mil tokens de distância quando chega a edição.

“

O GEMINI.md é documentação. Uma regra Deny e um hook force_ask são controlos. Não arquives no primeiro aquilo de que precisavas nos segundos.

A Google treina os modelos com o teu código?

O que é recolhido enuncia-o a página de definições: «o Antigravity recolhe interações para avaliar, desenvolver e melhorar o Antigravity e os modelos que o sustentam.» A FAQ acrescenta que «podes desativar a recolha de dados a qualquer momento a partir do painel Settings», e remete o resto para os termos de serviço.

A postura empresarial é materialmente diferente, e mais vale conhecê-la antes de uma revisão de segurança a pedir. A Google escreve que «os prompts, respostas, código e telemetria dos clientes empresariais nunca são armazenados fora dos teus ambientes privados». E escreve também que «a tua telemetria de cliente e as tuas interações com o modelo são registadas diretamente no projeto Google Cloud correspondente à licença que escolheres», com regiões global, us e eu e VPC Service Controls disponível.

Ligada

recolha por defeito no produto padrão, com interruptor em Settings

O teu projeto

onde ficam telemetria e interações com o modelo na licença empresarial

Não publicado

período de retenção, em toda a documentação que conseguimos ler

Não vamos deduzir um período de retenção de uma documentação que não o indica, e um questionário de fornecedores também não se devia arriscar. Se a resposta conta para os teus auditores, está nos termos de serviço e no teu contrato com a Google, não num artigo.

A passagem de dez minutos, por ordem

1. Verifica a tua predefinição, não as tuas intenções. Em macOS e Linux, confirma que estás em Default e não em Turbo. No Windows, põe a Outside of Folder File Access Policy em Always Ask e liga o Sandbox Mode onde a predefinição própria o oferecer.
2. Procura .agents/ antes de confiares num repositório. Quatro caminhos lá dentro são política executável que chega por uma pull request: rules, skills, mcp_config.json e hooks.json. Merecem um revisor, tal como um workflow de CI.
3. Nunca escrevas command(*). Escreve os cinco comandos que o teu projeto corre mesmo. O motor é suficientemente preciso para esses dez minutos compensarem.
4. Tira da prosa a única regra que não podes perder. Um hook PreToolUse que devolve force_ask ignora as permissões em cache. Uma linha no GEMINI.md, não.
5. Decide a questão da telemetria de uma vez, em Settings, e deixa escrito o que decidiste e porquê. Alguém vai perguntar.
6. Revê o diff, porque nada do que está acima revê o diff.

O que vendemos, dito sem rodeios

O ponto seis é o nosso produto. Se os outros cinco estão neste artigo é porque são gratuitos e vêm antes.

O VibeDefend instala-se no ambiente do agente, não no teu repositório. Liga-se à superfície de hooks descrita acima, põe as regras relevantes para o ficheiro em edição à frente do modelo mesmo antes da escrita, e depois analisa o que sai. O que não faz é impor: a metade determinista é a guarda sobre a ação, ao passo que a regra no contexto continua a ser um argumento. No nosso próprio estudo, um agente ignorou uma regra que lhe tinha sido servida treze vezes. Preferimos dizer qual das duas é um controlo a deixar supor que ambas o são, e o modelo completo está em segurança de agentes de código IA.

Perguntas frequentes

O Antigravity é seguro?

Seguro contra os estragos ao nível da máquina em macOS e Linux; indefinido em todo o lado contra os defeitos ao nível do código. Os comandos de shell correm dentro de uma sandbox do sistema ativada por defeito nessas duas plataformas, com ~/.ssh e .env bloqueados e acesso à rede limitado aos domínios aprovados. Mas nada nessa fronteira examina o código que o agente escreve: uma execução perfeitamente isolada pode fazer commit de um controlo de acesso partido.

Dá para usar o Antigravity com o código da empresa?

Em macOS ou Linux com a predefinição Default, a postura técnica é razoável, melhor até do que a de vários concorrentes. Num contexto regulado, duas perguntas decidem. O teu parque é Windows, onde a sandbox ainda não existe? E estás na licença empresarial, onde a Google afirma que prompts, respostas, código e telemetria «nunca são armazenados fora dos teus ambientes privados» e ficam registados no teu próprio projeto Google Cloud?

O Antigravity tem modo sandbox?

Tem, e ligado por defeito em macOS e Linux. O Linux usa namespaces do kernel que «isolam o sistema de ficheiros, escondem os processos do host e cortam a rede», e o macOS perfis Seatbelt que «restringem o acesso ao sistema de ficheiros e as ligações de socket». Com a predefinição Default, os comandos correm nessa sandbox com acesso limitado ao workspace e aos diretórios temporários, sem rede e sem aprovação manual.

Por que razão o Antigravity diz que a sandbox não é suportada no Windows?

Porque a versão Windows ainda corre o sistema de permissões anterior. A documentação da Google indica que o sistema atualizado está «atualmente disponível em macOS e Linux, onde a sandbox está ativada por defeito», e que o Windows «passará ao sistema de permissões unificado numa versão futura». Entretanto o Windows expõe outros controlos: uma Terminal Execution Policy, uma Outside of Folder File Access Policy e um interruptor Sandbox Mode dentro de uma predefinição própria.

Como é que se saltam as permissões no Antigravity, e convém?

Nenhum flag para trazer do Claude Code: não existe equivalente de --dangerously-skip-permissions na linha de comandos. As vias previstas são a predefinição Turbo e uma regra command(*). Em macOS ou Linux, ambas continuam a correr dentro da sandbox, que é o que as torna sobreviváveis; no Windows esse chão não existe hoje. O melhor remédio para a fadiga de aprovações é permitir os cinco comandos que o teu projeto corre mesmo.

O Antigravity pode correr comandos sem me perguntar?

Pode, com a predefinição Default em macOS e Linux, dentro do Terminal Sandbox. É o comportamento documentado e não uma má configuração: «os comandos podem correr sem aprovação manual dentro da sandbox», onde o acesso se limita ao workspace e aos diretórios temporários, sem rede. No Windows, os comandos não declarados continuam a exigir aprovação manual.

É seguro instalar uma skill do Antigravity vinda do GitHub?

Trata-a como uma dependência, porque a documentação não oferece qualquer modelo de confiança. Uma skill vive em .agents/skills/ ou ~/.gemini/config/skills/, exige um SKILL.md e pode trazer uma pasta scripts/, e o agente «decide em função do contexto» se a usa sem que ninguém lho peça. A sandbox retém os comandos que uma skill executa, não as instruções que dá, e uma instrução maliciosa produz um diff limpo.

Um servidor MCP pode executar ferramentas sem aprovação no Antigravity?

Por defeito não. A documentação diz que «as ferramentas MCP não configuradas funcionam em modo Ask e exigem a tua aprovação antes de executar», com a configuração em ~/.gemini/config/mcp_config.json ou .agents/mcp_config.json. O risco que sobra não é a execução mas a descrição da ferramenta, que o modelo leu antes de te perguntarem o que quer que seja.

Como se impõe uma regra no Antigravity?

Com um hook ou uma regra Deny, não com prosa. Um hook PreToolUse que devolve "force_ask" «pergunta sempre ao utilizador, ignorando as permissões em cache»: é o único ponto de decisão que um Always Allow anterior não consegue contornar. Deny também ganha a tudo o resto, já que as regras em conflito são avaliadas estritamente como Deny > Ask > Allow.

Um GEMINI.md garante que o agente segue as minhas regras?

Não, e a documentação da Google nunca o afirma. As regras vivem em ~/.gemini/GEMINI.md ou .agents/rules, limitadas a 12 000 caracteres por ficheiro. No nosso estudo controlado de 90 execuções sobre um agente comparável, uma secção de regras escrita à mão de forma realista implementou exatamente 7 especificações em 55: o mesmo resultado de não ter ficheiro de regras nenhum. Deixa lá as convenções adivinháveis, e põe os valores arbitrários, códigos de erro e limiares onde o agente os encontra, no momento da edição.