Les navigateurs IA créent une nouvelle frontière de confiance

Les navigateurs IA ne sont pas risqués parce qu'ils ajoutent un chatbot à un onglet. Le risque commence quand le chatbot devient agent: il lit des pages, suit des liens, clique, mémorise le contexte et agit dans des sessions où l'utilisateur est déjà connecté. Ce n'est plus une simple aide à la recherche. C'est une nouvelle frontière de confiance dans le navigateur.

Deux travaux récents rendent cette frontière visible. Des chercheurs de l'University of Washington ont étudié sept agentic browsers et constaté que quatre créaient des conditions permettant de contourner la same-origin policy, la règle qui empêche un site de lire les données d'un autre. Leur preuve de concept complète visait ChatGPT Atlas. Ils ont aussi observé des conditions proches dans Chrome with Gemini, Claude for Chrome et Perplexity Comet. De son côté, LayerX a présenté BioShocking, une attaque qui pousse le navigateur IA dans une fausse réalité de jeu jusqu'à affaiblir ses guardrails.

Ce n'est pas une raison de paniquer. C'est une raison d'arrêter de traiter un agentic browser comme un navigateur ordinaire avec une meilleure complétion. Le web repose sur la séparation. Les agents brouillent cette séparation parce qu'ils lisent le texte à la fois comme contenu et comme instruction.

Same-origin policy, simplement

La same-origin policy est l'une des protections invisibles qui font tenir le web. Une boutique, une boîte mail et une banque peuvent être ouvertes dans le même navigateur, mais un script d'une origine ne devrait pas lire librement les données d'une autre. MDN définit l'origine par le schéma, l'hôte et le port. En pratique, une page quelconque ne doit pas pouvoir lire votre boîte mail parce que deux onglets sont ouverts.

Cette protection existe depuis les années 1990. Les utilisateurs la voient rarement, mais elle permet de garder plusieurs sessions actives sans que chaque page devienne une fenêtre vers toutes les autres.

Un navigateur agentique ajoute un acteur. L'agent peut inspecter une page, la résumer, lire du contenu intégré, se souvenir de pages précédentes et agir avec les droits de l'utilisateur. Si une page malveillante injecte des instructions dans ce que l'agent lit, elle n'a pas forcément besoin d'une faille web classique. Elle peut demander à l'agent de franchir la limite.

Ce que l'étude UW montre

L'étude UW est utile parce qu'elle parle de conception. L'équipe a examiné Brave Leo AI, ChatGPT Atlas, Chrome with Gemini, Claude for Chrome, Microsoft Edge with Copilot, Firefox AI Mode et Perplexity Comet. Les essais datent du début 2026, donc les produits peuvent évoluer. La leçon de sécurité reste actuelle.

Dans les conceptions les moins restrictives, une page malveillante qui réussit une prompt injection peut pousser l'agent à mélanger des informations entre origines. UW a démontré une attaque complète sur ChatGPT Atlas en Agent Mode: un site a récupéré des informations d'un autre site intégré, comme une publicité dans une page de mail qui lirait le contenu des messages. Les chercheurs ont trouvé des préconditions similaires dans Chrome with Gemini, Claude for Chrome et Perplexity Comet.

Ils mentionnent aussi la falsification d'actions cross-origin, l'exposition de champs masqués comme les mots de passe et le chat memory poisoning. Ce dernier point compte car les agents compressent et réutilisent ce qu'ils ont vu. Si leur mémoire mélange des origines différentes, l'ancienne isolation du navigateur ne suffit plus.

Ce que BioShocking ajoute

LayerX attaque un autre niveau. BioShocking ne vise pas d'abord la same-origin policy, mais le modèle de sécurité de l'agent. La page malveillante construit un monde de jeu où les mauvaises réponses deviennent gagnantes. Quand l'agent accepte cette logique, il peut être poussé vers des actions que ses guardrails devraient refuser.

LayerX indique que la preuve de concept a fonctionné sur plusieurs navigateurs et assistants, dont ChatGPT Atlas, Perplexity Comet, Fellou, Genspark Browser, Sigma Browser et le plugin Claude pour Chrome. Les scénarios incluent l'exposition d'informations sensibles, le changement de mots de passe ou la fuite d'identifiants. Ars Technica et The Hacker News ont repris le sujet car la leçon est nette: les guardrails ne sont pas un contrôle d'accès.

Une règle de refus dans un LLM est une couche de politique. La sécurité du navigateur a besoin de limites dures. Si le même agent voit une page malveillante, une page privée et peut agir dans une session authentifiée, un prompt bien placé peut relier des espaces censés rester séparés.

Ce qui peut réellement arriver

Les risques plausibles sont souvent ordinaires. Un utilisateur demande un résumé. Du texte caché dans la page dit à l'agent d'inclure des données d'un autre onglet, de copier un code à usage unique, d'ouvrir un document privé ou de coller un résumé dans un formulaire de l'attaquant. Un salarié laisse l'agent aider dans un CRM pendant que mail, GitHub, calendrier et consoles internes sont ouverts. Un commentaire malveillant dans une issue demande à l'agent de récupérer des secrets ailleurs et de les présenter comme du contexte.

Certains scénarios sont aujourd'hui des preuves de concept, pas des attaques de masse confirmées. Il faut le dire. Mais une preuve de concept suffit pour planifier le risque quand l'actif est un profil de navigateur déjà authentifié. Une extension trop permissive est dangereuse. Un agent l'est davantage parce qu'il interprète le langage, planifie et déplace des données entre étapes.

Règles pratiques

Pour tester un navigateur IA, utilisez un profil séparé. Ne mettez pas banque, consoles d'administration, dépôts privés, mail et gestionnaire de mots de passe dans le même profil où l'agent peut agir.

Désactivez les actions automatiques si possible. L'agent devrait demander confirmation avant d'envoyer un formulaire, acheter, copier des données entre sites, ouvrir un document privé ou utiliser des identifiants. Si le produit ne le permet pas, gardez-le loin des sessions sensibles.

Les entreprises doivent traiter ces outils comme de l'automatisation privilégiée. Politique d'autorisation, profils séparés, identités dédiées, isolation de navigateur, contrôles endpoint, allowlists et audit logs ne sont pas du luxe. Ce sont les bases si l'agent peut voir des données de travail.

La formation doit aussi changer. Les employés connaissent les liens suspects. Ils connaissent moins les instructions suspectes cachées dans une page normale. Le message calme est: le contenu web non fiable peut devenir une instruction pour l'agent.

Ce que les fournisseurs doivent changer

Améliorer le safety prompt ne suffira pas. Les navigateurs agentiques ont besoin d'une mémoire consciente des origines, de limites de permissions strictes, de confirmations par action, d'une séparation fiable du contenu intégré, de logs lisibles et de réglages par défaut peu permissifs. Dans l'étude UW, les designs qui donnaient moins de droits semblaient plus sûrs, même s'ils étaient moins impressionnants.

Le verdict raisonnable tient en trois mots: séparer, limiter, confirmer. Séparer l'agent des comptes sensibles. Limiter ce qu'il lit et fait. Confirmer toute action qui déplace des données, dépense de l'argent, utilise des identifiants ou touche les systèmes de travail.

Un navigateur était un lecteur avec des murs solides entre sites. Un navigateur IA ressemble plutôt à un assistant qui traverse ces pièces avec un carnet. Tant que les murs ne sont pas reconstruits pour les agents, ne lui donnez pas toutes les clés.