Agents de navigateur : quels sont leurs risques de sécurité ?

En bref : Les risques de sécurité liés aux agents de navigateur alimentés par l'IA sont structurellement différents des risques logiciels traditionnels : les agents héritent des sessions authentifiées, fonctionnent simultanément sur plusieurs applications et génèrent des actions à partir d'instructions en langage naturel qu'aucune couche de contrôle existante ne peut interpréter. Les gouverner fait désormais partie de la construction de la résilience cybernétique, car vous avez besoin de visibilité à la fois sur l'identité et les données avant le déploiement, pas après un incident.

Les agents de navigateur sont passés des programmes pilotes aux flux de production plus rapidement que la plupart des équipes de sécurité n'ont pu réagir.

Chaque déploiement crée une catégorie distincte d’exposition que les contrôles de sécurité hérités ne peuvent pas voir, enregistrer ou gérer, qu’il s’agisse d’une intégration Copilot, d’une extension Claude ou d’un flux de travail ChatGPT fonctionnant dans la finance.

La couche d’authentification considère les agents comme des utilisateurs de confiance, la couche de données n’a aucune visibilité sur ce à quoi ils accèdent, et la couche de contrôle a été conçue pour des applications déterministes, pas pour des applications autonomes fonctionnant en langage naturel.

Ce guide explique comment évaluer cette exposition, classer les agents par niveau de risque et appliquer des contrôles qui gèrent le risque sans interrompre le travail.

Qu'est-ce qu'un agent de navigateur ?

Un agent navigateur est un système d'IA qui effectue des actions autonomes dans un navigateur web au nom d'un utilisateur. Il navigue dans les applications web, remplit des formulaires, clique sur des boutons, télécharge des fichiers et exécute des workflows multi-étapes à travers des sessions authentifiées sans nécessiter d'instructions humaines étape par étape.

L'agent reçoit une instruction en langage naturel, l'interprète à l'aide d'un grand modèle de langage et génère la séquence d'actions nécessaires pour accomplir la tâche sur toutes les applications accessibles par le navigateur.

Comment fonctionnent aujourd’hui les agents de navigateur

Trois mises en œuvre majeures illustrent la portée pratique de l'exposition.

1. Claude d'Anthropic peut naviguer sur le web, effectuer des actions entre les onglets et interagir avec les systèmes locaux. La propre documentation de recherche d'Anthropic déclare explicitement : « L'utilisation du navigateur amplifie le risque d'injection de prompt de deux manières. Premièrement, la surface d'attaque est vaste : chaque page web, document intégré, publicité et script chargé dynamiquement représente un vecteur potentiel pour des instructions malveillantes. »

2. L'agent ChatGPT d'OpenAI comprend quatre composants : Operator (navigation web autonome), Deep Research (recherche internet en plusieurs étapes), Code Interpreter (exécution Python) et intégrations avec Google Drive, GitHub et OneDrive. La documentation officielle d'OpenAI déclare clairement : « Cela introduit de nouveaux risques, notamment parce que l'agent ChatGPT peut travailler directement avec vos données. »

3. Actions Microsoft Copilot s'exécutent sur l'infrastructure Power Platform, utilisant les flux Power Automate et les connecteurs certifiés. En pratique, les actions automatisées peuvent se produire sous les identifiants d'un utilisateur selon la configuration et la manière dont l'approbation est mise en œuvre pour des types d'actions spécifiques.

Pourquoi les contrôles de sécurité existants ne peuvent pas voir l'activité de l'agent du navigateur

Les piles de sécurité ont été conçues pour des applications déterministes fonctionnant sur des données structurées. Les agents de navigateur fonctionnent en langage naturel avec des résultats probabilistes, à un niveau sémantique qui se situe au-dessus de l’endroit où chaque contrôle existant opère.

Les outils existants fonctionnent en dessous de la couche où les agents prennent des décisions

Les CASB, DLP, la surveillance réseau et l’EDR fonctionnent tous au niveau de la couche de sortie. Ils voient le trafic, les modèles et l’activité des processus après que les décisions ont été prises. La plupart des outils existants ont une capacité limitée à observer ce que raisonne un agent ou quelle instruction il exécute dans un onglet de navigateur.

Un agent chargé de résumer les données financières des clients et de les envoyer à l'extérieur accomplit cette tâche par une série d'actions qui est considérée comme tout à fait normale par ces quatre outils.

Les agents de navigateur peuvent lire simultanément toutes les sessions authentifiées

Les navigateurs appliquent une politique de même origine (Same-Origin Policy, SOP) qui empêche un script d’un domaine de lire les données d’un autre. Les agents du navigateur, fonctionnant en tant que processus utilisateur ou extensions, peuvent efficacement traverser plusieurs sessions authentifiées que la SOP isolerait normalement au niveau du script.

Ils s'exécutent en tant que processus au niveau utilisateur avec accès à toutes les sessions authentifiées actives dans le navigateur en même temps, ce qui signifie qu'un système RH, une application financière et un CRM ne sont plus isolés les uns des autres.

Une instruction malveillante intégrée dans une page web, un e-mail ou une invitation de calendrier peut diriger l'agent pour extraire et combiner les données de tous ces éléments dans une séquence automatisée.

Le trafic de l'agent arrive avec des identifiants valides, donc les contrôles d'identité le laissent passer

Les agents du navigateur s’authentifient via des sessions SSO existantes et héritent de jetons valides du fournisseur d’identité. Chaque requête qu’ils effectuent atteint les services organisationnels avec des identifiants légitimes via des canaux autorisés.

OAuth et SAML considèrent une entité authentifiée comme digne de confiance pendant toute la durée d'une session, un modèle qui échoue lorsque l'entité est un agent autonome dont le comportement change à chaque invite.

5 types de risques de sécurité des agents de navigateur

Les risques ci-dessous ne sont pas hypothétiques. Chaque catégorie comporte des incidents réels documentés ou des prototypes de recherche publiés démontrant une exploitation active.

1. Injection de prompt à partir de contenu web hostile

OWASP LLM Top 10 classe l'injection de prompt comme la principale menace pour les applications LLM : des instructions malveillantes cachées dans le contenu traité par l'agent peuvent détourner complètement son comportement.

Les agents de navigateur d'entreprise sont particulièrement exposés car ils combinent souvent trois conditions qui maximisent le risque : accès aux données privées, exposition à du contenu non fiable et capacité à communiquer à l'extérieur.

Des chercheurs ont montré que des invitations de calendrier malveillantes, des documents ou du contenu web intégré peuvent déclencher des actions involontaires de l'agent, y compris l'exfiltration sans clic de données locales ou cloud.

L'évaluation académique de huit approches de défense contre l'injection de prompt a révélé que toutes peuvent être contournées, avec des recherches publiées rapportant des taux de réussite élevés des attaques même contre des défenses renforcées.

2. Exfiltration de données sensibles vers des points de terminaison IA externes

Dans de nombreuses organisations, les employés utilisent des outils d’IA en version gratuite ou avec des comptes personnels en parallèle des outils d’entreprise autorisés, et une partie de cette utilisation inclut des données sensibles ou réglementées.

Avec beaucoup d'accès à GenAI transitant par les navigateurs, les données peuvent atteindre des points de terminaison IA externes via des canaux que la pile de sécurité traite comme un trafic web normal.

Les contrôles traditionnels de shadow AI se concentrent sur les listes d'applications autorisées et sont structurellement aveugles à ce schéma.

3. Actions autonomes provoquant une interruption des activités et une perte de données

Les agents du navigateur peuvent hériter de permissions destructrices (par exemple, des actions de suppression ou de modification irréversible) et les exécuter à la vitesse de la machine lorsqu'une tâche est mal comprise, mal définie ou influencée par un contenu hostile.

Par ailleurs, les modèles d’héritage entre outils et entre sessions dans des configurations multi-agents peuvent permettre des actions non autorisées dans les outils en aval sans visibilité claire pour l’utilisateur.

Ces incidents ont une cause commune : les agents se voient accorder des autorisations équivalentes à celles de l’utilisateur, sans limiter ces autorisations à des tâches spécifiques prévues.

4. Vol de justificatifs, détournement de session et mouvement latéral

Recherche de l'Université Cornell démontre que l'injection de prompt a évolué en attaques en cinq étapes reflétant les campagnes traditionnelles de logiciels malveillants : accès initial, élévation des privilèges, persistance dans la mémoire de l'agent, mouvement latéral à travers les services connectés et exécution.

Ces attaques multi-sauts exploitent le fait que les agents maintiennent des sessions authentifiées sur plusieurs services simultanément, donnant à un attaquant qui injecte avec succès des instructions une chaîne d'identifiants couvrant l'ensemble de l'accès de l'utilisateur.

5. Dérive silencieuse de la conformité due à l’adoption non encadrée de l’IA

Les cadres existants n'ont pas été conçus pour les systèmes autonomes. Selon l'exigence de contrôles d'audit de HIPAA (45 CFR §164.312(b)), les agents de navigateur opérant sur plusieurs systèmes sans journalisation unifiée créent des violations immédiates.

En vertu de GDPR Article 22, les agents prenant des décisions autonomes concernant l'accès aux données sans supervision humaine peuvent violer les protections relatives à la prise de décision automatisée. Plus largement, la shadow AI peut augmenter l'impact des violations et des audits car elle contourne souvent les contrôles standard de journalisation, de conservation et de gouvernance des accès.

Comment évaluer le risque de sécurité de l'agent du navigateur dans votre environnement

Avant d’appliquer des contrôles, les organisations ont besoin d’une base de référence sur trois dimensions : où les agents sont déployés, quelles données ils peuvent atteindre, et à quoi ressemble l’héritage des permissions.

Étape 1 : Inventaire de l'utilisation de l'IA du navigateur et des extensions

Configurez les outils DLP pour identifier les modèles de trafic IA, extraire les journaux proxy pour les connexions aux principaux services IA et examiner les journaux d’autorisation OAuth. Microsoft Defender Vulnerability Management fournit un inventaire natif des extensions de navigateur sur Edge, Chrome et Firefox sans coût supplémentaire.

Selon le Rapport Annuel sur la Sécurité des Navigateurs 2025 de LayerX Security, une part importante des extensions de navigateur d'entreprise disposent de permissions élevées ou critiques, les extensions GenAI demandant des étendues de permissions plus larges que les extensions standard.

Étape 2 : Cartographier l'exposition des données et ce à quoi l'agent peut accéder

Pour chaque agent découvert, documentez les sessions authentifiées auxquelles il peut accéder. La capacité de la Netwrix 1Secure Platform de Data Security Posture Management (DSPM) localise et classe en continu les données sensibles tout en les corrélant avec les identités qui y ont accès. Lorsque First National Bank Minnesota a dû reconstruire son Active Directory pour renforcer la sécurité, découvrir et classer d'abord les données sensibles des clients leur a permis de terminer un projet initialement estimé à six mois en seulement trois semaines.

Vous ne savez pas exactement ce que vos agents peuvent atteindre ? Netwrix 1Secure cartographie les données sensibles et les corrèle avec les identités qui y ont accès. Demandez une démo avant qu’un agent ne révèle la faille.

Étape 3 : Analyser l'héritage des identités et des permissions

Dans de nombreuses entreprises, la prolifération des privilèges entre les utilisateurs, les comptes de service et les applications connectées via OAuth est déjà présente. Les agents du navigateur héritent de cette prolifération et peuvent l’exercer à la vitesse de la machine. Documentez l’écart entre les états d’autorisation requis et réels avant le déploiement de tout agent.

Étape 4 : Évaluer la posture de sécurité du fournisseur et les contrôles intégrés

Examinez l'architecture de sécurité documentée de chaque fournisseur d'agents : quelles données l'agent peut accéder, où elles sont traitées, comment les invites et réponses sont stockées, et quels contrôles d'entreprise sont disponibles.

Étape 5 : Définir les politiques d’utilisation approuvées, restreintes et bloquées

La politique d’utilisation acceptable doit couvrir explicitement quels outils d’IA sont sanctionnés, quelles classifications de données sont autorisées pour chacun, les responsabilités des utilisateurs, les activités interdites et les mécanismes d’application. Les exigences de la politique évoluent rapidement à mesure que de nouvelles capacités des agents sont publiées. Certaines organisations ont mis à jour leurs politiques d’utilisation acceptable de l’IA plusieurs fois en un seul trimestre, chaque révision traitant de nouveaux cas limites introduits par les mises à jour des agents

Comment réduire le risque de sécurité de l'agent du navigateur sans interrompre la productivité

Bloquer toute l'IA du navigateur n'est pas une posture réaliste pour la plupart des organisations. Les contrôles ci-dessous sont classés par impact relatif au coût de mise en œuvre.

La classification des risques et la remédiation du moindre privilège sont des prérequis. Les contrôles restants s'appuient sur l'hygiène d'accès qu'ils établissent.

Classifiez les agents par niveau de risque : approuvé, restreint ou bloqué

Évaluez chaque cas d'utilisation de l'agent du navigateur selon quatre dimensions : sensibilité des données, impact opérationnel, exposition réglementaire et autonomie décisionnelle. Ajoutez des facteurs spécifiques au navigateur : portée d'accès aux identifiants, limites de session, intégrations de services externes, et si les actions de l'agent peuvent être surveillées et annulées.

• Risque faible (approuver) : Données publiques uniquement, pas d’identifiants d’entreprise, surveillance standard suffisante.
• Risque moyen (restreindre) : Données d’entreprise non sensibles, contrôles d’accès basés sur les rôles access controls requis, posture en lecture seule préférée, surveillance renforcée et couverture DLP, recertification trimestrielle.
• Risque élevé (bloquer ou gérer avec des contrôles compensatoires) : Données réglementées, identifiants d’authentification, systèmes de production ou capacité de prise de décision autonome. Évaluation complète de la sécurité requise, surveillance continue et examen dédié de la gouvernance avant tout déploiement.

Appliquez le principe du moindre privilège avant que les agents n'amplifient l'exposition existante

Si les utilisateurs disposent aujourd’hui de permissions excessives, un agent de navigateur hérite de chacune d’elles et les exerce à la vitesse de la machine. Corriger les accès surprovisionnés avant l’adoption de l’agent est l’action préparatoire la plus rentable disponible.

Netwrix Privilege Secure applique un accès just-in-time sans privilèges permanents, ce qui signifie que les agents opérant sous des comptes gérés ne détiennent pas d'accès élevé persistant en attente d'exploitation. Chaque opération privilégiée est liée à une identité spécifique dans la piste d'audit, fournissant la visibilité médico-légale requise par les cadres de conformité.

Par exemple, lorsque les testeurs d'intrusion exploitaient à plusieurs reprises des comptes administrateurs surprovisionnés, Eastern Carver County Schools a mis en place un modèle d'accès just-in-time qui a éliminé les privilèges permanents. Pour un district scolaire disposant de ressources informatiques limitées, la capacité à mettre en œuvre ce niveau de contrôle en quelques jours plutôt qu'en plusieurs mois a été cruciale pour sécuriser les données de 9 300 élèves.

Utilisez des profils de navigateur gérés et des listes blanches d’extensions

Microsoft Edge for Business crée des contextes de sécurité distincts pour la navigation professionnelle et personnelle, avec trois niveaux de sécurité associés aux profils de risque des utilisateurs. Chrome Enterprise fournit la détection des conflits de politiques qui bloque automatiquement l'accès aux applications d'entreprise lorsque les politiques critiques montrent une non-conformité sur les appareils BYOD.

Les listes blanches d’extensions utilisant une posture de refus par défaut sont le contrôle le plus efficace disponible au coût marginal le plus bas. Dans Microsoft Edge, les politiques ExtensionSettings peuvent bloquer toutes les extensions par défaut, avec des exceptions explicitement approuvées pour chaque outil qui réussit le processus d’évaluation des risques.

Appliquez la classification des données et le DLP conscient de l'IA pour contenir l'exposition des données sensibles

Le DLP traditionnel ne peut pas suivre le rythme des modes d'interaction de GenAI. Data classification qui indique aux contrôles quelles données sont importantes est le préalable.

Configurez des protections différenciées selon le niveau de sensibilité : les données restreintes ne peuvent pas être collées dans un outil d’IA externe quel que soit le rôle de l’utilisateur, tandis que les données publiques circulent sans restriction.

La plateforme 1Secure intègre la découverte et la classification des données sensibles avec Identity Threat Detection et la fonctionnalité DLP de Netwrix Endpoint Protector, maintenant en continu les étiquettes de sensibilité dans les environnements hybrides afin que les protections s'appliquent lorsque les données circulent dans les flux de travail des agents.

Microsoft Edge Protected Clipboard ajoute une couche de protection pilotée par des politiques au niveau du presse-papiers pour empêcher l’exfiltration par copier-coller depuis des applications sensibles.

Détecter les anomalies pilotées par l'IA dans l'activité du navigateur et de l'identité

Les agents de navigateur présentent des comportements différents de ceux des utilisateurs humains : appels API rapides, accès massif aux données, activité en dehors des heures normales, agrégation de données inter-applications sur de courtes fenêtres temporelles.

Defender for Cloud Apps identifie les menaces en analysant les modèles d'activité du navigateur lors des événements de connexion. La détection d'anomalies basée sur l'identité est le mécanisme techniquement le plus viable disponible aujourd'hui car les agents partagent les mêmes protocoles, identifiants et canaux que les utilisateurs légitimes.

Les comportements qui distinguent l'activité de l'agent (vitesse, étendue et timing) sont les signaux que identity threat detection mettent en évidence une ligne de base d'identité gouvernée.

Comment Netwrix vous aide à gérer le risque de sécurité des agents de navigateur

Les agents de navigateur se situent à l'intersection de l'identité et des données. Ils s'authentifient en utilisant des identités organisationnelles, accèdent aux données organisationnelles et opèrent via des canaux que tous les contrôles existants considèrent comme légitimes. Sécuriser une dimension sans l'autre laisse une faille que les agents exploiteront à la vitesse de la machine.

Pour les organisations de taille moyenne gérant des environnements hybrides fortement Microsoft, la question fondamentale n'est pas quel agent bloquer. C'est de savoir si vous avez une visibilité précise sur ce que vos identités peuvent atteindre et si cet accès est toujours approprié. Sans cette base, gouverner les agents de navigateur est un jeu de devinettes.

Netwrix 1Secure traite directement cette base de référence : DSPM localise et classe en continu les données sensibles tout en les corrélant avec les identités pouvant y accéder. Cependant, la seule visibilité ne réduit pas la surface d'attaque héritée par les agents.

Netwrix Privilege Secure élimine l’accès permanent grâce à des privilèges permanents nuls et une élévation just-in-time. Les agents opérant sous des comptes gérés ne détiennent pas de permissions élevées persistantes entre les sessions.

Identity Threat Detection & Response met en lumière les anomalies comportementales qui distinguent l’activité pilotée par des agents des schémas utilisateur normaux, fournissant la couche de détection qu’aucun navigateur ou contrôle réseau existant ne peut offrir.

Demandez une démo pour voir comment Netwrix cartographie l'exposition des identités et l'accès aux données sensibles dans votre environnement avant que les agents ne l'amplifient.