Faut-il laisser un agent piloter votre navigateur ?

Pas dans le navigateur où vous êtes connecté à votre messagerie, à votre banque et à vos outils internes, et la raison n’a rien à voir avec la qualité de l’agent. Un agent qui pilote un navigateur n’hérite pas de la page que vous lui montrez, il hérite de toutes les sessions ouvertes dans ce profil, en même temps. La page que vous lui demandez de lire, elle, a été écrite par quelqu’un d’autre.

C’est la combinaison qui pose problème, et elle est nouvelle. Un lecteur humain qui tombe sur une page piégée ne va pas spontanément ouvrir sa messagerie pour en recopier le contenu ailleurs ; un agent, si, parce qu’il ne distingue pas ce que vous lui avez demandé de ce qu’il a lu en chemin. Nous décrivons ailleurs le même mécanisme quand un CV contient des consignes destinées à l’agent. Le navigateur en est la version étendue : le texte hostile ne vient plus d’une pièce jointe qu’on peut isoler, il vient de n’importe quelle page du web, et les droits qu’il emprunte sont les vôtres.

Que s’est-il passé exactement dans le cas Comet ?

Une consigne cachée dans un commentaire Reddit a fait sortir un code d’authentification de la messagerie d’un utilisateur, sans qu’il ait fait autre chose que cliquer sur « résumer cette page ».

Le détail mérite d’être lu, parce qu’il est plus banal qu’un scénario de sécurité classique. Brave a publié la démonstration le 20 août 2025, après l’avoir signalée le 25 juillet. Les instructions étaient repliées derrière une balise de masquage, du type de celles qui cachent un dénouement de film : invisibles pour le lecteur, parfaitement lisibles pour la machine qui récupère le texte de la page. À la demande de résumé, l’assistant a lu ces instructions, en a tiré l’adresse électronique de l’utilisateur depuis les informations de son compte, s’est rendu sur un domaine imité, a ouvert la messagerie déjà connectée dans le même navigateur, y a récupéré le code à usage unique reçu, puis a publié l’adresse et le code en réponse au commentaire d’origine.

Aucune faille technique dans cette chaîne. Aucun logiciel malveillant, aucun mot de passe volé, aucune élévation de privilège. Chaque étape est une action que l’agent avait le droit de faire, et c’est précisément pour cela qu’aucun filtre placé sur le texte lu n’aurait tenu. Brave conclut d’ailleurs que les hypothèses de sécurité habituelles du web ne s’appliquent plus, et recommande d’isoler la navigation agentique de la navigation ordinaire.

Le web se remplit-il vraiment de ce genre de pièges ?

Oui, et à une vitesse mesurable depuis peu. Le Cloud Security Alliance relève une hausse relative de 32 % du contenu porteur d’injection indirecte entre novembre 2025 et février 2026, sur un corpus de deux à trois milliards de pages explorées chaque mois. Ce n’est plus une démonstration de laboratoire, c’est une population.

La façon dont ces charges se cachent est instructive, parce qu’elle explique pourquoi la revue humaine ne rattrape rien. Sur les cas catalogués par l’Unit 42 de Palo Alto Networks, 37,8 % sont du texte parfaitement lisible pour la machine et invisible à l’écran, 19,8 % passent par un attribut HTML, 16,9 % par une règle de style qui supprime l’affichage. Le reste utilise de l’encodage ou un assemblage à l’exécution. Et 85,2 % des cas empruntent une tournure d’ingénierie sociale, c’est-à-dire qu’ils s’adressent poliment au modèle plutôt que d’exiger.

Les objectifs documentés vont du virement forcé à la suppression récursive de fichiers, et l’un d’eux mérite d’être relevé ici : le criblage biaisé de candidatures. Une page qui demande à l’agent de traiter favorablement un profil est une charge utile comme une autre, et elle est plus difficile à repérer que les précédentes, puisque son résultat ressemble à un avis.

Pourquoi la frontière utile est la session et non la page

Parce que c’est la seule ligne qui tienne sans connaître l’attaque à l’avance.

Le réflexe habituel consiste à vouloir contrôler ce que l’agent lit : une liste de sites autorisés, un filtre sur les instructions suspectes, une vérification du contenu avant qu’il n’atteigne le modèle. Nous avons essayé cette approche ailleurs, sur les descriptions d’outils d’un serveur MCP, et nous l’avons retirée après quelques semaines. Elle attrape les tentatives grossières, laisse passer le reste, et produit surtout le sentiment de sécurité qui fait relâcher l’attention là où elle comptait.

Ce qui tient est plus bête et plus efficace : décider ce que l’agent peut atteindre s’il est retourné. Un profil de navigation dédié, sans messagerie, sans banque, sans outil interne connecté dedans, réduit le pire scénario à « il a lu une page publique et raconté n’importe quoi ». C’est un incident de qualité, pas un incident de sécurité, et la différence entre les deux est toute la question.

La même logique s’applique à ce que l’agent peut faire depuis ce profil. Lire, et rien d’autre. Publier un commentaire, remplir un formulaire, envoyer un message, ce sont des actions sortantes, et rien de sortant ne part sans qu’une personne l’ait libéré. Dans le cas Comet, cette seule règle aurait cassé la chaîne à la dernière étape, celle de la publication du code.

Il faut dire ce que cette séparation laisse intact, sinon la position ressemble à un refus. Un navigateur agentique dans un profil vide est un excellent outil, et nous nous en servons : lire une documentation publique, comparer les pages tarifaires de trois fournisseurs, vérifier qu’une entreprise existe et à quoi ressemble son site. Ce sont des lectures dont le résultat se contrôle d’un coup d’œil, sur des pages qui n’ont aucune raison de nous viser en particulier, et où le pire cas se limite à une réponse fausse. La règle n’interdit donc pas le navigateur, elle interdit le navigateur qui a vos sessions dedans.

Et pour le sourcing, alors ?

C’est l’usage qui motive la question dans notre métier, et la réponse est non, pour deux raisons qui ne se recouvrent pas.

La première est contractuelle et n’a rien de nouveau : les conditions d’utilisation des grandes plateformes professionnelles interdisent l’automatisation depuis un compte personnel, et nous avons déjà écrit pourquoi nous refusons de faire agir un agent sous l’identité d’un recruteur. Le risque de suspension est individuel, la décision qui l’a pris est collective, et cette asymétrie suffit à trancher.

La seconde est celle de cet article, et elle est plus large. Une page de profil, une offre publiée par une entreprise, un fil de commentaires sous une annonce sont du texte écrit par un tiers. Un agent qui les lit dans une session portant vos droits est exactement dans la situation du cas Comet, avec en plus une motivation économique claire pour l’auteur de la page, puisque influencer un tri de candidatures a une valeur immédiate.

Ce qui reste possible, et que nous faisons, c’est de lire ces sources par des accès prévus pour cela, avec un identifiant qui n’appartient à personne en particulier et une portée réduite à la lecture. Ce n’est pas la même capacité, elle est plus étroite, et je préfère le dire ainsi plutôt que de vendre l’étroitesse comme une fonctionnalité.

Qu’est-ce qui rendrait un navigateur agentique acceptable ?

Trois propriétés, dont aucune ne dépend de la qualité du modèle.

Une séparation stricte entre le profil de navigation de l’agent et celui de la personne, de sorte qu’aucune session sensible ne soit accessible depuis la même fenêtre. Une distinction visible, dans l’interface, entre ce que l’utilisateur a demandé et ce que l’agent a lu en chemin, pour que la trace d’un incident soit lisible après coup. Et une validation humaine sur toute action qui écrit vers l’extérieur, quelle que soit la confiance accordée à la page à l’origine.

Ces trois points sont des décisions de produit, pas des consignes, et c’est ce qui les rend tenables. Une règle écrite en langue naturelle se contourne par une autre phrase en langue naturelle, ce qui est le point de départ de tout ce qui précède, et la raison pour laquelle une limite qui tient est un droit non accordé plutôt qu’une instruction bien rédigée.

Reste la question qui vient juste après, et qui se pose dès qu’on branche autre chose qu’un navigateur : chaque intégration ajoutée détient des identifiants et fournit du texte au modèle, ce qui en fait un fournisseur plutôt qu’un connecteur.