Quand l'IA devient à la fois problème et solution : Google admet les risques créés par l'agent IA introduit dans Chrome

Estimant qu'un second modèle IA est nécessaire pour surveiller le premier

Quand l’IA devient à la fois problème et solution : Google admet les risques créés par l'agent IA introduit dans Chrome,
estimant qu'un second modèle IA est nécessaire pour surveiller le premier et prévenir ses propres dérives

Depuis septembre 2025, Google a intégré à Chrome un assistant alimenté par son modèle d’intelligence artificielle Gemini. Concrètement, un chat-window basé sur Gemini est disponible dans le navigateur, avec la promesse que Chrome finira par disposer de capacités « agentic » — c’est-à-dire la faculté d’agir en autonome, d’interagir avec les contrôles du navigateur, de remplir des formulaires, de naviguer sur des sites, voire d’exécuter des séquences d’actions complexes sur la base d’un simple prompt de l’utilisateur.

Ce virage transforme Chrome — jusque-là un simple outil d’affichage et d’interaction manuelle avec le web — en un véritable « navigateur-agent », capable d’agir pour l’utilisateur. Mais cette évolution soulève des enjeux de sécurité, de vie privée et de confiance fondamentalement nouveaux.

Google prévoit d'ajouter un deuxième modèle basé sur Gemini à Chrome afin de résoudre les problèmes de sécurité créés par l'ajout du premier modèle Gemini à Chrome.

En septembre, Google a ajouté une fenêtre de chat alimentée par Gemini à son navigateur et a promis que le logiciel acquerrait bientôt des capacités d'action lui permettant d'interagir avec les commandes du navigateur et d'autres outils en réponse à une invite.

Il est dangereux de permettre à des modèles d'IA sujets aux erreurs de naviguer sur le web sans intervention humaine, car le logiciel peut ingérer du contenu – provenant peut-être d'une page web malveillante – qui lui ordonne d'ignorer les mesures de sécurité. C'est ce qu'on appelle « l'injection indirecte de commandes »

Le problème : « l’indirect prompt injection »

L’un des dangers majeurs identifiés est ce que Google nomme « indirect prompt injection ». Il s’agit d’un scénario dans lequel une page web malveillante — ou un contenu inséré par des tiers (iframe, publicité, contenu généré par un utilisateur, commentaires, etc.) — contient des instructions destinées à manipuler l’agent IA afin qu’il exécute des actions non souhaitées. Par exemple : lancer un paiement, envoyer des données sensibles, ou réaliser d’autres actions potentiellement dangereuses

Puisque l’IA « lit » le contenu des pages web pour décider de ce qu’elle va faire, cette exposition à du contenu non fiable rend le système vulnérable

Nathan Parker, qui fait partie de l'équipe de sécurité de Chrome, affirme que l’injection indirecte de prompts représente « la principale nouvelle menace pour tous les navigateurs agentics. » Dans un billet de blog, il déclare :

« La principale nouvelle menace à laquelle sont confrontés tous les navigateurs agentics est l'injection indirecte de commandes. Elle peut apparaître sur des sites malveillants, dans du contenu tiers dans des iframes ou dans du contenu généré par les utilisateurs, comme les avis, et peut amener l'agent à effectuer des actions indésirables, telles que lancer des transactions financières ou exfiltrer des données sensibles. Face à ce défi, nous investissons dans une défense multicouche qui comprend à la fois des défenses déterministes et probabilistes afin de rendre les attaques difficiles et coûteuses pour les pirates.

« La conception d'une navigation sécurisée par agent pour Chrome a nécessité une collaboration étroite entre les experts en sécurité de Google. Nous nous sommes appuyés sur les protections existantes de Gemini et les principes de sécurité des agents, et avons mis en place plusieurs nouveaux niveaux de protection pour Chrome.

La solution de Google : « Empiler l’IA sur l’IA »

Consciente de ces risques, Google a décidé de ne pas simplement désactiver ou retarder les fonctions agentic de Chrome. À la place, l’entreprise mise sur… une seconde IA — un modèle distinct — pour surveiller, contrôler, et valider les actions de la première. Ce modèle est baptisé User Alignment Critic (UAC).

Le fonctionnement est le suivant :

• L’agent « principal » (le modèle Gemini) planifie les actions à réaliser sur la base du prompt de l’utilisateur + du contenu web.
• Avant d’exécuter quoi que ce soit, le « User Alignment Critic » intervient après la planification et avant l’exécution : il examine la ou les actions proposées, mais sans avoir accès au contenu web non filtré — uniquement à des métadonnées de l’action (cible, type d’action, domaine, etc.).
• Si l’action est jugée “désalignée” (c.-à-d. qu’elle ne correspond pas à l’objectif déclaré de l’utilisateur, ou qu’elle présente un risque), l’agent est invité à reformuler ses actions — et en cas d’échec récurrent, le contrôle est rendu à l’utilisateur.

Ainsi, selon Google, c’est un second modèle IA qui sert de garde-fous aux excès potentiels du premier — un pattern de « IA sur IA », déjà réfléchi dans des travaux de recherche internes, notamment un cadre conceptuel publié en 2025 (le “CaMeL”)

Nathan Parker explique :

« Le principal modèle de planification de Gemini utilise le contenu des pages partagées dans Chrome pour décider de l'action à entreprendre. L'exposition à des contenus web non fiables le rend intrinsèquement vulnérable à l'injection indirecte de commandes. Nous utilisons des techniques telles que le "spotlighting" qui incitent le modèle à privilégier les instructions de l'utilisateur et du système plutôt que le contenu de la page, et nous avons intégré des attaques connues afin d'entraîner le modèle Gemini à les éviter.

« Pour renforcer davantage l'alignement du modèle au-delà du spotlighting, nous introduisons le User Alignment Critic, un modèle distinct construit avec Gemini qui agit comme un composant système hautement fiable. Cette architecture s'inspire en partie du modèle dual-LLM ainsi que des recherches CaMeL de Google DeepMind.

« Le User Alignment Critic s'exécute une fois la planification terminée afin de vérifier chaque action proposée. Son objectif principal est l'alignement des tâches : déterminer si l'action proposée sert l'objectif déclaré de l'utilisateur. Si l'action n'est pas alignée, le critique d'alignement la rejettera. Ce composant est conçu pour ne voir que les métadonnées relatives à l'action proposée et non le contenu web non filtré et non fiable, ce qui garantit qu'il ne peut pas être directement corrompu à partir du web. Il dispose de moins de contexte, mais sa tâche est également plus simple : il suffit d'approuver ou de rejeter une action.

« Il s'agit d'une couche de défense supplémentaire puissante contre le détournement d'objectifs et l'exfiltration de données au sein de l'étape d'action. Lorsqu'une action est rejetée, le Critic fournit un retour d'information au modèle de planification afin de reformuler son plan, et le planificateur peut rendre le contrôle à l'utilisateur en cas d'échecs répétés. »


Autres protections enclenchées

Au-delà de l’UAC, Google complète sa stratégie par une série de couches défensives :

• L’extension des mécanismes « d’isolation d’origine » (origin-isolation) et la politique dite « same-origin » : l’agent IA ne peut interagir qu’avec les « origines » (i.e. domaines/web-origines) explicitement autorisées pour la tâche en cours, afin d’éviter des interactions cross-site imprévues.
• Avant toute navigation ou toute action sur des sites sensibles (banque, santé, données personnelles, etc.), l’agent doit demander une confirmation explicite de l’utilisateur. Même chose avant d’utiliser un gestionnaire de mot de passe pour auto-login, ou avant d’exécuter des actions sensibles (achat, envoi de message, remplissage de formulaire critique…).
• Le système de sécurité de Chrome intègre aussi des défenses plus classiques selon les facettes de la menace : détection de contenu malveillant, classification des injections de prompt, sandboxing, transparence des actions de l’agent (journalisation), bug bounty pour encourager les chercheurs à tester la robustesse du système (jusqu’à 20 000 dollars de prime pour une démonstration de contournement des limites de sécurité).

En résumé : Google estime que pour rendre l’IA « agentic » suffisamment sûre, il faut un système d’IA à plusieurs niveaux, avec supervision et « frein de secours » — et non simplement des règles codées classiques.


Les inquiétudes et les limites de cette approche

« Empiler les IA » ne gomme pas tous les risques

Le recours à une deuxième IA (ou plusieurs) pour modérer une IA introduit ce que certains observateurs appellent une « régression en boucle » : l’on remplace un risque (celui d’une IA non surveillée) par un autre (celui d’une IA superviseuse — potentiellement faillible, vulnérable, moins transparente, etc.).

Autrement dit, si le modèle « critique » se trompe, interprète mal une action, ou fait l’objet d’une manipulation, le système global pourrait encore être compromis.

De plus, l’exposition initiale du modèle agent — à travers le contenu web — reste une surface d’attaque sensible. Même si l’UAC ne lit pas le contenu directement, les modèles de planification restent basés sur ces données. Les techniques « d’injection indirecte de prompt » sont encore un domaine de recherche active, souvent imprévisible, et des attaquants motivés pourraient trouver des contournements sophistiqués.

Comme le résume un internaute : « De l'IA empilée sur de l'IA, empilée sur de l'IA. Bon sang. »

Risques pour la vie privée et la confiance

Avec des agentic IA capables de naviguer, d’interagir, de remplir des formulaires ou de se connecter à des services, la frontière entre « utilisateur » et « agent » devient floue. Même si Google affirme que l’agent ne peut pas accéder à vos mots de passe — et qu’il demande votre autorisation avant des actions sensibles — le simple fait d’automatiser des interactions critique implique de lui confier un certain niveau de confiance.

Cela peut générer un malaise légitime : un utilisateur non attentif pourrait « laisser faire » l’IA, ce qui pourrait exposer des données sensibles, ou permettre des actions non désirées. L’automatisation et la « paresse cognitive » — l’habitude de laisser l’agent faire le travail sans vérifier — représentent un risque d’erreur humaine, ou de mésusage.

De plus, en cas de bug, de faille, ou de contournement des défenses, les conséquences peuvent être plus graves que pour un usage manuel classique d’un navigateur.

Des réserves exprimées par des experts

La gravité de la menace a récemment conduit le cabinet de conseil en informatique Gartner à recommander aux entreprises de bloquer tous les navigateurs IA « jusqu’à ce que les risques soient adéquatement maîtrisés ». Ces réserves concernent notamment les erreurs de l’IA, les fuites de données, les actions non autorisées, ou plus largement les incertitudes liées à un modèle d’IA « autonome mais contrôlé ».


Implications pour les utilisateurs et pour l’avenir du web

Pour les utilisateurs individuels

• Si vous utilisez Chrome avec les fonctions IA activées, il est important de comprendre que l’agent « fait le travail à votre place » — mais à condition que les garde-fous internes fonctionnent correctement. Il reste recommandé de vérifier toute action sensible (paiement, connexion, actions sur des comptes personnels, etc.), même si l’IA l’automatise.
• Activez les mises à jour de sécurité (et d’IA) dès qu’elles sont disponibles, car Google rappelle qu’une partie des protections repose sur les correctifs réguliers, l’architecture du navigateur, et le suivi des vulnérabilités.
• Restez vigilant face aux sites douteux : l’IA peut aider, mais elle peut aussi être mise en défaut si l’exposition initiale au contenu malveillant est trop forte.

Pour les entreprises et les environnements professionnels

• L’adoption d’un « navigateur IA agentic » dans le cadre professionnel — automatisation de tâches, formulaires, workflows web — peut représenter un gain de productivité, mais aussi de vulnérabilité. Les entreprises devraient revendiquer des politiques claires : quand l’IA peut agir seule, quand une validation humaine est requise, quels types de sites ou d’actions sont interdits à l’agent.
• Les responsables sécurité (CISO) devront évaluer les nouveaux vecteurs de menace — « prompt injection », « agent compromise », « fuite de données via automatisation », etc. Un simple pare-feu ou filtrage traditionnel ne suffira probablement pas.

Conclusion : Un pari audacieux… mais chargé d’inconnues

La démarche de Google marque un tournant majeur : plutôt que de considérer l’IA comme un simple outil de suggestion ou d’assistance, Chrome se transforme en environnement d’agentic IA. Pour relever les risques, Google choisit de « montrer qu’on peut faire confiance à l’IA en la supervisant par l’IA elle-même ».

C’est un pari audacieux, qui reconnaît explicitement que l’IA pose des vulnérabilités — mais que celles-ci peuvent (et doivent) être gérées avec d’autres IA. Cependant, ce pari repose sur l’hypothèse que ces systèmes de contrôle seront à la hauteur en toutes circonstances. L’histoire récente de la sécurité informatique — et plus encore de l’IA — incite à la prudence.

Dans les années à venir, le succès (ou l’échec) de cette approche pourrait influencer profondément la manière dont les navigateurs, les assistants numériques, et plus largement les services web, s’autonomiseront… ou non.

Source : Google

Et vous ?

Google a-t-il raison d’affirmer que seule l’IA peut corriger les risques générés par l’IA, ou s’agit-il d’un cercle vicieux technologique ?

Sommes-nous en train de créer une dépendance structurelle à des couches d’IA que personne ne peut réellement auditer ?

Le navigateur doit-il rester un outil manuel, ou est-il inévitable qu’il devienne un agent autonome ?

L’intégration d’une IA agentic dans Chrome représente-t-elle une avancée pour l’utilisateur ou une menace pour sa liberté numérique ?