Quand lire une page permet aussi d’agir

Un assistant qui résume un article doit seulement en interpréter le contenu. Un agent de navigateur peut aller plus loin : lire des pages, naviguer d’un site à l’autre et, selon ses autorisations, cliquer ou saisir du texte dans une session où la personne est déjà connectée. Cette différence élargit ce qu’il peut faire pour le compte de quelqu’un, mais augmente aussi les conséquences possibles d’une erreur. Google souligne que les agents peuvent fonctionner dans des sessions authentifiées et qu’une action indésirable pourrait entraîner une transaction ou l’exposition de données sensibles. https://developer.chrome.com/docs/agents/security https://blog.google/security/architecting-security-for-agentic/

La question n’est donc pas seulement de savoir si le modèle répond correctement à une demande, mais aussi quels contenus il voit, quelles actions il est autorisé à effectuer et qui vérifie que chaque étape correspond à l’objectif de la personne. La frontière entre lire et agir est essentielle : résumer un avis n’a pas le même impact qu’envoyer un message, se connecter ou effectuer un paiement. La documentation de Chrome présente ses mesures comme des protections en plusieurs couches, et non comme une propriété magique du modèle qui rendrait inoffensif tout texte trouvé sur le Web. https://blog.google/security/architecting-security-for-agentic/

Une page peut contenir des instructions destinées à l’agent

L’injection indirecte d’instructions se produit lorsqu’une commande adressée au modèle apparaît dans les données qu’il consulte, au lieu de lui parvenir directement de la personne. Elle peut se trouver sur une page manipulée, dans du contenu tiers intégré ou dans des contributions d’utilisateurs, comme des commentaires et des avis. Google décrit deux risques précis pour les outils Web : des définitions d’outils contenant des instructions cachées et des réponses apparemment ordinaires qui intègrent du texte hostile. https://developer.chrome.com/docs/agents/security https://blog.google/security/architecting-security-for-agentic/

La difficulté tient au fait que le modèle traite des textes provenant de sources différentes tout en essayant d’accomplir une tâche. S’il prend le contenu d’une page pour une commande légitime, il peut s’écarter de l’objectif initial. Le site n’a pas besoin d’avoir autorité sur l’agent : il suffit que le texte influence sa planification. Google avertit explicitement que la nature probabiliste des modèles empêche de garantir la sécurité au seul niveau du modèle. Par conséquent, même une instruction dissimulée ou mêlée à des informations utiles doit être considérée comme un contenu non fiable, et non comme une autorisation de l’utilisateur. https://developer.chrome.com/docs/agents/security

Des travaux de recherche illustrent l’ampleur de cette surface d’attaque, même si leurs résultats ne doivent pas être généralisés automatiquement à tous les navigateurs. Une étude publiée sous forme de prépublication sur arXiv en mai 2025 a examiné, en boîte blanche, un projet open source de navigation et signalé une injection d’instructions, un contournement de la validation des domaines et une exposition d’identifiants. Il s’agit de l’analyse d’un projet et d’une configuration précis : elle montre que des défaillances sont possibles, mais ne constitue ni une mesure universelle des agents actuels ni une preuve concernant Chrome. https://arxiv.org/abs/2505.13076

Des couches qui réduisent les possibilités d’abus

Le guide de Chrome destiné aux agents utilisant WebMCP recommande plusieurs garde-fous déterministes : limiter le volume des entrées, restreindre les origines Web avec lesquelles l’agent peut interagir et demander une confirmation avant toute action. Il conseille également de traiter les réponses des outils comme des données non fiables. L’objectif est de réduire à la fois la quantité de contenu hostile qui entre dans le contexte et les voies par lesquelles une instruction manipulatrice pourrait causer un préjudice. Il s’agit de recommandations de conception pour les personnes qui créent des agents, et non d’une garantie que chaque extension ou navigateur les applique automatiquement. https://developer.chrome.com/docs/agents/security

Une autre technique décrite est le spotlighting : marquer ou transformer le contenu non fiable pour que le modèle le comprenne comme des données plutôt que comme des instructions. Chrome souligne que ces options impliquent des compromis. Délimiter le texte coûte peu, mais peut échouer si les délimiteurs sont manipulés ; l’encoder en Base64 complique certaines astuces structurelles, mais consomme davantage de contexte. Dans les deux cas, le système doit expliquer au modèle comment traiter ce contenu. Ces mesures se complètent ; elles ne constituent pas un filtre infaillible capable de reconnaître toute intention malveillante. https://developer.chrome.com/docs/agents/security

Google décrit également une architecture pour les capacités agentiques de Chrome : un modèle planificateur propose des actions et un composant distinct, appelé User Alignment Critic, vérifie qu’elles correspondent à l’objectif de l’utilisateur. L’entreprise affirme que ce critique reçoit les métadonnées des actions, et non le contenu Web non filtré, et qu’il peut rejeter des propositions. En outre, des ensembles d’origines visent à limiter les sites que l’agent peut lire et ceux sur lesquels il peut agir. La publication précise que la première mise en œuvre de cette restriction était plus simple et que la conception devait continuer à évoluer. https://blog.google/security/architecting-security-for-agentic/

Confirmations et limites déclarées

La confirmation humaine peut servir de frein lorsqu’une action risque d’avoir des conséquences. Google indique que son agent Chrome demande une autorisation avant certains sites sensibles, avant une connexion via Google Password Manager et avant des actions telles qu’un achat, un paiement ou l’envoi d’un message. L’entreprise mentionne aussi un journal des étapes et la possibilité de mettre la tâche en pause ou de l’arrêter. Ce sont des fonctionnalités décrites par le fournisseur ; cela ne signifie pas qu’elles sont toutes disponibles dans chaque région, version ou produit, ni que la personne doit approuver chaque détail de la même manière. https://blog.google/security/architecting-security-for-agentic/

La documentation reconnaît elle-même des limites : les classificateurs peuvent ne pas détecter tous les contenus conçus pour influencer l’agent, et les défenses nécessitent des tests et des améliorations continus. Google explique qu’il recourt à des exercices automatisés de red team pour générer des sites de test et observer si les protections arrêtent les attaques. Cette évaluation aide à repérer les régressions, mais un taux de réussite mesuré sur un ensemble de tests ne prouve ni l’absence de vulnérabilités futures ni la couverture de toutes les pages, langues, procédures et combinaisons d’outils. La conclusion prudente est que les différentes couches renchérissent le coût d’une attaque et peuvent en limiter les effets, mais pas qu’elles la rendent impossible. https://blog.google/security/architecting-security-for-agentic/

Ce que peut faire la personne qui utilise l’agent

Avant de déléguer une tâche, il est utile de vérifier les autorisations demandées par le navigateur ou l’extension et de limiter l’accès aux sites réellement nécessaires. Si une fonction peut envoyer des données, modifier un compte ou effectuer un achat, il est raisonnable de garder un œil sur l’opération et de vérifier le destinataire, les champs et le résultat avant de confirmer. Le guide de Chrome recommande de restreindre les origines et de demander confirmation pour les actions ; il ne s’agit pas de transférer toute la responsabilité à la personne, mais de conserver un point de contrôle pour les effets difficiles à annuler. https://developer.chrome.com/docs/agents/security

Il est également utile de distinguer les tâches à faible impact — comme organiser des informations publiques — des opérations portant sur des identifiants, des données médicales, des informations financières ou des messages privés. Si l’agent rencontre une instruction inattendue sur une page, il ne faut pas supposer qu’elle faisait partie de la demande initiale. Mieux vaut s’arrêter et examiner l’action proposée. La supervision réduit l’exposition, mais ne remplace pas les contrôles techniques : les recommandations officielles insistent sur les restrictions d’origine, l’évaluation régulière et les confirmations, tandis que les recherches disponibles montrent que des défaillances peuvent survenir dans différents composants du système. Rien ne permet de promettre une protection absolue. https://developer.chrome.com/docs/agents/security https://arxiv.org/abs/2505.13076