8 min read Sécurité agents

Agents navigateur : ce n'est pas le mot de passe qui vous expose, c'est la session

Agents navigateur : ce n'est pas le mot de passe qui vous expose, c'est la session

Google a annoncé le 30 juillet 2026 que Gemini Spark s'intègre désormais directement à Chrome. La formulation du billet officiel est sans ambiguïté : avec votre permission, Spark peut utiliser vos comptes connectés et vos mots de passe enregistrés pour traiter des tâches web fastidieuses. La bascule technique est là : l'agent ne travaille plus dans un navigateur distant géré par le fournisseur, où toute demande d'authentification interrompait la tâche, mais dans le Chrome installé sur la machine, avec la session que l'utilisateur y a déjà ouverte. Le déploiement a commencé aux États-Unis, avec une extension annoncée à d'autres régions.

La reprise de l'annonce s'est concentrée sur les mots de passe, et c'est un contresens utile à défaire. La documentation de sécurité publiée par l'équipe Chrome est explicite sur ce point : le modèle n'a pas d'accès direct aux mots de passe stockés, et une confirmation utilisateur est requise avant que Chrome ne procède à une connexion via le gestionnaire de mots de passe. Autrement dit, l'identifiant reste protégé par un mécanisme qui fonctionne. Ce qui n'est protégé par rien, c'est la session qui suit. Une fois l'authentification faite, il n'existe plus de point de contrôle : pas de réautorisation par action, pas de distinction entre l'humain et l'agent, et du côté du fournisseur SaaS, la requête ressemble trait pour trait à celle du collaborateur.

L'article du 13 juillet sur le contrôle d'accès des agents IA traitait le problème dans le sens habituel, celui d'un agent qui appelle des API avec un périmètre défini par un scope, révocable et journalisé. Le cas décrit ici est l'inverse exact : l'agent n'a aucun périmètre propre, il hérite de la totalité du contexte authentifié du poste, authentification unique d'entreprise comprise, sans passer par l'IAM et sans laisser de trace distincte chez le fournisseur. Ce qui suit détaille ce renversement, l'état réel des défenses, et l'endroit où le point de contrôle s'est déplacé.

Un curseur circule librement entre plusieurs applications déjà ouvertes dans un navigateur, tandis qu'un portique de contrôle reste inutilisé à l'écart.
L'agent n'obtient pas de nouveaux droits, il travaille à l'intérieur de ceux qui étaient déjà ouverts.

Un périmètre hérité plutôt qu'accordé

La différence entre les deux modèles de menace tient en une phrase. Un agent qui appelle une API dispose d'un jeton dont vous avez choisi la portée, la durée et les droits, et chaque appel apparaît dans un journal côté fournisseur avec une identité propre. Un agent qui pilote le navigateur de l'utilisateur dispose de tout ce à quoi cet utilisateur est connecté à cet instant, pour la durée de vie de ces sessions, avec ses droits à lui. Le premier périmètre est accordé, le second est hérité. Rien ne le déclare, rien ne le limite, et rien ne permet ensuite de séparer, dans les journaux d'un outil RH ou d'une console cloud, les actions de la personne de celles de son agent.

Google ne minimise pas ce point, et c'est ce qui rend sa documentation intéressante. Le billet de l'équipe sécurité de Chrome, publié en décembre 2025, l'écrit dans les termes d'un ingénieur sécurité : un agent non restreint qui serait compromis et pourrait interagir avec des sites arbitraires crée en pratique un contournement de l'isolation de site, avec un impact sévère quand l'agent opère dans un navigateur local comme Chrome, les sites où l'utilisateur est connecté devenant vulnérables à l'exfiltration de données. C'est le fournisseur lui-même qui décrit la classe de risque, et il déploie une architecture pour la contenir.

Le schéma qui se dessine sur le terrain ressemble beaucoup à celui des extensions de navigateur il y a dix ans. Un outil s'installe côté poste, à la demande de l'utilisateur, pour un gain de productivité réel, et il obtient par construction plus de portée que n'importe quelle intégration validée par une revue d'architecture. La différence est qu'une extension exécutait un code fixe et auditable, quand un agent exécute un plan reformulé à chaque tâche, à partir de contenus qu'il lit sur des pages qu'il n'a pas choisies.

Des défenses sérieuses, et explicitement incomplètes

Il faut rendre justice à ce qui a été construit. Chrome décrit une défense en couches qui va nettement au-delà d'un avertissement dans une boîte de dialogue. Un modèle distinct, appelé User Alignment Critic, vérifie chaque action proposée par le planificateur et peut y opposer un veto ; ce composant ne voit que des métadonnées et jamais le contenu web brut, ce qui le rend non empoisonnable depuis la page. Les Agent Origin Sets étendent l'isolation d'origine au monde agentique, en distinguant les origines lisibles des origines sur lesquelles l'agent peut agir, et en n'envoyant même pas au modèle les contenus hors périmètre. Une liste déterministe de sites sensibles, banque et santé notamment, déclenche une confirmation avant navigation. Un classificateur d'injection de prompt tourne en parallèle de l'inférence. Un programme de primes va jusqu'à 20 000 dollars pour une démonstration de franchissement de ces frontières.

Ces mêmes documents indiquent où en est réellement le sujet. Chrome écrit que l'implémentation initiale du cloisonnement d'origines est simplifiée et ne suit que l'ensemble des origines accessibles en écriture, et que la sécurité des agents web reste un domaine émergent. L'injection de prompt indirecte y est désignée comme la principale menace nouvelle pour tous les navigateurs agentiques, sans exception de marque.

La recherche indépendante confirme cette prudence. À Black Hat USA 2026, Artem Chaikin, ingénieur sécurité chez Brave, a présenté une session consacrée à l'attaque et à la défense des navigateurs IA, avec des démonstrations sur les navigateurs d'Opera, sur Perplexity Comet et sur ChatGPT Atlas. Sa conclusion, telle que rapportée par Dark Reading le 5 août, est que tous les navigateurs analysés se sont révélés vulnérables aux injections de prompt, y compris ceux qui cumulent instructions système strictes, marquage des contenus non fiables, modèle vérificateur secondaire et validation humaine. Un détail de cette présentation mérite d'être retenu par toute équipe qui compare des offres : les utilisateurs gratuits atteignant leur plafond d'usage pouvaient être basculés sur un modèle plus vulnérable aux injections. La robustesse de l'agent dépendait donc de son plan tarifaire. Chaikin conclut qu'il n'existe aujourd'hui aucune solution parfaite connue, chaque couche réduisant le risque sans le supprimer.

Comparatif entre un périmètre accordé par jeton d'API et un périmètre hérité des sessions du navigateur.
Deux façons pour un agent d'obtenir des droits, dont une seule laisse une trace exploitable.

Le point de contrôle a changé de console

La conséquence organisationnelle est celle qui échappe le plus souvent. Beaucoup d'entreprises ont installé leur gouvernance IA autour des contrats fournisseurs, des clés d'API et d'un comité qui arbitre les cas d'usage. Aucun de ces leviers n'atteint un agent qui tourne dans le Chrome personnel d'un collaborateur, sur un poste géré, avec une session d'entreprise ouverte. Le levier qui l'atteint est la politique de navigateur géré.

Chrome Enterprise expose pour cela des politiques applicables par unité organisationnelle. La plus large, GenAiDefaultSettings, prend trois valeurs : autoriser les fonctions d'IA générative en laissant les interactions contribuer à l'amélioration des modèles, les autoriser sans cette contribution, ou les interdire. Une politique dédiée à Gemini prend le pas sur ce réglage par défaut quand elle est définie, et d'autres politiques encadrent des surfaces précises comme l'intégration IA de la barre d'adresse. Ces réglages se pilotent depuis la console d'administration, dans les paramètres utilisateur et navigateur, unité organisationnelle par unité organisationnelle.

La question à trancher n'est donc pas de savoir si l'entreprise autorise les agents, elle est de savoir quelle unité organisationnelle a quelle valeur, et qui l'a décidée. Dans la plupart des organisations, la réponse est que personne ne l'a décidée et que la valeur par défaut s'applique. C'est exactement le mécanisme que l'article du 23 juillet sur la gouvernance du risque agentique décrivait sous l'angle de l'autorisation d'exécution : une capacité arrive par un canal que le dispositif de gouvernance ne surveille pas, et l'absence de décision fait office de décision.

À mettre en route cette semaine

Faites l'inventaire de ce qui tourne déjà. Recensez les extensions et agents navigateur présents sur le parc, en vous appuyant sur les remontées du navigateur géré plutôt que sur un questionnaire. Un agent qui n'est pas dans cet inventaire n'est pas absent, il est simplement invisible.

Fixez explicitement la politique d'IA générative du navigateur par unité organisationnelle, plutôt que de laisser courir la valeur par défaut. La décision peut être permissive, elle doit être écrite et datée, avec un responsable identifié.

Séparez le profil professionnel du profil sur lequel un agent est autorisé à travailler. C'est la mitigation que Brave a retenue pour son propre navigateur, avec des comptes personnels déconnectés par défaut, et c'est la seule mesure qui casse l'héritage de session à la racine plutôt que de tenter de le filtrer.

Désactivez le remplissage automatique des identifiants pour les sessions pilotées par un agent, et dressez la liste des domaines interdits à l'automatisation : banque, paie, ressources humaines, administration cloud, outils de signature. Une liste déterministe côté entreprise vaut mieux qu'une liste de sites sensibles maintenue par un tiers pour le grand public.

Déplacez la journalisation côté proxy plutôt que côté agent. C'est le seul endroit où vous verrez le trafic quelle que soit l'application qui l'a produit, et c'est la seule façon de répondre plus tard à la question de savoir qui, de l'humain ou de l'agent, a déclenché une action.

Ajoutez enfin une question au dossier de sélection de tout agent navigateur : quel est le modèle plancher, et que se passe-t-il quand un quota est atteint ? La réponse conditionne le niveau de sécurité réel du produit que vous déployez.

Conclusion

Le déplacement en cours est simple à énoncer et coûteux à ignorer : pendant deux ans, la sécurité des agents s'est jouée du côté du serveur, dans le périmètre des jetons et des permissions d'API, et elle se joue désormais aussi sur le poste de travail, dans un espace où votre gestion des identités n'a pas de prise. Les fournisseurs construisent des défenses réelles et le reconnaissent eux-mêmes comme un chantier ouvert, ce qui est la position honnête. Cela laisse aux entreprises une responsabilité qu'elles ne peuvent pas déléguer, et un levier concret dont la plupart n'ont pas encore réglé la valeur.

Sources : As of August 2026

Godwin AVODAGBE