Google voulait faire de Antigravity son IDE du futur : un environnement de développement construit autour de l’IA, fluide, automatisé, capable d’agir comme un véritable collègue virtuel.
Mais quelques semaines après son lancement, l’outil fait déjà l’objet d’alertes sévères.
Selon une étude de PromptArmor, l’IDE laisse son agent IA exécuter des commandes automatiquement dans certaines configurations par défaut. Un comportement qui ouvre la voie à des dérives critiques — dont certaines ont déjà été démontrées en conditions réelles.
Quand un simple fichier devient une porte d’entrée : les risques du prompt injection
Le principe est simple… et inquiétant : quand du contenu non fiable se retrouve dans un fichier source, un README, un morceau de Markdown ou un commentaire de code, l’agent d’Antigravity peut l’interpréter comme une instruction.
Résultat :
- exécution de commandes non souhaitées
- manipulations du terminal
- déclenchement de processus potentiellement dangereux
Bref : un prompt injection classique, mais cette fois à l’intérieur même de l’IDE, dans un espace où les développeurs manipulent du code sensible.
Accès aux fichiers, contournement des protections et exfiltration discrète
Antigravity permet à son agent IA de lire, générer et manipuler du contenu — y compris des fichiers sensibles. En théorie, Google a posé des garde-fous : par exemple, les éléments présents dans. gitignore comme les. env devraient être protégés.
Sauf que… l’agent peut tout simplement contourner la règle via le terminal : cat. env.
Et à partir de là, encoder les identifiants, les accrocher à une requête sortante, utiliser un sous-agent navigateur pour envoyer le tout vers un domaine malveillant. Des chercheurs affirment avoir récupéré ainsi des logs internes, des credentials cloud, du code privé et des secrets applicatifs.
Le tout sans aucune alerte claire côté utilisateur.
Un problème de conception plus que de bug
Les failles ne viennent pas seulement d’un manque de filtres. Elles découlent du parti pris d’Antigravity : un environnement où l’IA a beaucoup d’autonomie.
L’IDE pousse l’utilisateur à accepter les paramètres recommandés, laisser l’agent opérer en tâche de fond, déléguer la validation des commandes, gérer plusieurs agents via l’Agent Manager sans supervision permanente. Autrement dit : on donne à l’IA les clés du terminal, tout en incitant l’utilisateur à ne pas regarder.
D’un point de vue sécurité, c’est l’inverse de ce que ferait un pare-feu moderne ou un outil devops classique.
L’effet cocktail : automatisation + multi-agents + faible surveillance
Le risque augmente encore lorsque plusieurs agents travaillent ensemble. Un seul agent peut ignorer une alerte. Deux agents peuvent s’auto-compléter. Trois agents peuvent ex-filtrer des secrets en quelques secondes… pendant que vous regardez un autre onglet.
C’est exactement ce que montrent les démonstrations publiées : un agent lit un fichier, un deuxième encode son contenu et un troisième ouvre discrètement un navigateur pour ex-filtrer l’ensemble. Le tout sans que l’interface ne bloque clairementl’opération.
Google affiche bien des avertissements lors de l’onboarding, mais ils ne remplacent pas des garde-fous structurels.
Quand le confort l’emporte sur la sécurité
Antigravity cherche à réduire la friction entre le développeur et l’IA : moins de pop-ups, moins de confirmations, plus d’automatisation. Le problème ? Certains choix donnent aux attaquants un terrain de jeu parfait.
Les experts résument la situation ainsi : « L’IDE cherche la fluidité, mais sacrifie la sécurité là où elle devrait être non négociable ».
Pour une entreprise comme Google, c’est un revers symbolique : un outil « AI-first » ne peut pas être « security-second ».
