Les agents IA augmentent les risques dans le navigateur

La question de la sécurité des navigateurs se déplace de la détection vers l’exécution

Les équipes de sécurité des entreprises doivent de plus en plus décider où le code web peut s’exécuter. Gartner prévoit que plus de 85 % des charges de travail d’entreprise seront accessibles via le navigateur d’ici 2027, tandis que des rapports du secteur indiquent que les attaques basées sur le navigateur ont fortement augmenté au cours des deux dernières années. Ces tendances rendent la frontière d’exécution déterminante, car le navigateur traite du contenu distant tout en maintenant des sessions d’entreprise authentifiées.

Ces sessions authentifiées prennent désormais en charge des plateformes SaaS, des systèmes CRM et ERP, des outils de collaboration et des workflows alimentés par des LLM. Les applications d’entreprise utilisent de plus en plus le navigateur à la fois comme point d’accès et comme espace de travail, tandis que des agents IA autonomes commencent à fonctionner via ces mêmes sessions. À mesure que des activités de plus en plus critiques se déplacent dans cet environnement, les équipes de sécurité doivent se demander quel code peut y être exécuté et sur quelle machine il s’exécute.

Shioupyn Shen, fondateur et PDG de CloudMosa, l’entreprise à l’origine de Puffin Cloud Security, estime que cette évolution change le rôle du navigateur : « Le navigateur n’est plus simplement une application de plus exécutée sur le terminal. » CloudMosa bénéficie commercialement lorsque les entreprises adoptent son approche de navigateur cloud, de sorte que l’interprétation de Shen soutient aussi la stratégie produit de l’entreprise. Son argument technique est que les navigateurs conventionnels interprètent le code distant localement, alors que les usages d’entreprise exigent de plus en plus une isolation plus forte et une application plus stricte des politiques autour de cette exécution.

Cette distinction soulève une question de conception concrète. Un navigateur conventionnel permet à du code actif distant d’atteindre un terminal et de s’y exécuter, après quoi des couches de sécurité peuvent identifier, restreindre ou traiter ce qui se passe. À mesure que le travail en entreprise et les agents IA se concentrent dans des sessions de navigateur authentifiées, les équipes de sécurité peuvent se demander si le contenu actif d’origine doit réellement s’exécuter sur le terminal.

L’IA rend l’exécution locale dans le navigateur plus difficile à défendre par la seule détection

L’emplacement de l’exécution compte en raison du modèle de fonctionnement normal du navigateur. Un onglet peut recevoir du JavaScript, du WebAssembly et d’autres contenus web depuis des systèmes distants, les interpréter localement et fonctionner pendant que le navigateur maintient des sessions authentifiées pour des applications d’entreprise. Des scripts malveillants, le vol d’identifiants, la compromission de la chaîne d’approvisionnement et d’autres exploits visant le navigateur peuvent donc pénétrer dans un environnement d’exécution qui a déjà accès à des comptes et à des données de valeur.

Une fois que le contenu distant s’exécute localement, les contrôles axés d’abord sur la détection font face à une contrainte de temps, car l’inspection et la réponse peuvent intervenir après le début de l’exécution. Du JavaScript dynamique ou obscurci et du WebAssembly peuvent s’exécuter avant que les défenses du terminal ne réagissent, de sorte qu’une attaque éphémère ou sans fichier peut avoir le temps de voler des identifiants ou d’exfiltrer des données. La séquence est importante même lorsque la détection finit par identifier l’attaque, car le navigateur a déjà donné au contenu l’occasion d’agir.

L’IA accentue encore la pression sur cet intervalle, car les attaquants peuvent automatiser la génération, la mutation et le déploiement de malwares. Un chiffre rapporté situe à 89 % l’augmentation des attaques menées par des adversaires utilisant l’IA au cours de l’année écoulée. À ce rythme, les défenseurs peuvent être confrontés à de nouveaux variants plus vite que les systèmes fondés sur des signatures ne peuvent analyser les échantillons précédents et mettre à jour les règles de détection.

Ces variants comptent parce que les malwares polymorphes modifient leur code ou leur comportement d’une occurrence à l’autre, ce qui rend moins utile une signature apprise à partir d’un échantillon antérieur. Les techniques sans fichier et sans malware peuvent utiliser des outils légitimes, des sessions compromises ou du contenu web malveillant, sans laisser aux scanners de fichiers conventionnels de signature de fichier malveillant à inspecter. Le volume d’attaques se combine donc à la variation et à la vitesse d’exécution pour accroître la pression temporelle sur la classification.

Cette pression est au cœur de l’argument de Shen en faveur d’un changement de frontière du navigateur. « Les défenseurs ne se contentent plus de poursuivre davantage de menaces, ils poursuivent une machine capable d’en créer sans cesse de nouvelles », explique Shen. Il décrit le rythme attendu du changement de manière encore plus marquée : « Ce qui était suffisant au cours des 10 dernières années ne sera pas suffisant dans les six prochains mois. »

La détection continue d’apporter des informations et des capacités de réponse dont les entreprises ont besoin, mais une alerte tardive ne peut pas annuler une exécution déjà accomplie. Si une attaque peut voler une session authentifiée ou exfiltrer des informations avant qu’une décision défensive n’arrive, une latence de détection plus faible laisse malgré tout un intervalle pendant lequel du code distant non fiable s’exécute localement. La question de conception est de savoir si le terminal peut éviter cette exposition tout en préservant un accès exploitable à l’application.

Shen soutient que déplacer l’exécution offre une alternative. « Il ne suffit plus de se demander uniquement si une menace peut être détectée », dit-il. Il enchaîne avec le principe de conception qui sous-tend l’approche commerciale de CloudMosa : « L’approche la plus robuste consiste à empêcher qu’un code risqué ou malveillant n’atteigne l’appareil dès le départ. » Pour une entreprise qui évalue cette proposition, la question technique est de savoir si les utilisateurs peuvent interagir avec une application web sans placer son contenu actif d’origine sur leurs terminaux.

Puffin modifie l’endroit où le code web actif s’exécute

Puffin met en œuvre cette idée, de sorte que l’intérêt commercial de CloudMosa est directement lié à l’affirmation selon laquelle l’exécution à distance améliore la sécurité. « Dans un navigateur conventionnel, le risque arrive jusqu’à l’appareil », explique Shen. « Dans un modèle cloud isolé, le risque en est tenu à l’écart. » La différence pratique tient à la machine qui reçoit et traite le contenu web exécutable avant que l’utilisateur ne voie la page résultante et n’interagisse avec elle.

Avec Puffin, la session de navigateur d’origine s’exécute dans un environnement cloud isolé et jetable. Le JavaScript, le WebAssembly et les autres charges exécutables y sont traités, ainsi que le rendu HTML nécessaire à la construction de la page. Le terminal reçoit un flux de pixels rendu, tandis que les clics, la saisie et le défilement renvoient les interactions de l’utilisateur vers la session distante.

Comme ce traitement a lieu à distance, le terminal n’analyse pas, n’exécute pas et ne stocke pas le code web actif d’origine dans la conception de Puffin. La rastérisation de l’affichage, c’est-à-dire le travail qui produit les pixels affichés à l’utilisateur, constitue la partie du système exposée au terminal. Le rendu HTML et l’exécution active restent dans le cloud, créant la séparation sur laquelle reposent les affirmations de sécurité de CloudMosa.

CloudMosa affirme que la rastérisation de l’affichage représente environ 5 % de la charge totale d’un navigateur. Cette estimation soutient l’argument de conception de l’entreprise, car elle répartit le traitement du navigateur entre une charge d’affichage relativement faible sur le terminal et une charge bien plus importante côté cloud. Selon ce modèle, le terminal peut offrir une expérience de navigation interactive pendant que le cloud gère le code actif qui crée la page.

À partir de cette même séparation, CloudMosa affirme que les exploits zero-day et le code polymorphe généré par l’IA n’ont aucune charge exécutable en cours d’exécution sur le terminal. L’entreprise affirme également que les attaques sans fichier, le contenu SaaS compromis et les menaces sur la chaîne d’approvisionnement restent confinés dans l’environnement cloud jetable. CloudMosa vend le système qui fournit ce confinement ; les entreprises qui évaluent ces résultats de sécurité doivent donc distinguer la frontière d’exécution observable des affirmations de protection plus larges que l’entreprise en déduit.

Une application SaaS compromise montre comment cette frontière fonctionne. Avec l’exécution locale conventionnelle dans le navigateur, un contenu actif malveillant livré via ce service de confiance peut s’exécuter là où la session d’entreprise est déjà ouverte. Dans le modèle de Puffin, le contenu compromis s’exécute dans la session de navigateur distante isolée tandis que le terminal reçoit son résultat rendu, ce qui modifie la frontière que le code web devrait franchir pour s’exécuter localement.

CloudMosa décrit le principe qui sous-tend ce choix comme étant « paranoïaque par conception ». En pratique, ce principe part d’un environnement de menace au pire des cas, dans lequel un contenu hostile peut échapper à la détection et les défenses du terminal peuvent échouer, de sorte que l’isolation limite l’endroit où ce contenu s’exécute. Shen relie directement ce principe à sa mise en œuvre : « Ce n’est pas seulement une philosophie, c’est quelque chose qui se reflète directement dans l’architecture elle-même. »

Cet usage de sécurité découle d’une raison plus ancienne de déplacer le traitement du navigateur vers le cloud. CloudMosa a initialement conçu son approche de navigateur cloud pour améliorer les performances et l’accessibilité du navigateur, car l’entreprise s’attendait à ce que le travail en entreprise se déplace de plus en plus vers le navigateur. À mesure que davantage de traitement passait dans le cloud, cette même séparation entre affichage sur le terminal et exécution à distance est aussi devenue utile pour contenir le code navigateur hostile.

Shen relie cet historique à l’environnement de menace actuel : « CloudMosa a initialement conçu son architecture cloud pour améliorer les performances et l’accessibilité du navigateur, en partant du principe que le travail en entreprise se déplacerait de plus en plus vers le navigateur. Le piratage assisté par l’IA d’aujourd’hui a validé cette architecture, démontrant que ce qui a été conçu pour la performance fournit aussi une base solide pour la sécurité moderne des entreprises. » L’accent du produit a changé, mais son mécanisme sous-jacent continue de déplacer une part importante du traitement du navigateur hors de l’appareil.

CloudMosa qualifie le changement qui en résulte de passage d’une « sécurité suffisante sur l’appareil à une sécurité étanche dans le cloud ». Comme CloudMosa vend Puffin Cloud Security, « étanche » est une qualification fournisseur de la protection apportée par sa conception. L’isolation traite spécifiquement l’exposition créée par l’exécution web locale, tandis que les identifiants, l’autorisation, la politique de trafic, l’accès aux applications et les décisions de sécurité associées restent des problèmes de contrôle distincts.

Cette affirmation plus ciblée sur l’exécution donne à une équipe de sécurité un moyen pratique d’évaluer la conception. L’équipe peut examiner ce qui se passe lorsque la détection manque un script obscurci, un exploit jusque-là inconnu ou un contenu malveillant livré via une chaîne d’approvisionnement SaaS compromise. Dans la conception de Puffin, la réponse de CloudMosa est que le code s’exécute toujours, mais que son exécution reste dans un environnement cloud jetable au lieu du terminal de l’utilisateur.

Shen affirme que CloudMosa a adopté ce modèle de menace plus sévère plus tôt que la plupart des organisations et soutient que les attaques actuelles assistées par l’IA rendent cette posture de plus en plus pertinente. Son argument alimente un marché dans lequel CloudMosa bénéficie d’un usage plus large de l’isolation distante du navigateur ; la mise en œuvre peut donc être évaluée séparément de la caractérisation plus large que l’entreprise fait de sa protection. Le choix de conception directement vérifiable est l’endroit où le code web actif s’exécute et ce qui atteint le terminal.

Les agents IA transforment le navigateur à la fois en outil et en cible

La frontière d’exécution compte davantage lorsque le logiciel lui-même pilote le navigateur avec l’autorité d’une personne. Des agents IA autonomes peuvent agir via des sessions de navigateur avec des privilèges de niveau utilisateur, donnant au contenu web malveillant un processus actif de prise de décision à cibler en plus du logiciel du navigateur. Shen identifie l’injection de prompt, le détournement de session et la compromission indirecte via du contenu web compromis comme des risques particuliers pour ces agents.

De récentes enquêtes de 2026 ont montré que 92 % des professionnels de la sécurité s’inquiètent de l’impact des agents IA et que 48 % citent l’IA agentique comme principal vecteur d’attaque de l’année. Ces chiffres de préoccupation correspondent à une évolution technique de la session de navigateur, car un agent peut exercer une autorité une fois qu’il entre dans un workflow authentifié. Le risque qui en résulte dépend à la fois de ce qui atteint la session et des actions que l’agent peut entreprendre.

Pour un utilisateur humain, un contenu malveillant dans le navigateur peut tenter d’exploiter le logiciel ou de voler une session. Un agent autonome ajoute une autre cible, car des instructions et du contenu web peuvent influencer ce qu’il décide de faire tout en disposant d’autorisations de niveau utilisateur. L’intégrité de la session devient particulièrement importante dans ce modèle, car l’agent peut continuer à agir via l’autorité attachée à une session compromise ou manipulée.

CloudMosa propose d’exécuter l’activité de navigateur d’un agent IA dans des sandboxes cloud isolées, en étendant la même frontière d’exécution de Puffin aux workflows d’agents. Le terminal reçoit le flux de pixels rendu, et CloudMosa affirme que cette organisation empêche le contenu malveillant d’interagir directement avec l’appareil, ses identifiants ou les systèmes connectés. Comme CloudMosa bénéficie commercialement de l’application de Puffin à ces charges de travail, cette affirmation doit être évaluée comme une affirmation de sécurité d’un fournisseur, tandis que l’injection de prompt et les décisions d’accès restent des contrôles avec lesquels l’isolation doit fonctionner de concert.

L’isolation comble une lacune dans la stack de sécurité

Le cas des agents montre aussi où l’isolation de l’exécution s’insère par rapport aux contrôles d’entreprise existants. Les secure web gateways (SWG), les cloud access security brokers (CASB) et les systèmes de zero trust network access (ZTNA) acheminent le trafic, appliquent les politiques et gouvernent l’accès, tandis que les systèmes de détection identifient les menaces et soutiennent la réponse. CloudMosa soutient que l’exécution locale dans le navigateur laisse un autre point de contrôle : l’endroit où le contenu actif s’exécute une fois les décisions d’accès et de routage prises.

Puffin est donc positionné comme une couche complémentaire à ces investissements, ce qui sert aussi l’intérêt commercial de CloudMosa en ajoutant son produit aux stacks de sécurité existantes. Une équipe de sécurité peut faire passer certaines sessions à haut risque par un environnement cloud isolé pendant que son SWG, son CASB, son ZTNA et ses autres contrôles continuent d’assurer leurs fonctions actuelles. « L’objectif n’est pas de défaire les investissements existants, mais de les rendre plus complets », explique Shen.

Cette même frontière d’exécution modifie aussi la manière dont la propriété du terminal affecte la politique du navigateur. CloudMosa affirme qu’une politique au niveau du navigateur peut s’appliquer lorsqu’un utilisateur se connecte via un VPN ou un réseau domestique, et lorsque l’appareil est géré par l’entreprise ou qu’il s’agit d’un système bring-your-own-device (BYOD) non géré. Ces cas sont importants parce que les sessions de navigateur d’entreprise peuvent s’étendre à des terminaux et à des réseaux sur lesquels les équipes de sécurité disposent de niveaux d’autorité de gestion différents.

Sur un appareil géré, l’isolation peut couvrir une session sélectionnée même lorsque des contrôles du terminal sont déjà en place. Un appareil BYOD non géré peut faire passer la charge de travail navigateur correspondante par le cloud, réduisant la dépendance aux contrôles d’exécution locale. Les cas VPN et réseau domestique conservent la même frontière d’exécution, car la charge de travail active du navigateur reste dans l’environnement isolé indépendamment du réseau immédiat de l’utilisateur.

Cette flexibilité permet aussi une adoption sélective. Shen explique que les organisations peuvent commencer par des cas limités, comme l’accès à des SaaS à haut risque ou des workflows d’agents IA, puis étendre l’usage sans perturber les outils déjà déployés. CloudMosa bénéficie si ces essais s’étendent à des déploiements Puffin plus larges, tandis que l’approche progressive donne aux équipes de sécurité un moyen circonscrit d’évaluer l’isolation de l’exécution autour de sessions où un contenu malveillant pourrait avoir de graves conséquences.

La stack qui en résulte attribue à chaque catégorie de contrôle un rôle distinct. Les produits d’accès décident qui ou quoi peut atteindre une ressource ; les passerelles et les brokers gèrent le routage et les politiques ; les systèmes de détection recherchent les activités malveillantes ; et l’isolation du navigateur détermine où la charge de travail web active s’exécute. L’emplacement de l’exécution constitue donc une frontière de contrôle spécifique que les équipes peuvent évaluer en parallèle de ces fonctions existantes.

L’architecture et la mise en œuvre doivent être évaluées séparément

Cette répartition des responsabilités aide aussi à distinguer le mécanisme de Puffin des affirmations de CloudMosa sur la protection qu’il fournit. Gartner prévoit que plus de 85 % des charges de travail d’entreprise seront accessibles via le navigateur d’ici 2027, des rapports du secteur décrivent une hausse des attaques basées sur le navigateur au cours des deux dernières années, et le chiffre de 89 % concernant les adversaires utilisant l’IA indique une génération d’attaques plus rapide. Les chiffres de l’enquête 2026, 92 % et 48 %, ajoutent une mesure de l’inquiétude des professionnels face au risque lié aux agents IA.

Ces chiffres de contexte expliquent pourquoi l’exécution dans le navigateur reçoit davantage d’attention, tandis que CloudMosa avance l’argument de sécurité spécifique en faveur de Puffin. L’entreprise fournit également l’estimation d’environ 5 % pour la rastérisation, qui soutient son argument sur la charge de travail du terminal. Comme CloudMosa vend le produit et bénéficie du fait que les entreprises adhèrent à l’argument en faveur de l’isolation distante du navigateur, ses affirmations sur le confinement, la résistance aux zero-day et les protections associées doivent être évaluées en gardant à l’esprit cette incitation commerciale.

L’évaluation peut distinguer deux questions. La première est architecturale : conserver le code web actif d’origine dans un navigateur cloud isolé modifie l’endroit où le code s’exécute et le contenu actif qui atteint le terminal. La seconde concerne la mise en œuvre : une équipe de sécurité peut tester si Puffin fournit le confinement et la résistance aux zero-day que CloudMosa revendique dans le cadre de ses propres applications, politiques, workflows d’agents et hypothèses de menace.

Shen présente l’évolution sous-jacente de la menace comme suffisamment importante pour obliger les entreprises à repenser le navigateur « de fond en comble ». Il formule le choix pour les responsables de la sécurité de manière plus tranchée : « repenser avec prévoyance, ou attendre que le recul rende la leçon inévitable ». Pour les équipes qui évaluent cette proposition, la décision concrète porte sur l’endroit où le code du navigateur et les charges de travail navigateur des agents IA peuvent s’exécuter, et sur les contrôles qui gouvernent les sessions qui les entourent.

Principaux points à retenir pour les dirigeants

• Faire de l’emplacement de l’exécution une décision de sécurité : À mesure que les charges de travail d’entreprise se concentrent dans des sessions de navigateur authentifiées, les équipes de sécurité doivent gouverner l’endroit où le code web actif s’exécute. L’exécution à distance peut réduire l’exposition du terminal avant même que la détection et la réponse ne commencent.
• Tenir compte de la vitesse des attaques pilotées par l’IA : Les attaques générées par l’IA, polymorphes et sans fichier accentuent la pression sur les systèmes de détection en créant des menaces qui évoluent rapidement. Les architectes sécurité peuvent évaluer des contrôles qui contiennent l’exécution même lorsque la classification arrive tard ou manque un nouveau variant.
• Tester l’isolation distante du navigateur sur des charges de travail à haut risque : Puffin traite le JavaScript, le WebAssembly et les autres contenus actifs dans des environnements cloud jetables tout en envoyant un rendu aux terminaux. Les équipes de sécurité qui évaluent ce modèle doivent tester de manière indépendante les affirmations de CloudMosa sur le confinement et la résistance aux zero-day.
• Isoler les sessions de navigateur des agents IA : Les agents autonomes combinent un accès authentifié avec la capacité d’agir sur du contenu web, ce qui accroît l’exposition à l’injection de prompt, au détournement de session et au contenu compromis. Les organisations qui déploient des agents basés sur le navigateur peuvent placer leurs sessions dans des environnements isolés et gouverner étroitement les identifiants et les autorisations.
• Ajouter l’isolation de l’exécution aux contrôles de sécurité existants : Les SWG, CASB, ZTNA et systèmes de détection traitent l’accès, le trafic, les politiques et la réponse, tandis que l’isolation du navigateur contrôle l’endroit où le contenu actif s’exécute. Les entreprises peuvent commencer par des SaaS à haut risque, des cas BYOD ou des workflows d’agents, puis évaluer si l’isolation renforce la stack existante.
• Distinguer l’architecture des affirmations du fournisseur : L’isolation distante du navigateur crée une frontière observable en maintenant le code web actif d’origine à l’écart du terminal, tandis que les affirmations de protection plus larges dépendent de la mise en œuvre. Les équipes de sécurité peuvent valider Puffin par rapport à leurs propres applications, politiques, workflows et modèles de menace avant d’étendre le déploiement.