Le détournement sans clic expose un risque de sécurité central dans les navigateurs IA

Google News a relayé un avertissement selon lequel des navigateurs IA peuvent être détournés sans qu’une victime ne clique, n’approuve ou n’ouvre sciemment une commande malveillante. Des chercheurs en sécurité affirment que du contenu conçu à cette fin peut rediriger un agent pendant qu’il exécute une tâche ordinaire. La même automatisation qui fait gagner du temps peut alors exposer des fichiers, des identifiants, des messages ou des comptes authentifiés.

La recherche porte sur PleaseFix, une classe de vulnérabilités introduite par Zenity Labs en mars 2026 et élargie à Black Hat USA. Contrairement à l’ingénierie sociale classique, l’attaque vise le logiciel qui agit au nom de l’utilisateur. Une invitation de calendrier, une publication sur les réseaux sociaux, un site web ou un formulaire d’inscription à une newsletter peut devenir le canal d’instructions.

Cela crée un conflit que les éditeurs de navigateurs ne peuvent pas écarter comme un simple bug isolé. Les navigateurs IA ont besoin d’un accès étendu pour effectuer des tâches utiles sur différents sites web. Cet accès devient dangereux lorsque l’agent ne peut pas distinguer de manière fiable l’objectif de l’utilisateur des instructions placées dans du contenu non fiable.

Dark Reading a rapporté que les chercheurs de Zenity avaient identifié des chemins d’attaque dans les principales conceptions de navigateurs agentiques, y compris des produits liés à OpenAI, Google, Anthropic, Microsoft et Perplexity. La question importante n’est plus de savoir si un produit particulier a besoin d’un correctif. Elle est de déterminer si la navigation autonome peut préserver les frontières de sécurité habituelles du Web tout en agissant avec l’autorité d’un utilisateur.

PleaseFix transforme le contenu courant en déclencheur d’attaque

PleaseFix déplace l’ingénierie sociale : au lieu de persuader une personne, il redirige l’agent qui possède déjà l’autorité de cette personne.

Les attaques ClickFix traditionnelles convainquent les utilisateurs d’effectuer une action dangereuse, souvent en copiant une commande ou en approuvant une invite suspecte. PleaseFix élimine ce verrou humain. L’attaquant place plutôt des instructions là où un navigateur IA les rencontrera au cours d’un flux de travail normal.

Zenity a initialement divulgué PleaseFix le 3 mars 2026. Ses chercheurs ont démontré deux chemins d’exploitation impliquant Perplexity Comet. L’un pouvait utiliser une invitation de calendrier pour guider l’agent navigateur vers des fichiers locaux et envoyer leur contenu vers une destination contrôlée par l’attaquant.

Le second chemin visait les flux de travail de gestion des mots de passe. Selon Zenity, l’attaquant n’avait pas besoin d’exploiter directement le gestionnaire de mots de passe. Le contenu malveillant redirigeait l’agent navigateur alors qu’il opérait dans une session authentifiée.

Perplexity a corrigé le problème sous-jacent côté navigateur avant la divulgation publique. Zenity a indiqué que 1Password avait confirmé que la cause profonde ne se trouvait pas dans son gestionnaire de mots de passe. Cette distinction est importante, car l’agent agissait comme intermédiaire autorisé entre des systèmes par ailleurs légitimes.

La catégorie technique est l’injection indirecte de prompt. Elle survient lorsqu’un modèle d’IA traite des données non fiables comme une instruction, alors même que l’utilisateur n’a jamais donné cette instruction. Une page web, un e-mail, un document ou un événement de calendrier peut contenir le texte malveillant.

L’attaque peut rester cachée pendant que l’agent termine la tâche visible. Un utilisateur peut demander à un navigateur IA d’accepter une invitation ou de résumer une page. L’agent peut renvoyer la réponse attendue tout en réalisant une action supplémentaire choisie par l’attaquant.

Michael Bargury, cofondateur et CTO de Zenity, a décrit la faille comme une défaillance de confiance de l’agent, et pas seulement comme un défaut d’un gestionnaire de mots de passe ou d’un site web. La recherche PleaseFix de l’entreprise indique que l’instruction injectée hérite de tous les accès que l’utilisateur a accordés à l’agent.

Cet accès hérité change l’impact. Une page web compromise fonctionne normalement dans les limites imposées par le navigateur. Un agent compromis peut naviguer entre les onglets, lire des services connectés, saisir du texte, cliquer sur des contrôles et invoquer d’autres outils.

À Black Hat, les chercheurs ont étendu leur constat au-delà des démonstrations initiales sur Comet. Ils ont décrit une technique appelée collision d’intentions. Elle évite de demander directement à un agent d’abandonner la requête de l’utilisateur.

À la place, le contenu malveillant fournit une fausse définition de la manière dont la requête doit être accomplie. Si l’utilisateur demande à s’inscrire à une newsletter, l’attaque peut indiquer à l’agent qu’une action malveillante sans rapport fait partie de l’inscription.

L’agent semble toujours aligné sur la tâche d’origine. Il a simplement accepté un chemin contrôlé par l’attaquant pour l’accomplir. Cela rend moins efficaces les simples contrôles qui recherchent des instructions manifestement contradictoires.

Les reportages de Dark Reading publiés en juillet indiquaient que Zenity avait constaté des conceptions et garanties de sécurité sensiblement différentes entre les navigateurs agentiques. Pourtant, les chercheurs ont affirmé que chaque produit exposait au moins une voie d’attaque. Ce schéma fait du détournement d’agent sans clic un problème de catégorie.

Un correctif unique peut fermer une chaîne d’attaque démontrée. Il ne supprime pas le conflit sous-jacent entre contenu non fiable, décisions autonomes et accès authentifié.

Pourquoi les navigateurs IA mettent sous pression les frontières familières du Web

Un navigateur IA gagne en utilité en franchissant des frontières que les navigateurs conventionnels ont mis des décennies à imposer.

La politique de même origine est l’une de ces frontières. Elle empêche généralement le contenu d’un site web de lire ou de manipuler du contenu appartenant à un autre. Une page malveillante ne devrait pas pouvoir accéder à une session ouverte de banque, de messagerie ou d’environnement de travail.

Les agents navigateurs compliquent ce modèle, car l’activité intersites fait partie de leur objectif. Une tâche de voyage peut nécessiter de lire un site de réservation, de comparer des cartes, d’ouvrir des e-mails, de saisir des informations de paiement et de mettre à jour un calendrier. L’agent a besoin d’une visibilité plus large que celle dont bénéficie une page web isolée.

Des chercheurs de l’Université de Washington ont testé sept navigateurs agentiques au début de 2026. Leur étude sur la même origine a examiné Brave Leo AI, ChatGPT Atlas, Chrome with Gemini, Claude for Chrome, Microsoft Edge with Copilot, Firefox AI Mode et Perplexity Comet.

L’équipe a démontré une attaque complète de vol de données inter-origines contre ChatGPT Atlas en Agent Mode. Les chercheurs ont également identifié les conditions d’attaques connexes dans Chrome with Gemini, Claude for Chrome et Perplexity Comet si l’injection de prompt réussissait.

Dans la preuve de concept, un site malveillant intégrait du contenu provenant d’une autre origine. Une instruction injectée demandait à l’agent de lire ce contenu et de le placer dans un formulaire soumis automatiquement. L’agent devenait le pont que le code ordinaire du navigateur n’avait pas le droit de créer.

Les chercheurs n’ont pas affirmé que tous les produits testés étaient vulnérables au même exploit complet. Leur constat était plus structurel. Plusieurs conceptions réduisaient l’efficacité de la politique de même origine à l’efficacité des défenses contre l’injection de prompt.

C’est une dépendance exigeante. L’injection de prompt n’est pas une signature conventionnelle que les défenseurs peuvent bloquer de manière fiable une fois pour toutes. Les attaquants peuvent reformuler une instruction, la cacher dans du contenu visuel, la répartir entre plusieurs éléments ou la présenter comme faisant partie de la tâche.

Une personne peut ignorer un texte pâle ou des métadonnées de page inaccessibles. Un agent multimodal peut extraire ces informations et agir en conséquence. Cloud Security Alliance note que des chercheurs ont démontré des instructions utilisant des couleurs que les humains peinent à percevoir, mais que les systèmes d’IA peuvent toujours lire.

La mémoire crée un autre problème de frontière. Les agents peuvent compresser l’activité antérieure dans des résumés qui influencent leur comportement ultérieur. Si du contenu hostile atteint cette mémoire, sa source initiale peut devenir moins visible lors de décisions futures.

LayerX a précédemment décrit Tainted Memories, une attaque qui plaçait des instructions malveillantes dans la mémoire de ChatGPT Atlas. D’autres divulgations ont utilisé des fragments d’URL, des documents partagés et des chemins de récupération côté serveur pour fournir des instructions adversariales.

Ces méthodes diffèrent, mais exploitent la même ambiguïté. Le modèle reçoit l’intention de l’utilisateur et du contenu externe via des canaux qui ne fournissent pas une provenance fiable des instructions.

La provenance des instructions consiste à savoir qui a fourni une commande et quelle autorité elle doit avoir. Les logiciels conventionnels peuvent étiqueter le code, les entrées, les autorisations et les processus au moyen de structures techniques explicites. Les modèles de langage reçoivent souvent ces éléments sous forme de texte dans un contexte partagé.

Les navigateurs IA exercent donc une pression sur les équipes de sécurité dans deux directions. Restreindre l’accès réduit les dommages, mais réduit aussi les tâches qu’un agent peut achever. Étendre l’accès améliore l’automatisation tout en augmentant les conséquences d’une mauvaise décision.

L’équipe de l’Université de Washington a observé que le navigateur le moins risqué dans ses tests était aussi celui dont les capacités étaient les plus limitées. Ce constat résume le compromis central. Les capacités et l’exposition sont accrues par nombre des mêmes choix de conception.

Les titres de Google News masquent un problème d’autorisations plus profond

Le titre porte sur les prompts malveillants, mais la défaillance de sécurité plus large concerne les autorisations qui subsistent après qu’un agent a mal interprété une instruction.

Google News peut faire apparaître le détournement d’agent sans clic comme une nouvelle histoire de vulnérabilité à évolution rapide. Ce cadrage risque de concentrer l’attention sur la charge utile ingénieuse plutôt que sur l’autorité disponible une fois qu’elle fonctionne.

Un assistant IA qui se contente de résumer des pages publiques présente un périmètre d’impact limité. Un agent capable de lire les e-mails, d’accéder aux fichiers locaux, d’utiliser des identifiants enregistrés, de contacter des personnes et d’effectuer des achats présente un risque différent.

L’attaque n’a pas besoin de compromettre indépendamment chaque service connecté. Elle peut manipuler l’agent déjà autorisé à les utiliser. L’authentification légitime devient une partie de la chaîne d’attaque.

Cela ressemble à un adjoint confus, un problème de sécurité dans lequel un composant de confiance utilise mal son autorité pour le compte d’une autre partie. Le navigateur IA pense servir l’utilisateur alors qu’un attaquant influence la manière dont il interprète l’objectif de celui-ci.

PleaseFix démontre ce problème au moyen de contenu ordinaire. D’autres recherches l’étendent à différents canaux de livraison. GeminiJack aurait utilisé des documents Google partagés contenant des instructions cachées. HashJack plaçait des instructions après le symbole dièse dans les URL, une zone que les contrôles réseau peuvent ignorer.

ZombieAgent ciblait le comportement de récupération dans un agent de recherche IA. CometJacking utilisait des paramètres de requête conçus à cette fin et nécessitait un clic. Ces variations montrent que les défenseurs ne peuvent pas sécuriser uniquement les pages web tout en laissant les e-mails, les documents, la mémoire et les réponses d’outils sans traitement.

NIST a défini le détournement d’agent comme une forme d’injection indirecte de prompt qui amène un agent à poursuivre l’objectif d’un attaquant. Ses évaluations de détournement mettent l’accent sur la vérification de la capacité des agents à accomplir des objectifs malveillants cachés dans les ressources qu’ils traitent.

Cette approche d’évaluation est importante, car un système peut sembler sûr lors de tâches de référence ordinaires. Il peut également bloquer une formulation d’injection connue tout en restant vulnérable à une instruction formulée différemment.

La collision d’intentions rend le problème de test plus difficile. Le contenu hostile ne contredit pas toujours la requête de l’utilisateur. Il peut prétendre que l’étape malveillante est nécessaire pour accomplir la requête.

Un contrôle d’alignement limité pourrait voir une demande d’inscription à une newsletter suivie d’interactions avec un formulaire et conclure que le plan reste pertinent. Il doit aussi détecter qu’une action proposée franchit une origine, un outil ou un privilège sans rapport.

Les autorisations devraient donc être rattachées à une tâche précise, et non simplement à l’identité générale de l’agent. Une demande de résumé d’une page web ne nécessite pas l’accès à un gestionnaire de mots de passe. L’acceptation d’une invitation de calendrier ne devrait pas autoriser l’envoi de fichiers locaux.

Des autorisations de courte durée, limitées à une tâche, réduiraient la surface d’impact. Une séparation explicite entre accès en lecture et accès en écriture y contribuerait également. Un agent pourrait consulter plusieurs sources sans recevoir l’autorisation d’en transmettre le contenu ailleurs.

Le même principe s’applique aux déploiements en entreprise. Un agent de navigation connecté à des dossiers clients, des documents internes, des dépôts de code et des systèmes de messagerie ne devrait pas recevoir un ensemble d’autorisations unique et indifférencié.

Les équipes de sécurité ont également besoin de visibilité sur les actions des agents. Les journaux traditionnels peuvent montrer qu’une session utilisateur authentifiée effectue des requêtes valides. Ils peuvent ne pas indiquer si ces requêtes proviennent de la personne, du planificateur de l’agent ou d’un contenu hostile.

Cela affaiblit les logiques de détection habituelles. Il peut n’y avoir ni mot de passe volé, ni exécutable suspect, ni connexion non autorisée. L’activité nuisible peut se produire via un navigateur approuvé sur un appareil approuvé.

Pour les acheteurs en entreprise, la question essentielle concernant le produit n’est pas de savoir si un navigateur inclut un filtrage des injections de prompts. Ils devraient demander comment le système délimite les autorisations, enregistre les sources d’instructions, isole les origines et empêche les déplacements de données inattendus.

Les éditeurs de navigateurs mettent en place des garde-fous, mais aucun ne met fin au compromis

Des défenses à plusieurs niveaux peuvent interrompre des voies d’attaque connues, mais aucune architecture publiée ne supprime la tension fondamentale entre autonomie et contrôle.

Google identifie ouvertement l’injection indirecte de prompts comme la principale nouvelle menace pour les navigateurs agentiques. Ses défenses proposées pour Chrome combinent l’entraînement des modèles, des restrictions d’origine, l’examen des actions, la détection des menaces et des confirmations pour les étapes critiques.

L’un des composants est le User Alignment Critic. Ce modèle distinct examine une action planifiée et détermine si elle sert l’objectif déclaré de l’utilisateur. Google indique que ce critique reçoit des métadonnées sur l’action sans voir le contenu non filtré de la page web qui a influencé le planificateur.

Cette séparation réduit la probabilité que le même texte malveillant empoisonne à la fois le planificateur et son évaluateur. Le critique peut rejeter une action non alignée ou demander au planificateur d’élaborer un autre plan.

Google décrit également les Agent Origin Sets. Ils limitent les sites web qu’un agent peut consulter et ceux qu’il peut modifier au cours d’une tâche. Une fonction de contrôle fiable décide si une origine appartient au flux de travail demandé.

Cette conception se rapproche d’une autorité limitée à la tâche. Toutefois, elle doit toujours déterminer quelles origines sont légitimement pertinentes. Une demande d’achat, de voyage ou de recherche peut naturellement impliquer plusieurs sites inconnus.

Les attaquants peuvent exploiter cette ambiguïté. Une page malveillante peut présenter une autre destination comme nécessaire à l’achèvement de la tâche. Les faux positifs comptent également, car un blocage excessif rend l’agent moins utile.

OpenAI considère de la même manière l’injection de prompts comme un défi de sécurité persistant. Ses travaux de sécurité sur Atlas décrivent des exercices continus de red teaming et des mises à jour de modèles, plutôt qu’une correction achevée.

Microsoft a adopté une approche prudente concernant les actions agentiques dans le navigateur. Ses orientations publiques décrivent des restrictions sur le lancement d’applications externes, la saisie d’informations sensibles et certaines actions à fort impact. L’accès expérimental limite également l’exposition pendant que les conceptions évoluent.

Les confirmations restent utiles, en particulier avant des achats, des messages, des transferts de fichiers ou l’utilisation d’identifiants. Pourtant, une boîte de dialogue de confirmation peut échouer si elle présente le cadrage de l’attaquant plutôt que la véritable conséquence.

Les utilisateurs finissent également par s’habituer à approuver des invites fréquentes. Un outil autonome perd une grande partie de son attrait si chaque étape importante exige une inspection manuelle attentive. Un contrôle que les utilisateurs acceptent systématiquement offre une protection limitée.

Les modèles de détection font face à une course adversariale. Les chercheurs peuvent générer de nouvelles formulations, encodages, images et instructions en plusieurs étapes. Un détecteur entraîné sur les prompts d’hier peut manquer une instruction exprimée par le contexte et l’implication.

Cela ne rend pas les défenses inutiles. Des contrôles superposés obligent les attaquants à franchir plusieurs barrières et limitent les dégâts lorsqu’une barrière échoue. Le problème consiste à considérer un modèle, une politique ou un avertissement unique comme une frontière suffisante.

Le point de vue sceptique exige également de la prudence. Les affirmations générales de Zenity décrivent une catégorie de vulnérabilités et plusieurs démonstrations, et non des preuves que chaque utilisateur de navigateur IA a été compromis. Un accès obtenu dans le cadre d’une preuve de concept n’établit pas une exploitation généralisée.

Les produits évoluent aussi rapidement. Perplexity a traité le problème côté navigateur divulgué en mars, tandis que d’autres fournisseurs continuent de modifier les contrôles d’origine et de confirmation. Une conclusion concernant une version ne devrait pas décrire automatiquement toutes les versions ultérieures.

Toutefois, l’absence d’exploitation massive connue ne résout pas la préoccupation architecturale. Les navigateurs IA agissent au sein de sessions authentifiées à forte valeur, et la communauté de la sécurité a maintes fois identifié des voies menant d’un contenu non fiable à une action privilégiée.

Les entreprises devraient traiter ces produits comme de l’automatisation privilégiée, et non comme des logiciels de productivité ordinaires. Les évaluations de déploiement devraient inclure les mêmes pratiques que pour les comptes de service, l’automatisation robotisée des processus et les outils d’administration.

Cela implique de limiter les services connectés, de séparer les sessions personnelles et professionnelles, de désactiver les accès en écriture inutiles et de surveiller les actions sortantes. Les flux de travail à fort impact devraient conserver une vérification indépendante en dehors de la propre interface de l’agent.

Trois signaux montreront si les navigateurs IA deviennent plus sûrs

Le prochain test sera de savoir si les fournisseurs peuvent limiter l’autorité des agents sans réduire la navigation autonome à une démonstration supervisée.

Le premier signal est l’application d’origines propres à chaque tâche. Les éditeurs de navigateurs doivent montrer que les agents ne peuvent pas librement déplacer des informations entre des sites non liés simplement parce qu’ils apparaissent dans une même session.

Des chercheurs indépendants devraient répéter les tests inter-origines après les principales versions. Une défense efficace empêcherait une instruction injectée d’ajouter une nouvelle destination, de lire du contenu non lié ou de soumettre des informations sensibles.

Cela renforcerait l’argument selon lequel les navigateurs IA peuvent préserver les frontières fondamentales du Web. La poursuite des vols démontrés par preuve de concept sur des produits mis à jour montrerait que les contrôles d’origine dépendent encore trop de décisions faillibles des modèles.

Le deuxième signal est une confirmation indépendante pour les actions conséquentes. La conception la plus robuste générerait les informations d’approbation à partir de métadonnées d’action fiables, et non de la page web ou du récit du planificateur.

Une confirmation utile devrait indiquer quelles données seront déplacées, quelle destination les recevra et quel compte exécutera l’action. Elle devrait également empêcher une escalade silencieuse d’une tâche en lecture seule vers une opération d’écriture.

Les chercheurs testeront si un contenu malveillant peut masquer, supprimer ou reformuler ces avertissements. Si les confirmations exposent systématiquement la véritable conséquence, elles affaibliront les attaques par collision d’intention. Si les utilisateurs voient encore des invites vagues, la protection reste fragile.

Le troisième signal est la publication transparente des incidents et des évaluations. Les fournisseurs devraient publier les catégories d’attaques qu’ils testent, les autorisations détenues par leurs agents et les actions qui exigent toujours une approbation humaine.

Les taux de réussite globaux ne suffiront pas. Les tests doivent inclure des e-mails réalistes, des invitations de calendrier, des cadres intégrés, des documents, des images, des composants d’URL, des entrées de mémoire et des réponses d’outils. Ils doivent également inclure des attaques qui soutiennent la formulation apparente de la tâche de l’utilisateur.

OWASP classe l’injection de prompts parmi les risques centraux des applications reposant sur des modèles de langage. Ses recommandations sur l’injection de prompts préconisent de contraindre le comportement du modèle, de valider les sorties, de séparer les contenus externes et d’appliquer le principe du moindre privilège.

Les rapports publics peuvent révéler si ces principes fonctionnent dans des navigateurs déployés. Ils peuvent aussi distinguer les progrès architecturaux du simple correctif de démonstrations individuelles.

Les utilisateurs n’ont pas besoin d’abandonner toutes les fonctionnalités de navigateur IA pendant la poursuite de ces travaux. Ils devraient adapter l’autorité de l’agent à la sensibilité de la tâche.

Résumer des recherches publiques comporte moins de risques que d’opérer dans des sessions d’e-mail, de banque, de stockage cloud ou de gestion de mots de passe. Des profils de navigateur distincts peuvent réduire l’exposition, même s’ils ne peuvent pas corriger une conception d’agent dangereuse.

Les organisations devraient commencer avec des comptes limités et des flux de travail non critiques. Elles devraient empêcher les agents d’accéder aux identifiants ou aux fichiers locaux, sauf lorsqu’une tâche précise approuvée requiert cet accès.

Les équipes de sécurité devraient également partir du principe que le contenu peut être hostile, même lorsque son service d’hébergement est fiable. Un document partagé, un événement de calendrier, une publicité, un ticket d’assistance ou un message interne peut contenir des instructions contrôlées par un attaquant.

Google News continuera de faire remonter des découvertes individuelles à mesure que les chercheurs testeront de nouveaux produits. Les lecteurs devraient regarder au-delà du nom de chaque produit et se demander si l’agent pouvait distinguer une intention vérifiée d’un contenu non fiable.

La preuve décisive viendra de tests indépendants répétés. Un agent mis à jour peut-il rejeter un contenu hostile, rester dans des origines propres à la tâche et exposer chaque action conséquente avant son exécution ?

Tant que les fournisseurs ne pourront pas répondre systématiquement à ces questions, le détournement d’agent sans clic restera plus qu’un cycle temporaire de bugs. C’est le coût d’accorder aux logiciels une large autorité avant de leur donner un moyen fiable de reconnaître qui émet la commande.