La sandbox d'Antigravity protège votre poste, pas votre code

Google Antigravity est-il sûr ?

Sûr contre la panne que tout le monde imagine, indéterminé contre celle qui coûte de l'argent : le mot recouvre trois questions distinctes, et Antigravity y répond très inégalement.

Peut-il casser votre poste ou repartir avec vos clés ? Sur macOS et Linux, à peu près non, par conception, sans que vous ayez rien à régler. Peut-il exécuter quelque chose que vous n'aviez pas prévu ? Seulement si vous élargissez les règles vous-même, et c'est précisément ce que les gens cherchent à faire. Peut-il écrire une vulnérabilité dans votre produit, la committer, et voir la CI passer au vert ? Oui. Et rien dans l'outil ne vise ce cas.

Partons de la définition de l'éditeur : antigravity.google parle d'une « plateforme de développement agentique » dont les agents « exécutent directement des commandes shell ». La surface de risque est donc énoncée par le fournisseur lui-même, et tout le reste de la documentation est une tentative honnête de la clôturer.

Que bloque réellement la sandbox d'Antigravity ?

Quatre frontières, et c'est le système d'exploitation qui les tient, pas la bonne volonté du modèle.

Le preset par défaut assemble les quatre. « Les commandes du terminal s'exécutent dans le Terminal Sandbox isolé, avec un accès restreint à votre workspace et aux répertoires temporaires, et sans accès réseau. Les commandes peuvent s'exécuter sans approbation manuelle dans la sandbox. »

Lisez cette dernière phrase comme le marché qu'elle est. La fenêtre d'approbation, celle que tout développeur finit par cliquer en aveugle à la quarantième occurrence, disparaît parce qu'elle devient inutile pour la classe de commandes qui ne peut abîmer qu'un répertoire jetable. Le marché reste meilleur que celui d'un agent qui demande tout et vous entraîne à dire oui.

Pourquoi la sandbox n'est-elle pas supportée sous Windows ?

Parce que la version Windows tourne encore sur l'ancien système de permissions. La page dédiée l'écrit noir sur blanc : « le nouveau système de permissions d'Antigravity est actuellement disponible sur macOS et Linux, où la sandbox est activée par défaut ». Les pages sandbox et permissions portent la même note, Windows « passera au système de permissions unifié dans une prochaine version ».

Pour une équipe, ce n'est pas un détail. Les deux plateformes exposent des réglages différents sous des noms différents : une politique écrite sur un Mac ne se transporte pas sur un poste Windows, même recopiée avec soin.

On peut lire ce tableau comme si Windows était plus strict, et c'est à moitié vrai : demander confirmation pour chaque commande non déclarée est un vrai contrôle. La moitié fausse arrive quand la réponse est oui. Sur macOS, une approbation donnée trop vite s'exécute dans une boîte sans réseau et sans vue sur ~/.ssh. Sous Windows, aujourd'hui, elle s'exécute sur votre machine.

Comment fonctionnent vraiment les permissions d'Antigravity ?

Trois verbes et un moteur de correspondance. Les règles sont Deny, Ask ou Allow, « les règles conflictuelles sont strictement évaluées par ordre de priorité : Deny > Ask > Allow », et c'est ainsi qu'un Deny écrit le trimestre dernier survit à un Allow ajouté ce matin dans l'urgence.

D'habitude, c'est sur le moteur que les listes blanches se cassent. Celui-ci est meilleur que la moyenne : une règle command(git) « correspond par défaut, littéralement, par préfixe exact de mot ou de token », regex: prend le relais quand il faut un motif, et command(*) quand on a décidé d'arrêter de lire. Vient ensuite le passage que la plupart des articles sur ce produit prennent à l'envers.

Le contournement classique, la documentation le nomme elle-même : « certaines constructions shell peuvent dissimuler l'exécution de commandes arbitraires derrière un préfixe par ailleurs anodin », et elle cite la substitution de commande et de processus, $(...), les backticks, <(...). Sa réponse est de resserrer plutôt que d'élargir : « lorsqu'Antigravity en détecte une, ou qu'il ne parvient pas à analyser proprement la commande, il désactive la correspondance par préfixe pour la ligne entière : la commande ne s'exécute sans demande que si une règle correspond à la ligne complète, caractère pour caractère. »

Qu'autorise vraiment « allow all commands » ?

Tout ce qu'un shell sait exprimer : dans la sandbox sur macOS et Linux, sur votre hôte sous Windows. C'est la réponse honnête à la question la plus cherchée sur ce produit, et l'écart entre ces deux moitiés fait tout l'intérêt de la question.

Disons-le franchement, puisque nous vendons un produit de cette catégorie : notre propre garde de commandes fonctionne elle aussi par correspondance littérale. Toute liste blanche bâtie sur de la comparaison de chaînes, la nôtre comprise, affirme quelque chose sur les caractères d'une commande et rien sur son effet. Dans notre étude contrôlée, ces gardes ont produit treize faux positifs sur trente tickets ; nous avons publié le nombre au lieu de l'arrondir. La comparaison de chaînes reste le bon outil pour une frontière grossière, et le mauvais pour une décision sur laquelle vous engagez l'entreprise.

D'où l'ordre des priorités. La sandbox est un contrôle parce que le noyau la fait respecter ; la liste de règles n'est qu'un confort, qui décide de la fréquence des interruptions. Couper la première pour que la seconde cesse de vous déranger, c'est échanger un contrôle contre un confort.

Les skills d'Antigravity sont-ils sûrs ?

Personne ne l'a dit, et c'est justement le résultat. « Antigravity skills » est la toute première suggestion que propose l'autocomplétion de Google après le nom du produit, en français comme en espagnol, en allemand, en italien et en portugais, le plus souvent suivie de « antigravity skills github ». Les gens en téléchargent déjà. Or la documentation des skills ne dit pas un mot de la façon de relire, d'évaluer ou de faire confiance à celui d'un tiers.

Voici ce qu'est un skill, d'après cette même page : un dossier, rangé dans <workspace-root>/.agents/skills/<skill-folder>/ pour un workspace ou dans ~/.gemini/config/skills/<skill-folder>/ pour tous, qui exige un SKILL.md et peut embarquer des sous-dossiers scripts/, examples/ et resources/. Vous n'avez « pas besoin de dire explicitement à l'agent d'utiliser un skill ». Il « décide en fonction du contexte ».

Réunissez ces trois faits et vous obtenez une supply chain : un dossier arrivé par une pull request, contenant des instructions et éventuellement des scripts exécutables, que l'agent lit et applique sans que personne le lui demande.

La sandbox aide ici moins qu'on ne l'imagine, et la raison mérite d'être dite précisément. Elle retient les commandes qu'un skill exécute ; elle ne retient pas les instructions qu'un skill donne. Un SKILL.md qui oriente discrètement l'agent vers une politique CORS permissive, un contrôle de propriétaire oublié ou une ligne de log qui imprime le token produira un diff propre, une suite de tests au vert, et une exécution aussi parfaitement réussie que parfaitement sandboxée. Nous avons documenté ce mécanisme deux fois, pour l'injection par fichier d'instructions dans AGENTS.md et CLAUDE.md et pour l'empoisonnement d'outils MCP, la même attaque livrée par une description d'outil.

Lire SKILL.md en entierOuvrir chaque fichier de scripts/Un appel réseau, un chemin de credentials ? StopÉpingler le commit, pas la brancheRelire le diff à chaque mise à jour

Et les serveurs MCP, et les hooks ?

Tous deux se configurent dans le même répertoire .agents, et tous deux arrivent avec un défaut raisonnable.

Les serveurs MCP se déclarent dans ~/.gemini/config/mcp_config.json ou .agents/mcp_config.json, et « par défaut, les outils MCP non configurés fonctionnent en mode Ask et exigent votre approbation avant exécution ». C'est le bon défaut. La réserve est la même que pour les skills : l'approbation porte sur l'appel, l'empoisonnement est dans la description, et le modèle l'a déjà lue au moment où on vous demande quoi que ce soit.

Pour une équipe sécurité, les hooks sont la moitié intéressante. Ils vivent dans un hooks.json sous ~/.gemini/config/ ou .agents/ et « permettent d'exécuter des scripts ou des commandes shell personnalisés à des points précis de la boucle d'exécution d'Antigravity » : PreToolUse, PostToolUse, PreInvocation, PostInvocation et Stop. Un hook PreToolUse peut renvoyer "decision": "ask", qui « interroge l'utilisateur mais respecte les réglages Always Allow », ou "force_ask", qui « interroge toujours l'utilisateur, en ignorant les permissions mises en cache ».

Cette seconde valeur est la seule chose du produit qu'un clic fatigué d'il y a trois semaines ne peut pas pré-approuver en silence. La règle que vous ne pouvez vraiment pas vous permettre de perdre a donc sa place derrière force_ask, et nulle part ailleurs.

Un GEMINI.md suffit-il à faire respecter vos règles ?

Pas de la façon que l'existence du fichier laisse croire. Les règles globales « vivent dans ~/.gemini/GEMINI.md », les règles de workspace « dans le dossier .agents/rules », et « les fichiers de règles sont limités à 12 000 caractères chacun ». Ce qu'on ne trouve nulle part dans cette documentation, c'est l'affirmation que l'agent les suivra, et cette retenue est méritée.

Nous avons mesuré l'équivalent sur un autre agent, et publié le résultat. Quatre-vingt-dix exécutions autonomes, trente tickets de développeur, un seul dépôt, un seul modèle, et une seule variable manipulée : le canal par lequel l'agent pouvait connaître les 49 règles métier et conformité de la plateforme. Une section de règles écrite à la main, de façon réaliste, a implémenté exactement 7 spécificités sur 55. Sans aucun fichier de règles : 7 sur 55 également, le même score. La méthode et les échecs sont dans Claude Code respecte-t-il le CLAUDE.md, et le mécanisme n'a rien de spécifique à Anthropic, un document lu une fois au démarrage de la session se retrouvant à trente mille tokens de distance au moment de l'édition.

“

Le GEMINI.md, c'est de la documentation. Une règle Deny et un hook force_ask, ce sont des contrôles. Ne rangez pas dans le premier ce dont vous aviez besoin dans les seconds.

Google entraîne-t-il ses modèles sur votre code ?

Ce qui est collecté, la page des réglages l'énonce : « Antigravity collecte les interactions pour évaluer, développer et améliorer Antigravity ainsi que les modèles qui le font fonctionner. » La FAQ ajoute qu'« on peut se désinscrire de la collecte de données à tout moment depuis le panneau Settings », et renvoie le reste aux conditions d'utilisation.

La posture entreprise est nettement différente, et il vaut mieux la connaître avant qu'une revue de sécurité ne la réclame. Google écrit que « les prompts, réponses, code et télémétrie des clients entreprise ne sont jamais stockés en dehors de vos environnements privés ». Il écrit aussi que « votre télémétrie client et vos interactions avec le modèle sont journalisées directement dans le projet Google Cloud correspondant à la licence que vous choisissez », avec des régions global, us et eu et la disponibilité de VPC Service Controls.

Activée

collecte par défaut sur le produit standard, avec un interrupteur dans Settings

Votre projet

où atterrissent télémétrie et interactions modèle en licence entreprise

Non publiée

durée de rétention, dans toutes les pages de documentation consultées

Nous ne déduirons pas une durée de rétention d'une documentation qui n'en donne aucune, et un questionnaire fournisseur ne devrait pas s'y risquer davantage. Si la réponse compte pour vos auditeurs, elle se trouve dans les conditions d'utilisation et dans votre contrat Google, pas dans un article.

La passe de dix minutes, dans l'ordre

1. Vérifiez votre preset, pas vos intentions. Sur macOS et Linux, confirmez que vous êtes sur Default et non sur Turbo. Sur Windows, mettez la Outside of Folder File Access Policy sur Always Ask et activez Sandbox Mode là où le preset personnalisé le propose.
2. Cherchez .agents/ avant de faire confiance à un dépôt. Quatre chemins y constituent de la politique exécutable arrivée par une pull request : rules, skills, mcp_config.json et hooks.json. Ils méritent un relecteur, au même titre qu'un workflow de CI.
3. N'écrivez jamais command(*). Écrivez les cinq commandes que votre projet lance vraiment. Le moteur est assez précis pour que ces dix minutes soient rentables.
4. Sortez de la prose la seule règle que vous ne pouvez pas perdre. Un hook PreToolUse qui renvoie force_ask ignore les permissions en cache. Une ligne dans GEMINI.md, non.
5. Tranchez la question de la télémétrie une bonne fois, dans Settings, et notez ce que vous avez décidé et pourquoi. Quelqu'un vous le demandera.
6. Relisez le diff, parce que rien de ce qui précède ne relit le diff.

Ce que nous vendons, dit simplement

Le point six est notre produit. Si les cinq autres figurent dans cet article, c'est qu'ils sont gratuits et qu'ils passent avant.

VibeDefend s'installe dans l'environnement de l'agent, pas dans votre dépôt. Il se branche sur la surface de hooks décrite plus haut, place les règles pertinentes pour le fichier en cours d'édition sous les yeux du modèle juste avant l'écriture, puis analyse ce qui en sort. Ce qu'il ne fait pas, c'est appliquer : la moitié déterministe, c'est le garde sur l'action, tandis que la règle dans le contexte reste un argument. Dans notre propre étude, un agent est passé outre une règle qui lui avait été servie treize fois. Nous préférons nommer laquelle des deux est un contrôle plutôt que de laisser croire que les deux le sont, et le modèle complet est dans sécurité des agents de code IA.

Questions fréquentes

Google Antigravity est-il sûr ?

Sûr contre les dégâts au niveau de la machine sur macOS et Linux ; indéterminé partout contre les défauts au niveau du code. Les commandes shell tournent dans une sandbox système activée par défaut sur ces deux plateformes, avec ~/.ssh et .env bloqués et un accès réseau limité aux domaines approuvés. Mais rien dans cette frontière n'examine le code que l'agent écrit : une exécution parfaitement sandboxée peut committer un contrôle d'accès cassé.

Peut-on utiliser Antigravity sur le code de l'entreprise ?

Sur macOS ou Linux avec le preset Default, la posture technique est raisonnable, meilleure même que celle de plusieurs concurrents. Pour une équipe régulée, deux questions tranchent. Votre parc est-il sous Windows, où la sandbox n'est pas encore en place ? Et êtes-vous sur la licence entreprise, où Google affirme que prompts, réponses, code et télémétrie « ne sont jamais stockés en dehors de vos environnements privés » et sont journalisés dans votre propre projet Google Cloud ?

Antigravity a-t-il un mode sandbox ?

Oui, actif par défaut sur macOS et Linux. Linux s'appuie sur des namespaces du noyau qui « isolent le système de fichiers, masquent les processus de l'hôte et coupent le réseau », macOS sur des profils Seatbelt qui « restreignent l'accès au système de fichiers et les connexions socket ». Sous le preset Default, les commandes tournent dans cette sandbox avec un accès limité au workspace et aux répertoires temporaires, sans réseau et sans approbation manuelle.

Pourquoi Antigravity indique-t-il que la sandbox n'est pas supportée sous Windows ?

Parce que la version Windows tourne encore sur l'ancien système de permissions. La documentation de Google indique que le nouveau système est « actuellement disponible sur macOS et Linux, où la sandbox est activée par défaut », et que Windows « passera au système de permissions unifié dans une prochaine version ». En attendant, Windows expose d'autres réglages : une Terminal Execution Policy, une Outside of Folder File Access Policy et un interrupteur Sandbox Mode dans un preset personnalisé.

Comment contourner les permissions d'Antigravity, et faut-il le faire ?

Aucun flag à transposer depuis Claude Code : il n'existe pas d'équivalent de --dangerously-skip-permissions en ligne de commande. Les voies prévues sont le preset Turbo et une règle command(*). Sur macOS ou Linux, les deux tournent encore dans la sandbox, ce qui les rend survivables ; sous Windows, ce plancher n'existe pas aujourd'hui. Le meilleur remède à la fatigue d'approbation reste d'autoriser les cinq commandes que votre projet lance vraiment.

Antigravity peut-il lancer des commandes sans me demander ?

Oui, sous le preset Default sur macOS et Linux, à l'intérieur du Terminal Sandbox. C'est le comportement documenté et non une mauvaise configuration : « les commandes peuvent s'exécuter sans approbation manuelle dans la sandbox », où l'accès se limite au workspace et aux répertoires temporaires, sans réseau. Sous Windows, les commandes non déclarées exigent toujours une approbation manuelle.

Peut-on installer un skill Antigravity trouvé sur GitHub ?

Traitez-le comme une dépendance, car la documentation ne propose aucun modèle de confiance. Un skill vit dans .agents/skills/ ou ~/.gemini/config/skills/, exige un SKILL.md et peut embarquer un dossier scripts/, et l'agent « décide en fonction du contexte » de s'en servir sans qu'on le lui demande. La sandbox retient les commandes qu'un skill exécute, pas les instructions qu'il donne, et une instruction malveillante produit un diff propre.

Un serveur MCP peut-il exécuter des outils sans approbation dans Antigravity ?

Pas par défaut. La documentation indique que « les outils MCP non configurés fonctionnent en mode Ask et exigent votre approbation avant exécution », la configuration se trouvant dans ~/.gemini/config/mcp_config.json ou .agents/mcp_config.json. Le risque résiduel n'est pas l'exécution mais la description de l'outil, que le modèle a lue avant qu'on vous demande quoi que ce soit.

Comment imposer une règle dans Antigravity ?

Avec un hook ou une règle Deny, pas avec de la prose. Un hook PreToolUse qui renvoie "force_ask" « interroge toujours l'utilisateur, en ignorant les permissions mises en cache » : c'est le seul point de décision qu'un Always Allow antérieur ne peut pas court-circuiter. Deny l'emporte également sur tout le reste, puisque les règles conflictuelles sont évaluées strictement dans l'ordre Deny > Ask > Allow.

Un GEMINI.md garantit-il que l'agent suivra mes règles ?

Non, et la documentation de Google ne le prétend jamais. Les règles vivent dans ~/.gemini/GEMINI.md ou .agents/rules, plafonnées à 12 000 caractères par fichier. Dans notre étude contrôlée de 90 exécutions sur un agent comparable, une section de règles écrite à la main de façon réaliste a implémenté exactement 7 spécificités sur 55 : le score obtenu sans aucun fichier de règles. Gardez-y les conventions devinables, et placez vos valeurs arbitraires, codes d'erreur et seuils là où l'agent les rencontre, au moment de l'édition.