Google présente une architecture de sécurité multicouche pour les capacités de navigation agentique de Chrome, en mettant l’accent sur la principale menace qui pèse sur les navigateurs capables d’exécuter automatiquement des tâches : l’injection indirecte d’instructions. Ce type d’attaque peut apparaître sur des sites malveillants ou dans du contenu tiers intégré à des cadres iframe ou à des avis d’utilisateurs, puis pousser l’agent à exécuter des actions incompatibles avec l’objectif de l’utilisateur, comme lancer des transactions financières ou exfiltrer des données sensibles.
Google affirme que la conception de la navigation agentique sécurisée dans Chrome a bénéficié de la collaboration des experts en sécurité de l’entreprise, ainsi que des protections déjà présentes dans Gemini et des principes de sécurité des agents. L’architecture proposée combine des défenses déterministes et probabilistes afin de rendre l’exploitation de l’agent plus difficile et plus coûteuse, tout en maintenant l’utilisateur dans la boucle de contrôle lors de l’exécution d’actions importantes.
Un modèle indépendant pour examiner les actions de l’agent
Lors de la phase de planification, Gemini s’appuie sur le contenu des pages que Chrome lui partage afin de déterminer l’étape suivante. Toutefois, ce contenu n’est par nature pas fiable, et le modèle de planification reste donc exposé aux tentatives d’influence visant à modifier le déroulement de la tâche. Google utilise des techniques telles que Spotlighting pour orienter le modèle afin qu’il privilégie les instructions de l’utilisateur et du système par rapport aux instructions présentes dans la page. Elle a également intégré des attaques connues à l’entraînement de Gemini afin de l’aider à les éviter.
Pour ajouter une couche supplémentaire, Google propose un composant appelé User Alignment Critic, un modèle distinct construit à l’aide de Gemini et fonctionnant comme un composant hautement fiable. Ce modèle intervient une fois la planification terminée pour examiner chaque action proposée et se concentre sur une question précise : l’action sert-elle l’objectif défini par l’utilisateur ? S’il considère que l’action n’est pas conforme à cet objectif, il peut la refuser.
Ce composant ne voit pas le contenu web non filtré ; il consulte plutôt les métadonnées associées à l’action proposée. Cette architecture lui fournit moins de contexte, mais rend sa tâche plus simple et davantage isolée du contenu malveillant : approuver ou refuser. Lorsqu’une action est refusée, le critique envoie ses remarques au modèle de planification afin que celui-ci reformule le plan. Si les échecs se répètent, le système peut rendre le contrôle à l’utilisateur.
Limiter l’étendue des sites auxquels l’agent peut accéder
Google étend les principes d’isolation des sites et de la politique de même origine à l’environnement des agents grâce au concept d’Agent Origin Sets. Les agents doivent travailler sur plusieurs sites, par exemple pour rassembler des composants sur un site puis remplir un panier sur un autre. Cependant, donner à un agent compromis une capacité illimitée d’interagir avec des sites arbitraires pourrait le transformer en moyen de contourner l’isolation des sites et d’exfiltrer des données issues de sessions locales authentifiées.
Une fonction de contrôle fiable identifie les origines liées à la tâche et les répartit, pour chaque session, en deux groupes distincts :
- Origines en lecture seule : Gemini est autorisé à en consommer le contenu, tandis que le contenu d’un cadre iframe n’est pas présenté au modèle si son origine ne figure pas dans ce groupe.
- Origines en lecture et écriture : l’agent est autorisé à y lire et à y exécuter des actions, comme cliquer et saisir du texte.
Cette séparation limite le risque de faire transiter des données entre des origines sans rapport avec la tâche et permet également au navigateur de ne jamais envoyer au modèle les données situées en dehors de l’ensemble de lecture. Le modèle de planification ne peut pas ajouter de nouvelles origines de sa propre initiative ; la fonction de contrôle doit les approuver. Une séparation similaire s’applique au contenu non web, comme les appels d’outils, en distinguant les appels de lecture et d’écriture et en vérifiant leur pertinence pour la tâche.
Les navigations vers de nouvelles origines font également l’objet d’un examen. Si le planificateur propose de naviguer vers une origine absente de l’ensemble de lecture, une instance du User Alignment Critic vérifie sa pertinence pour la tâche avant de l’ajouter et de commencer la navigation. Chrome utilise aussi une vérification déterministe pour limiter les URL générées par le modèle aux URL publiques connues, car les URL conçues par le modèle pourraient être exploitées pour exfiltrer des informations privées. Si la page navigue automatiquement vers une nouvelle origine, celle-ci est soumise au même examen.
Google reconnaît qu’il est difficile de définir ces limites correctement dès la première tentative, avant de savoir comment les tâches des utilisateurs interagiront avec elles. Elle a donc d’abord appliqué une version plus simple du contrôle des origines, qui suit les ensembles de lecture et d’écriture, avec des plans visant à ajuster les fonctions de contrôle et les autres éléments du système afin de réduire les frictions et d’améliorer la sécurité.
Confirmations de l’utilisateur et surveillance des actions sensibles
Chrome affiche les étapes de l’agent dans un journal d’activité au sein de l’onglet, afin que l’utilisateur puisse suivre ce qui se passe à chaque instant. Il peut également interrompre la tâche ou reprendre le contrôle à tout moment. Cette transparence est complétée par un ensemble de vérifications déterministes et fondées sur des modèles, qui demandent la confirmation de l’utilisateur avant les actions importantes.
Les principaux points d’arrêt sont les suivants :
- Demander une confirmation avant de naviguer vers des sites sensibles, comme ceux liés aux transactions bancaires ou aux informations médicales personnelles, sur la base d’une vérification déterministe d’une liste de sites sensibles.
- Demander une confirmation avant de se connecter à un site à l’aide de Google Password Manager, sans rendre les mots de passe enregistrés directement accessibles au modèle.
- S’arrêter avant des actions telles que finaliser un achat ou un paiement, envoyer un message ou effectuer toute action ayant des conséquences, puis demander l’autorisation ou inviter l’utilisateur à exécuter l’étape suivante.
Détection, tests et réponse
Le système examine chaque page consultée par l’agent à la recherche d’injections indirectes d’instructions, en parallèle de l’analyse en temps réel de Chrome via Safe Browsing et de l’intelligence artificielle embarquée afin de détecter les escroqueries traditionnelles. Le classificateur d’injection d’instructions fonctionne en parallèle du raisonnement du modèle de planification et peut bloquer les actions dont il détermine qu’elles ont été provoquées par le contenu de la page dans le but d’éloigner l’agent de l’objectif de l’utilisateur. Google reconnaît que le classificateur ne détectera pas toutes les influences malveillantes possibles, mais il constitue une couche supplémentaire dans une défense multicouche.
Pour vérifier l’efficacité de ces contrôles, Google a créé des systèmes automatisés de tests offensifs qui génèrent des sites malveillants isolés tentant de faire dévier l’agent de sa trajectoire. Les tests commencent par des attaques élaborées par des chercheurs en sécurité, puis les étendent à l’aide de modèles de langage et d’une technique adaptée aux agents de navigateur. Ils se concentrent sur les contenus largement diffusés, comme les publications d’utilisateurs sur les réseaux sociaux et les publicités, ainsi que sur les attaques susceptibles de causer des dommages persistants, comme les transactions financières ou l’exfiltration d’identifiants. Google utilise le taux de réussite des attaques pour évaluer les changements techniques et prévenir les régressions, tandis que les mises à jour automatiques de Chrome contribuent à déployer rapidement les correctifs.
Google a mis à jour les directives de son programme de récompenses pour les vulnérabilités afin de préciser comment les chercheurs externes doivent se concentrer sur les capacités agentiques de Chrome. L’entreprise affirme qu’elle versera jusqu’à 20 000 dollars pour les vulnérabilités critiques démontrant une compromission des limites de sécurité. Elle souligne que la sécurité des agents web reste un domaine émergent et que ces protections évolueront à mesure que se poursuivront les tests et la collaboration avec la communauté de la recherche en sécurité.