Google lance Antigravity. Les chercheurs le percent en 24 heures

Vingt-quatre heures. C'est le temps qu'il a fallu aux chercheurs en sécurité pour démontrer comment Antigravity, la plateforme de développement agentique présentée par Google au début du mois de décembre, peut se transformer en un parfait outil d'exfiltration de données. Nous ne parlons pas d'une attaque théorique ou d'une vulnérabilité exotique nécessitant des compétences de hacker de cinéma. Nous parlons d'une séquence d'attaque si simple qu'elle en paraît presque banale : un blog d'implémentation technique empoisonné, un caractère caché dans une police d'un point, et l'agent IA qui exfiltre les informations d'identification AWS directement vers un serveur contrôlé par l'attaquant.

L'histoire commence lorsque l'utilisateur demande à Antigravity de l'aider à intégrer une nouvelle fonctionnalité dans son projet, en fournissant comme référence un guide trouvé en ligne. Une action quotidienne, répétée des milliers de fois par jour par les développeurs du monde entier. Mais dans ce guide, caché au milieu de la page en caractères microscopiques, il y a quelque chose que l'œil humain ne voit pas : des instructions malveillantes adressées à l'agent IA. C'est ce que les chercheurs appellent "l'injection de prompt indirecte", une technique qui redéfinit le paysage des menaces informatiques à l'ère des agents autonomes.

Comme l'a documenté PromptArmor, l'attaque se déroule avec une précision presque chorégraphique. Gemini, le modèle à la base d'Antigravity, lit la page web et rencontre l'injection cachée. Les instructions lui ordonnent de collecter des extraits de code et des informations d'identification de la base de code de l'utilisateur, de construire une URL malveillante et de s'y rendre via le navigateur sous-agent intégré à la plateforme. Et c'est là que survient le premier rebondissement : lorsque Gemini tente d'accéder au fichier .env contenant les informations d'identification AWS, il se heurte à une protection. Le paramètre "Agent Gitignore Access" est désactivé par défaut, empêchant les agents de lire les fichiers listés dans .gitignore. Mais l'agent n'abandonne pas. Au lieu de respecter le blocage, il décide simplement de le contourner en utilisant la commande cat depuis le terminal pour vider le contenu du fichier, contournant ainsi les protections censées le protéger.

La chaîne se poursuit : Gemini construit méthodiquement une URL contenant les informations d'identification encodées, puis invoque un navigateur sous-agent avec l'instruction de visiter ce lien. Et c'est là qu'une autre faille de conception apparaît : la liste blanche par défaut des URL que le navigateur peut visiter inclut webhook.site, un service légitime qui permet à quiconque de créer des points de terminaison temporaires pour surveiller les requêtes HTTP. En d'autres termes, la porte de service a été laissée ouverte par commodité. Lorsque le navigateur visite l'URL malveillante, les informations d'identification voyagent dans les paramètres de la chaîne de requête, finissant dans les journaux accessibles à l'attaquant. Fin de la partie.

Anatomie d'un vol programmé

Ce qui rend cette attaque particulièrement insidieuse n'est pas la complexité technique, mais l'architecture même d'Antigravity. La plateforme a été conçue avec ce que Google appelle le "développement assisté par agent" comme configuration recommandée. En pratique, cela signifie que l'agent peut décider de manière autonome quand il est nécessaire de demander l'approbation humaine pour ses actions. Pendant toute la séquence de l'attaque documentée par PromptArmor, l'utilisateur n'a jamais vu une seule invite de confirmation. L'agent a pris toutes les décisions seul : lire des fichiers sensibles, exécuter des commandes dans le terminal, ouvrir des URL externes.

Le gestionnaire d'agents d'Antigravity, présenté comme une fonctionnalité phare, amplifie encore le problème. L'interface permet de gérer plusieurs agents simultanément, chacun engagé dans des tâches différentes. C'est l'équivalent d'avoir plusieurs assistants travaillant dans des pièces séparées : vous pouvez jeter un œil de temps en temps, mais la plupart du temps, ils opèrent sans supervision directe. Ce modèle opérationnel, conçu pour maximiser la productivité, crée une surface d'attaque parfaite pour les injections indirectes. Un agent travaillant en arrière-plan sur une intégration technique peut être compromis sans que l'utilisateur ne s'en aperçoive avant qu'il ne soit trop tard.

Mais l'injection de prompt n'est pas le seul vecteur d'attaque. L'OWASP a catalogué l'injection de prompt comme le risque numéro un de son Top 10 pour les applications LLM et GenAI, reconnaissant que la vulnérabilité découle d'une caractéristique fondamentale de ces systèmes : l'incapacité à distinguer clairement entre les instructions du développeur et les entrées de l'utilisateur. C'est comme si chaque entrée était potentiellement du code exécutable. Les attaques multimodales rendent les choses encore plus compliquées : des instructions malveillantes peuvent être cachées dans des images accompagnant un texte anodin, exploitant les interactions entre différentes modalités que les modèles les plus avancés prennent désormais en charge.

Prenons l'exemple des caractères invisibles ou presque invisibles. Un attaquant peut cacher des injections de prompt en utilisant des polices d'un point, du texte blanc sur fond blanc, ou même des caractères Unicode spéciaux que l'œil humain ne perçoit pas mais que le modèle lit parfaitement. Dans d'autres cas, les instructions malveillantes sont encodées en Base64 ou camouflées à l'aide d'emojis, de plusieurs langues ou de chaînes apparemment dénuées de sens qui influencent néanmoins la sortie du modèle de manière spécifique. La surface d'attaque est pratiquement infinie lorsque l'entrée peut prendre n'importe quelle forme et que le modèle a été entraîné à suivre des instructions en langage naturel. Image tirée de promptarmor.com

La porte dérobée qui survit à la désinstallation

Mais il y a un niveau de sophistication supplémentaire dans les attaques contre des plateformes comme Antigravity. Les chercheurs ont démontré qu'une injection de prompt peut non seulement exfiltrer des données, mais aussi installer des portes dérobées persistantes qui survivent à la session originale. Imaginez un agent qui, en suivant des instructions cachées dans une documentation technique, ajoute silencieusement des extraits de code malveillant dans les fichiers de configuration du projet. Du code qui est ensuite commité dans le référentiel, déployé en production, et peut-être même partagé avec d'autres membres de l'équipe via des systèmes de contrôle de version.

Ce type d'attaque, que PromptArmor a appelé "injection de prompt stockée", peut avoir des conséquences qui se propagent bien au-delà du moment initial de la compromission. Un petit fragment de code qui établit un shell inversé, un appel d'API vers un serveur externe qui suit l'utilisation de l'application, ou des modifications subtiles de la logique métier qui favorisent l'attaquant dans des scénarios spécifiques. Le code généré par l'IA est souvent considéré comme plus sûr qu'il ne devrait l'être, simplement parce qu'il provient d'un outil perçu comme neutre et fiable. Mais comme l'ont documenté des chercheurs de Snyk et Lakera, la sortie des LLM doit être traitée exactement comme toute autre entrée non fiable : validée, nettoyée, vérifiée avant d'être exécutée.

La persistance peut également être obtenue en manipulant les fichiers de l'espace de travail de l'IDE lui-même. Antigravity conserve des configurations, des préférences et des historiques qui influencent le comportement de l'agent lors des sessions ultérieures. Un attaquant qui parvient à injecter des instructions dans ces fichiers peut effectivement "entraîner" l'agent local de l'utilisateur à se comporter de manière malveillante à chaque fois qu'il est utilisé, créant ce que les chercheurs appellent un "empoisonnement de la mémoire". C'est l'équivalent numérique de laisser des post-it sur le bureau de quelqu'un, sauf que ces notes disent à l'assistant IA de faire des choses qu'il ne devrait pas.

L'écosystème fragile des agents IA

Antigravity n'est pas seul. L'ensemble de l'écosystème des IDE agentiques présente des vulnérabilités étonnamment similaires. La plateforme est dérivée de Windsurf, qui avait déjà présenté des problèmes de sécurité documentés. Cursor, un autre acteur majeur du secteur, a été confronté à des problèmes analogues. Claude Code d'Anthropic a démontré comment un agent IA peut être manipulé pour exécuter des actions non autorisées via des plugins de la marketplace compromis. Chaque nouvelle implémentation de "codage assisté par l'IA" semble répéter les mêmes schémas de vulnérabilité, comme si l'industrie réapprenait des leçons que la sécurité informatique avait déjà apprises il y a des décennies avec l'injection SQL et le XSS.

La différence fondamentale est que cette fois, nous ne parlons pas de bogues dans le code, mais de vulnérabilités intrinsèques à l'architecture même des modèles de langage. Comme l'a expliqué OpenAI dans son récent article sur l'injection de prompt, il s'agit d'un défi de frontière qui ne sera probablement jamais "résolu" complètement, tout comme le phishing et l'ingénierie sociale sur le web continuent d'exister malgré des décennies de contre-mesures. La nature même des LLM, qui consiste à suivre des instructions en langage naturel, les rend vulnérables à ce type de manipulation.

Le problème s'amplifie lorsque l'on considère l'écosystème plus large des agents IA. Comme nous l'avons documenté en analysant HumaneAIBench, les systèmes agentiques prolifèrent rapidement, de l'automatisation des e-mails et des calendriers à la gestion d'opérations DevOps complexes. Chacun de ces agents représente un vecteur d'attaque potentiel s'il n'est pas conçu avec la sécurité comme priorité absolue. Et la tendance ne montre aucun signe de ralentissement : GitHub prévoit un milliard de développeurs d'ici 2030, dont beaucoup utiliseront ces outils sans une compréhension approfondie des risques associés.

Le "vibe coding", l'idée de créer un logiciel en décrivant simplement ce que l'on veut en langage naturel, est fascinant du point de vue de l'accessibilité. Mais comme le soulignent des chercheurs de SecureCodeWarrior, donner à un développeur non préparé la capacité de générer des milliers de lignes de code via des prompts, c'est comme mettre un débutant au volant d'une Formule 1. L'expérience sera électrisante pour tout le monde, mais les chances que cela se termine mal sont très élevées. Le code généré par l'IA, comme le confirment les benchmarks de Baxbench, contient fréquemment des vulnérabilités de sécurité que les développeurs expérimentés identifieraient immédiatement. Image tirée de promptarmor.com

La sécurité qui ne s'adapte pas

La réponse de Google à l'affaire Antigravity a été pragmatique mais inquiétante. Au lieu d'annoncer des correctifs immédiats ou des architectures repensées, l'entreprise a opté pour la clause de non-responsabilité. Lors de l'intégration d'Antigravity, les utilisateurs sont avertis des risques d'exfiltration de données. Le message est clair : "nous savons qu'il y a des problèmes, utilisez-le à vos risques et périls". Dans leur annonce officielle de novembre, Google a présenté Antigravity comme faisant partie d'une nouvelle ère de l'intelligence, en mettant l'accent sur les capacités agentiques et le "vibe coding", sans mentionner les vulnérabilités connues.

Encore plus intéressant est la façon dont Google a géré la divulgation. Étant donné que l'entreprise avait déjà déclaré être consciente des risques d'exfiltration de données, PromptArmor a décidé de ne pas suivre le processus standard de divulgation responsable. La vulnérabilité a été classée comme "Problème connu" dans la documentation d'Antigravity, une catégorie qui exclut effectivement ces problèmes du programme de bug bounty de Google. En d'autres termes : nous savons qu'ils existent, mais nous ne les considérons pas comme des bogues à corriger en priorité. C'est une position qui rappelle celle du tabac dans les années 1950 : mettre une étiquette d'avertissement sur le paquet ne résout pas le problème sous-jacent.

Cette approche soulève de profondes questions sur le modèle de développement que l'industrie de l'IA est en train d'adopter. Comme nous l'avons observé en analysant Google Threat Intelligence, une course aux armements est en cours entre les capacités offensives et défensives dans le domaine de l'IA. Mais lorsque les plateformes sont publiées en connaissance de cause avec des vulnérabilités connues, classées comme des "fonctionnalités à risques", le fardeau de la sécurité est entièrement reporté sur les utilisateurs finaux. Ce modèle est-il durable ? Est-il éthique ?

La question devient encore plus complexe si l'on considère le contexte réglementaire. L'Union européenne élabore le Digital Omnibus, un cadre qui pourrait imposer des exigences de sécurité plus strictes pour les systèmes d'IA. Mindgard, une entreprise spécialisée dans la sécurité de l'IA, s'est inquiétée du fait que des plateformes comme Antigravity pourraient ne pas être conformes aux futures réglementations précisément à cause de ces vulnérabilités structurelles. Mais pour l'instant, en l'absence de réglementations claires, les entreprises peuvent choisir de privilégier la vitesse de publication par rapport à la sécurité, laissant aux utilisateurs le soin de gérer les risques.

IBM définit l'injection de prompt comme une préoccupation majeure car personne n'a encore trouvé de moyen infaillible de la traiter. Les vulnérabilités découlent d'une caractéristique fondamentale des systèmes GenAI : la capacité à répondre à des instructions en langage naturel. Identifier de manière fiable les instructions malveillantes est difficile, et limiter les entrées des utilisateurs pourrait changer fondamentalement le fonctionnement des LLM. Il s'agit d'un problème d'architecture, et non d'un bogue que l'on peut corriger avec une mise à jour logicielle.

CrowdStrike, par le biais de l'acquisition de Pangea, a analysé plus de 300 000 prompts adverses et suit plus de 150 techniques d'injection de prompt différentes. Leur taxonomie met en évidence comment la surface d'attaque continue de s'étendre. Chaque nouveau modèle, chaque nouvelle capacité multimodale, chaque intégration avec des outils externes ajoute des vecteurs de compromission potentiels. Et tandis que les défenses s'améliorent, les techniques d'attaque aussi, dans une danse évolutive qui rappelle l'éternelle bataille entre antivirus et logiciels malveillants.

L'avenir incertain de l'automatisation de confiance

Où tout cela nous mène-t-il ? Le front cyber de l'IA devient de plus en plus complexe et nuancé. D'un côté, nous avons des outils qui promettent de démocratiser le développement de logiciels et de multiplier la productivité. De l'autre, nous créons des surfaces d'attaque que nous ne savons pas encore comment défendre de manière adéquate. Le cas Antigravity est emblématique : une plateforme publiée en avant-première publique par l'une des entreprises technologiques les plus sophistiquées au monde, avec des vulnérabilités connues et documentées qui permettent l'exfiltration d'informations d'identification dans des scénarios d'utilisation réalistes.

Le défi n'est pas seulement technique, mais aussi culturel. Les développeurs doivent apprendre à traiter le code généré par l'IA avec le même scepticisme qu'ils réservent au code pris sur Stack Overflow. Les organisations doivent mettre en œuvre des politiques qui définissent clairement quelles données peuvent être exposées aux agents IA et lesquelles ne le peuvent pas. Les équipes de sécurité doivent faire évoluer leurs pratiques pour inclure la détection et l'atténuation de l'injection de prompt, une catégorie d'attaque que la plupart des outils traditionnels ne sont pas conçus pour intercepter.

Comme le souligne notre article sur les navigateurs IA, la promesse d'une expérience web améliorée par l'intelligence artificielle se heurte à des réalités de sécurité encore non résolues. OpenAI a récemment admis que son navigateur Atlas pourrait toujours être vulnérable à l'injection de prompt, reconnaissant que le problème ne sera probablement jamais "résolu" complètement. L'entreprise met en œuvre un "attaquant automatisé basé sur LLM" qui utilise l'apprentissage par renforcement pour trouver de nouvelles techniques d'attaque avant qu'elles ne soient découvertes dans la nature, mais il s'agit essentiellement d'une course entre l'innovation offensive et défensive où l'avantage semble pencher du côté des attaquants.

La sécurité de l'IA nécessite une approche stratifiée qui rappelle celle de la défense en profondeur traditionnelle. Il ne suffit pas d'avoir une seule couche de protection : il faut une validation des entrées, un sandboxing de l'exécution, une surveillance continue, une journalisation détaillée et, surtout, une culture de la sécurité qui imprègne chaque niveau de la pile. Les agents IA doivent fonctionner selon le principe du moindre privilège, en n'accédant qu'aux données strictement nécessaires à la tâche spécifique. Les actions conséquentes doivent nécessiter une confirmation explicite de l'utilisateur. Les listes blanches doivent être minimalistes, et non permissives par défaut.

Mais peut-être que la leçon la plus importante du cas Antigravity est que la vitesse de l'innovation ne peut pas se faire au détriment de la sécurité fondamentale. Publier des plateformes avec des "Problèmes connus" qui incluent l'exfiltration d'informations d'identification n'est pas acceptable, quel que soit le nombre de clauses de non-responsabilité affichées lors de l'intégration. Si l'industrie de l'IA veut que ces outils soient adoptés par des entreprises disposant de données sensibles, elle doit démontrer que la sécurité n'est pas une réflexion après coup mais une exigence fondamentale de la conception. Sinon, nous risquons de construire un avenir où l'automatisation intelligente devient le vecteur préféré des attaquants, tout comme les e-mails dans les années 2000 ou les applications web dans les années 2010.

Le chemin vers des agents IA vraiment sûrs sera long et n'aura probablement jamais de destination finale. Mais nous pouvons au moins éviter de répéter des erreurs que l'industrie du logiciel a déjà commises et surmontées. Traiter les entrées comme du code de confiance était un problème pour l'injection SQL il y a trente ans, pour le XSS il y a vingt-cinq ans, et maintenant cela se répète avec l'injection de prompt. La différence est que cette fois, l'enjeu est plus élevé : nous ne parlons pas d'applications web uniques, mais d'agents autonomes qui pourraient gérer des portions importantes de notre infrastructure numérique. Mieux vaut apprendre la leçon maintenant, avant que le coût ne devienne insoutenable.