La sandbox di Antigravity protegge il computer, non il codice

Antigravity è sicuro?

Sicuro contro il guasto che tutti immaginano, indefinito contro quello che costa davvero: sotto quella parola vivono tre domande diverse, e Antigravity risponde in modo molto disomogeneo.

Può rovinarti il portatile o portarsi via le chiavi? Su macOS e Linux, praticamente no, per come è fatto e senza che tu debba regolare niente. Può eseguire qualcosa che non avevi previsto? Solo se sei tu ad allargare le regole, e allargarle è esattamente quello che la gente sta cercando di capire come si fa. Può scrivere una vulnerabilità nel tuo prodotto, committarla e vedere i test diventare verdi? Sì. E nel prodotto non c'è nulla che punti a quel caso.

Partiamo da come il produttore definisce la cosa: antigravity.google parla di una «piattaforma di sviluppo agentica» i cui agenti «eseguono direttamente comandi shell». La superficie di rischio la dichiara quindi il fornitore stesso, e tutto quello che segue nella documentazione è un tentativo onesto di recintarla.

Cosa blocca davvero la sandbox di Antigravity?

Quattro confini, e a tenerli è il sistema operativo, non la buona volontà del modello.

Il preset predefinito tiene insieme le quattro cose. «I comandi da terminale girano dentro il Terminal Sandbox isolato, con accesso limitato al tuo workspace e alle directory temporanee, e senza accesso di rete. I comandi possono essere eseguiti senza approvazione manuale dentro la sandbox.»

Leggi quest'ultima frase per lo scambio che è. La finestra di approvazione, quella che qualunque sviluppatore finisce per cliccare alla cieca alla quarantesima volta, sparisce perché diventa inutile per la classe di comandi che può danneggiare solo una directory usa e getta. Resta uno scambio migliore di un agente che chiede su tutto e ti addestra a dire di sì.

Perché la sandbox non è supportata su Windows?

Perché la versione Windows gira ancora sul sistema di permessi precedente. La pagina della sandbox lo scrive a chiare lettere: «il sistema di permessi aggiornato di Antigravity è attualmente disponibile su macOS e Linux, dove la sandbox è abilitata di default». Sia quella pagina sia quella dei permessi riportano la stessa nota, Windows «passerà al sistema di permessi unificato in una versione futura».

Per un team questa non è una nota a piè di pagina. Le due piattaforme espongono impostazioni diverse sotto nomi diversi: una policy scritta su un Mac non si trasferisce su un portatile Windows, nemmeno ricopiandola con attenzione.

Si può leggere questa tabella come se Windows fosse più severo, ed è vero a metà: chiedere conferma per ogni comando non dichiarato è un controllo reale. La metà sbagliata arriva quando la risposta è sì. Su macOS un'approvazione data troppo in fretta gira in una scatola senza rete e senza vista su ~/.ssh. Su Windows, oggi, gira sulla tua macchina.

Come funzionano davvero i permessi di Antigravity?

Tre verbi e un motore di confronto. Le regole sono Deny, Ask o Allow, «le regole in conflitto vengono valutate rigorosamente per ordine di priorità: Deny > Ask > Allow», ed è così che un Deny scritto il trimestre scorso sopravvive all'Allow che aggiungi oggi di corsa.

Di solito è sul motore che le whitelist si rompono. Questo è migliore della media: una regola command(git) «per impostazione predefinita confronta letteralmente, per prefisso esatto di parola o token», regex: subentra quando serve un pattern, e command(*) quando hai deciso di smettere di leggere. E poi arriva il passaggio che quasi tutti gli articoli su questo prodotto raccontano al contrario.

Il bypass classico lo nomina la documentazione stessa: «alcuni costrutti di shell possono nascondere l'esecuzione di comandi arbitrari dietro un prefisso altrimenti innocuo», e cita la sostituzione di comando e di processo, $(...), i backtick, <(...). La sua risposta è stringere anziché allargare: «quando Antigravity ne rileva uno (o non riesce ad analizzare il comando in modo pulito), disabilita il confronto per prefisso sull'intera riga: il comando viene eseguito senza chiedere solo se una regola corrisponde alla riga completa, carattere per carattere.»

Cosa permette davvero «allow all commands»?

Tutto quello che una shell sa esprimere: dentro la sandbox su macOS e Linux, sul tuo host su Windows. È la risposta onesta alla domanda più cercata su questo prodotto, e la distanza fra quelle due metà è l'unica cosa interessante della domanda.

Vale la pena dirlo senza giri di parole, visto che vendiamo un prodotto di questa categoria: anche la nostra guardia sui comandi confronta testo letterale. Qualsiasi whitelist costruita sul confronto di stringhe, la nostra compresa, afferma qualcosa sui caratteri di un comando e niente sul suo effetto. Nel nostro studio controllato quelle guardie hanno prodotto tredici falsi positivi su trenta ticket; abbiamo pubblicato il numero invece di arrotondarlo. Il confronto di stringhe resta lo strumento giusto per un confine grossolano, e quello sbagliato per una decisione su cui ti giochi l'azienda.

Da qui l'ordine delle priorità. La sandbox è un controllo perché la impone il kernel; la lista di regole è solo una comodità, che decide ogni quanto vieni interrotto. Spegnere la prima perché la seconda smetta di disturbarti significa scambiare un controllo con una comodità.

Le skill di Antigravity sono sicure?

Nessuno l'ha detto, ed è proprio questo il risultato. «Antigravity skills» è la prima cosa che l'autocompletamento di Google propone dopo il nome del prodotto, in italiano come in francese, spagnolo, tedesco e portoghese, di solito seguita da «antigravity skills github». La gente le sta già scaricando. E la documentazione delle skill non spende una parola su come rivedere, valutare o fidarsi di quella di terzi.

Una skill è questo, secondo la stessa pagina: una cartella, in <workspace-root>/.agents/skills/<skill-folder>/ per un workspace o in ~/.gemini/config/skills/<skill-folder>/ per tutti, che richiede un SKILL.md e può portarsi dietro sottocartelle scripts/, examples/ e resources/. Non serve «dire esplicitamente all'agente di usare una skill». È lui che «decide in base al contesto».

Metti insieme questi tre fatti e hai una supply chain: una cartella arrivata da una pull request, con istruzioni ed eventualmente script eseguibili, che l'agente legge e applica senza che nessuno glielo chieda.

Qui la sandbox aiuta meno di quanto si creda, e la ragione va detta con precisione. Trattiene i comandi che una skill esegue; non trattiene le istruzioni che una skill dà. Un SKILL.md che spinga con discrezione l'agente verso una policy CORS permissiva, un controllo di proprietà dimenticato o una riga di log che stampa il token darà un diff pulito, una suite di test verde e un'esecuzione tanto riuscita quanto perfettamente isolata. Questo meccanismo lo abbiamo documentato due volte, in instruction file injection tramite AGENTS.md e CLAUDE.md e in tool poisoning su MCP, lo stesso attacco consegnato dalla descrizione di uno strumento.

Leggere SKILL.md per interoAprire ogni file dentro scripts/Chiamata di rete o percorso di credenziali? FermatiFissare il commit, non il branchRileggere il diff a ogni aggiornamento

E i server MCP e gli hook?

Entrambi si configurano nella stessa directory .agents, ed entrambi arrivano con un default ragionevole.

I server MCP si dichiarano in ~/.gemini/config/mcp_config.json oppure .agents/mcp_config.json, e «per impostazione predefinita gli strumenti MCP non configurati funzionano in modalità Ask e richiedono la tua approvazione prima dell'esecuzione». È il default giusto. La riserva è la stessa delle skill: l'approvazione riguarda la chiamata, l'avvelenamento sta nella descrizione, e il modello l'ha già letta quando a te viene chiesto qualcosa.

Per un team di sicurezza, gli hook sono la metà interessante. Vivono in un hooks.json sotto ~/.gemini/config/ o .agents/ e «permettono di eseguire script o comandi shell personalizzati in punti precisi del ciclo di esecuzione di Antigravity»: PreToolUse, PostToolUse, PreInvocation, PostInvocation e Stop. Un hook PreToolUse può restituire "decision": "ask", che «chiede all'utente ma rispetta le impostazioni Always Allow», oppure "force_ask", che «chiede sempre all'utente, ignorando i permessi in cache».

Quel secondo valore è l'unica cosa nel prodotto che un clic stanco di tre settimane fa non può pre-approvare in silenzio. La regola che davvero non puoi permetterti di perdere ha quindi il suo posto dietro force_ask, e da nessun'altra parte.

Un GEMINI.md basta a far rispettare le tue regole?

Non nel modo che l'esistenza del file lascia intendere. Le regole globali «vivono in ~/.gemini/GEMINI.md», quelle di workspace «nella cartella .agents/rules», e «i file di regole sono limitati a 12.000 caratteri ciascuno». Quello che in quella documentazione non compare da nessuna parte è l'affermazione che l'agente le seguirà, e questa reticenza è meritata.

Abbiamo misurato il file equivalente su un altro agente e pubblicato il risultato. Novanta esecuzioni autonome, trenta ticket di sviluppo, un repository, un modello, e una sola variabile manipolata: il canale attraverso cui l'agente poteva conoscere le 49 regole di business e conformità della piattaforma. Una sezione di regole scritta a mano, in modo realistico, ha implementato esattamente 7 specifiche su 55. Senza alcun file di regole: 7 su 55 anche lì, lo stesso punteggio. Metodo e fallimenti sono in Claude Code segue il tuo CLAUDE.md, e il meccanismo non ha nulla di specifico di Anthropic, perché un documento letto una volta all'avvio della sessione si ritrova a trentamila token di distanza quando arriva la modifica.

“

GEMINI.md è documentazione. Una regola Deny e un hook force_ask sono controlli. Non archiviare nel primo quello che ti serviva nei secondi.

Google addestra i modelli sul codice che scrivi in Antigravity?

Cosa viene raccolto lo dichiara la pagina delle impostazioni: «Antigravity raccoglie le interazioni per valutare, sviluppare e migliorare Antigravity e i modelli che lo alimentano.» La FAQ aggiunge che «puoi disattivare la raccolta dati in qualsiasi momento dal pannello Settings», e rimanda il resto ai termini di servizio.

La postura enterprise è nettamente diversa, e conviene conoscerla prima che la reclami una revisione di sicurezza. Google scrive che «prompt, risposte, codice e telemetria dei clienti enterprise non vengono mai memorizzati al di fuori dei tuoi ambienti privati». E scrive anche che «la tua telemetria cliente e le tue interazioni con il modello vengono registrate direttamente nel progetto Google Cloud corrispondente alla licenza che scegli», con regioni global, us e eu e VPC Service Controls disponibile.

Attiva

raccolta di default sul prodotto standard, con un interruttore in Settings

Il tuo progetto

dove finiscono telemetria e interazioni con licenza enterprise

Non pubblicato

periodo di conservazione, in tutta la documentazione consultabile

Non dedurremo un periodo di conservazione da una documentazione che non lo indica, e nemmeno un questionario fornitori dovrebbe rischiare. Se la risposta conta per i tuoi auditor, sta nei termini di servizio e nel tuo contratto con Google, non in un articolo.

Il giro da dieci minuti, in ordine

1. Controlla il preset, non le intenzioni. Su macOS e Linux, verifica di essere su Default e non su Turbo. Su Windows, metti la Outside of Folder File Access Policy su Always Ask e attiva Sandbox Mode dove il preset personalizzato lo offre.
2. Cerca .agents/ prima di fidarti di un repository. Quattro percorsi lì dentro sono policy eseguibile arrivata da una pull request: rules, skills, mcp_config.json e hooks.json. Meritano un revisore, esattamente come un workflow di CI.
3. Non scrivere mai command(*). Scrivi i cinque comandi che il tuo progetto lancia davvero. Il motore è abbastanza preciso da far rendere quei dieci minuti.
4. Togli dalla prosa l'unica regola che non puoi perdere. Un hook PreToolUse che restituisce force_ask ignora i permessi in cache. Una riga in GEMINI.md no.
5. Chiudi la questione telemetria una volta sola, in Settings, e metti per iscritto cosa hai deciso e perché. Qualcuno lo chiederà.
6. Rileggi il diff, perché niente di quanto sopra rilegge il diff.

Cosa vendiamo, detto chiaramente

Il punto sei è il nostro prodotto. Se gli altri cinque stanno in questo articolo è perché sono gratuiti e vengono prima.

VibeDefend si installa nell'ambiente dell'agente, non nel tuo repository. Si aggancia alla superficie di hook descritta sopra, mette le regole rilevanti per il file in modifica davanti al modello subito prima della scrittura, e poi analizza quello che esce. Quello che non fa è imporre: la metà deterministica è la guardia sull'azione, mentre la regola nel contesto resta un argomento. Nel nostro studio un agente ha scavalcato una regola che gli era stata servita tredici volte. Preferiamo dire quale delle due è un controllo piuttosto che lasciar credere che lo siano entrambe, e il modello completo è in sicurezza degli agenti di coding AI.

Domande frequenti

Antigravity è sicuro?

Sicuro contro i danni a livello di macchina su macOS e Linux; indefinito ovunque contro i difetti a livello di codice. I comandi shell girano dentro una sandbox di sistema attiva di default su quelle due piattaforme, con ~/.ssh e .env bloccati e accesso di rete limitato ai domini approvati. Ma nulla in quel confine esamina il codice che l'agente scrive: un'esecuzione perfettamente isolata può committare un controllo di accesso rotto.

Si può usare Antigravity sul codice aziendale?

Su macOS o Linux con il preset Default la postura tecnica è ragionevole, anzi migliore di quella di diversi concorrenti. In un contesto regolamentato decidono due domande. Il parco macchine è Windows, dove la sandbox non c'è ancora? E sei sulla licenza enterprise, dove Google afferma che prompt, risposte, codice e telemetria «non vengono mai memorizzati al di fuori dei tuoi ambienti privati» e finiscono nel tuo progetto Google Cloud?

Antigravity ha una modalità sandbox?

Sì, ed è attiva di default su macOS e Linux. Linux usa namespace del kernel che «isolano il filesystem, nascondono i processi dell'host e tagliano la rete», macOS profili Seatbelt che «limitano l'accesso al filesystem e le connessioni socket». Con il preset Default i comandi girano in quella sandbox con accesso limitato al workspace e alle directory temporanee, senza rete e senza approvazione manuale.

Perché Antigravity dice che la sandbox non è supportata su Windows?

Perché la versione Windows gira ancora sul sistema di permessi precedente. La documentazione di Google indica che il sistema aggiornato è «attualmente disponibile su macOS e Linux, dove la sandbox è abilitata di default», e che Windows «passerà al sistema di permessi unificato in una versione futura». Nel frattempo Windows espone altri controlli: una Terminal Execution Policy, una Outside of Folder File Access Policy e un interruttore Sandbox Mode dentro un preset personalizzato.

Come si saltano i permessi in Antigravity, e conviene?

Nessun flag da portarsi dietro da Claude Code: non esiste un equivalente di --dangerously-skip-permissions da riga di comando. Le strade previste sono il preset Turbo e una regola command(*). Su macOS o Linux entrambe girano comunque dentro la sandbox, ed è questo che le rende sopravvivibili; su Windows quel pavimento oggi non c'è. Il rimedio migliore alla stanchezza da approvazioni resta permettere i cinque comandi che il progetto lancia davvero.

Antigravity può eseguire comandi senza chiedermelo?

Sì, con il preset Default su macOS e Linux, dentro il Terminal Sandbox. È il comportamento documentato e non una configurazione sbagliata: «i comandi possono essere eseguiti senza approvazione manuale dentro la sandbox», dove l'accesso si limita al workspace e alle directory temporanee, senza rete. Su Windows i comandi non dichiarati richiedono ancora un'approvazione manuale.

È sicuro installare una skill di Antigravity presa da GitHub?

Trattala come una dipendenza, perché la documentazione non offre alcun modello di fiducia. Una skill vive in .agents/skills/ o ~/.gemini/config/skills/, richiede un SKILL.md e può portarsi dietro una cartella scripts/, e l'agente «decide in base al contesto» se usarla senza che nessuno glielo chieda. La sandbox trattiene i comandi che una skill esegue, non le istruzioni che dà, e un'istruzione malevola produce un diff pulito.

Un server MCP può eseguire strumenti senza approvazione in Antigravity?

Non di default. La documentazione dice che «gli strumenti MCP non configurati funzionano in modalità Ask e richiedono la tua approvazione prima dell'esecuzione», con la configurazione in ~/.gemini/config/mcp_config.json o .agents/mcp_config.json. Il rischio residuo non è l'esecuzione ma la descrizione dello strumento, che il modello legge prima che a te venga chiesto qualsiasi cosa.

Come si impone una regola in Antigravity?

Con un hook o una regola Deny, non con la prosa. Un hook PreToolUse che restituisce "force_ask" «chiede sempre all'utente, ignorando i permessi in cache»: è l'unico punto di decisione che un Always Allow precedente non può aggirare. Anche Deny batte tutto il resto, dato che le regole in conflitto vengono valutate rigorosamente come Deny > Ask > Allow.

Un GEMINI.md garantisce che l'agente segua le mie regole?

No, e la documentazione di Google non lo sostiene mai. Le regole vivono in ~/.gemini/GEMINI.md o .agents/rules, limitate a 12.000 caratteri per file. Nel nostro studio controllato da 90 esecuzioni su un agente comparabile, una sezione di regole scritta a mano in modo realistico ha implementato esattamente 7 specifiche su 55: lo stesso punteggio ottenuto senza alcun file di regole. Lascia lì le convenzioni indovinabili, e metti valori arbitrari, codici di errore e soglie dove l'agente li incontra, al momento della modifica.