Les équipes de sécurité affrontent deux problèmes liés à l’intelligence artificielle simultanément. Les adversaires utilisent l’IA pour améliorer des kits de phishing, pour créer des pièges et pour changer leur infrastructure plus vite que les listes de blocage peuvent les suivre. Les employés adoptent des outils d’IA plus rapidement que les équipes de sécurité peuvent les examiner, ils copient des données sensibles dans des LLM, ils accordent des permissions OAuth à des agents IA et ils installent des extensions de navigateur IA qui n’ont pas été vérifiées.
Ces deux problèmes se manifestent au même endroit : le navigateur. La façon la plus efficace de les traiter est d’utiliser une seule plateforme qui voit ce qui se passe dans les sessions du navigateur, et pas deux outils séparés qui chacun ne voit qu’une partie du tableau.
Les attaques facilitées par l’IA surpassent les défenses traditionnelles
La sécurité a toujours été une course entre attaquants et défenseurs, mais l’IA accélère le côté des attaquants. Les kits de phishing sont copiés, modifiés et mis sur le marché plus vite que jamais. L’IA multiplie la puissance de l’écosystème criminel et elle change la donne pour les défenseurs dans trois domaines.
L’IA a amplifié la création d’outils par les attaquants: Les attaquants utilisent l’IA comme un ingénieur pourrait le faire : pour multiplier leur production. Nous voyons les attaquants utiliser massivement l’IA dans la création et l’évolution des outils et kits de PhaaS.
L’évolution rapide de ClickFix, avec des nouvelles techniques comme InstallFix et ConsentFix, est un exemple. Et le phishing par code de dispositif, qui exploite un flux OAuth légitime pour contourner totalement l’authentification multifacteur et les passkeys, a explosé depuis une curiosité de recherche jusqu’à une offre industrielle de PhaaS, avec plus de 18 kits qui sont activement surveillés. Comme les kits d’attaque de type AitM et les kits de code de dispositif fusionnent dans des plateformes uniques, nous voyons des signes d’une forte utilisation de l’IA, comme nous avons observé quand nous avons examiné le Panel de Doko et les kits dérivés, qui sont largement utilisés par ShinyHunters et BlackFile.
Les détections basées sur des IoC sont de moins en moins efficaces: L’IA a aussi réduit le coût de construire une infrastructure de phishing convaincante. Une page de phishing qui semble authentique peut être créée en quelques minutes, elle peut être déployée sur un nouveau domaine, elle peut réussir à tromper des victimes et elle peut être changée avant qu’un service de réputation la marque.
Selon Spamhaus, 89% des domaines de phishing sont actifs moins de deux jours. Pour les organisations qui dépendent de listes de blocage et de flux d’IoC, chaque attaque de phishing est en fait une attaque zero-day. Elle n’a jamais été vue avant, et la prochaine ne sera pas identique.
Combiné avec l’utilisation abusive de sites légitimes pour héberger et distribuer des liens de phishing, il est très difficile de distinguer le bon du mauvais quand on s’appuie sur des IoC basiques comme les domaines et les IP. Des exemples récents montrent même que les attaquants hébergent des liens malveillants via une fonctionnalité légitime de partage de chat IA, une technique que nous détectons comme LLMShare.
L’IA facilite la construction et l’exécution de campagnes multicanales: Les données de Push montrent qu’environ 1 charge malveillante sur 3 arrive via des canaux autres que l’email, comme la publicité malveillante, les réseaux sociaux ou l’empoisonnement de résultats de recherche. ClickFix est un exemple encore plus clair, où 4 charges sur 5 arrivent spécifiquement par les résultats des moteurs de recherche. La sécurité des emails est structurement incapable de voir les canaux de distribution qui grandissent le plus vite.
L’exemple LLMShare est aussi pertinent ici : les attaquants ont diffusé les liens via des publicités dans les moteurs de recherche, qui sont très difficiles à identifier, ce qui montre comment la distribution hors email, l’abus de sites légitimes et l’utilisation abusive des outils d’IA peuvent se combiner pour un impact maximal.
Ces trois tendances convergent dans la session du navigateur, où la distribution de la charge malveillante et la prise de contrôle du compte se produisent réellement. C’est le niveau où la détection doit opérer, et il faut analyser le comportement de la page, l’exécution des scripts et les mécanismes malveillants comme le vol de session, la copie malveillante, les téléchargements de fichiers, plutôt que de comparer des domaines à une liste. Cela est particulièrement vrai car beaucoup d’attaques se déroulent maintenant entièrement dans la session du navigateur sans toucher l’équipement terminal.
L’adoption non contrôlée de l’IA est la deuxième partie du problème
Sur le côté des employés, l’adoption dépasse la gouvernance.
Il existe une directive des organisations pour utiliser plus d’IA afin de rester compétitives. Essayer de bloquer ou de freiner ce processus, ce qui nuit aux gains potentiels d’efficacité et de productivité, n’est pas une option viable. Les équipes de sécurité doivent donc trouver une façon d’adopter l’IA de manière sûre et sécurisée.
Les signes montrent que cela est hors de contrôle pour beaucoup d’organisations. Le rapport Verizon DBIR de 2026 a trouvé que 45% des employés sont maintenant des utilisateurs réguliers d’IA sur des dispositifs corporatifs, et 67% utilisent des comptes non corporatifs. Les données de Push montrent que l’organisation moyenne possède 16 applications IA différentes, 17 extensions de navigateur IA et 17 intégrations OAuth connectées à l’IA, et la plupart ne sont pas approuvées. Pour les téléchargements de fichiers vers des outils d’IA, 38% sont effectués depuis des comptes personnels cachés plutôt que depuis des comptes organisationnels.
Les risques s’accumulent vite. Des données sensibles quittent l’organisation via des copies dans le presse-papier et des téléchargements de fichiers vers des outils d’IA que les équipes de sécurité n’ont pas approuvés et qu’ils ne peuvent pas surveiller. Les extensions de navigateur IA collectent le contexte de navigation depuis des applications internes, ce qui crée un chemin d’exfiltration de données qui opère hors des systèmes traditionnels de DLP.
Les agents IA demandent des permissions OAuth pour accéder aux données organisationnelles. Ils extraient des informations d’un système, ils les analysent dans un autre et ils les présentent dans un troisième. Les connexions MCP créent maintenant un accès persistant et autorisé que la plupart des organisations ne peuvent ni voir ni contrôler.
La violation de Vercel en 2026 montre où cela peut mener : une intégration OAuth d’un fournisseur de SaaS IA tiers compromis a été le point d’entrée dans un environnement Google Workspace corporatif. Les campagnes de ShinyHunters contre Salesloft Drift et Gainsight ont montré le même schéma à grande échelle l’année dernière.
Le navigateur voit les deux côtés, et c’est l’objectif
Ces deux problèmes ont une cause commune : des activités pertinentes pour la sécurité se produisent dans les sessions du navigateur que la plupart des outils ne peuvent observer.
Beaucoup de ces techniques d’attaque sont natives du navigateur, ce qui signifie que les outils de monitoring traditionnels n’ont simplement pas la visibilité nécessaire dans la session du navigateur pour les détecter et les intercepter.
Le navigateur est aussi le meilleur niveau unique pour obtenir de la visibilité et du contrôle sur l’utilisation de l’IA. Il voit les applications, les autorisations OAuth, les extensions et le contexte du compte. Et les outils d’IA corporatifs comme Claude, ChatGPT Enterprise, Microsoft Copilot, Gemini for Workspace offrent de plus en plus des logs natifs des prompts et des contrôles DLP sur leurs plans corporatifs.
Combiner les deux signifie que vous pouvez utiliser le navigateur pour imposer les outils d’IA que les employés peuvent utiliser et pour garantir qu’ils atteignent l’environnement corporatif plutôt qu’un compte personnel. Vous pouvez ensuite utiliser les contrôles natifs de la plateforme pour gérer l’activité dans cet environnement.
Le navigateur rend les contrôles de plateforme efficaces et il empêche l’utilisation cachée d’IA qui pourrait autrement passer inaperçue. Par exemple, si les employés utilisent des comptes personnels, il n’existe pas de logs corporatifs à inspecter. Et pour la catégorie grandissante des agents IA, des navigateurs agentiques et des outils connectés à MCP qui opèrent via des autorisations OAuth plutôt que via une interaction directe avec l’utilisateur, le navigateur est l’endroit où les décisions de consentement qui autorisent ces agents sont faites.
Questions à poser quand on évalue des solutions basées sur le navigateur
Quand vous évaluez des plateformes dans ce domaine, quatre questions séparent les outils qui offrent une véritable télémetrie de sécurité de ceux qui offrent seulement des rapports de conformité avec une valeur d’investigation limitée.
L’outil capture-t-il les interactions avec l’IA qui n’ont pas provoqué une violation de politique ? Les outils axés sur l’application des règles enregistrent ce qu’ils ont bloqué : des téléchargements interdits, l’utilisation d’applications non approuvées, des noms de fichiers signalés. Cela est utile pour la conformité, mais les événements les plus significatifs sont souvent ceux qui semblaient normaux au moment : une extension approuvée qui change ses permissions en silence, une autorisation OAuth qui était techniquement permise mais qui ne devrait pas l’être, un utilisateur dont le comportement a changé graduellement avant un départ. Demandez si l’outil collecte la télémetrie pour les événements permis, pas seulement pour les violations.
L’outil capture-t-il le flux complet de consentement OAuth quand un agent IA demande un accès aux données organisationnelles ? La plupart des outils axés sur l’application traitent OAuth comme binaire : application approuvée ou application bloquée. Cela était un modèle raisonnable quand les autorisations OAuth étaient des intégrations gérées par l’IT. Ce n’est pas suffisant pour l’IA agentique, où les autorisations de consentement initiées par l’utilisateur se produisent dans les sessions du navigateur avec des périmètres larges et souvent sans que l’équipe de sécurité le sache. Le bon outil capture les périmètres qui étaient demandés, qui les a approuvés et quelle application les a obtenus. Il peut aussi avertir ou bloquer en temps réel.
Quand une nouvelle technique d’attaque apparaît et que aucun outil a un signature pour elle, à quelle vitesse la plateforme la détecte ? Les attaquants changent leur infrastructure en quelques heures et ils utilisent l’IA pour générer de nouveaux pièges à grande échelle. Un modèle de détection basé sur des listes de blocage et des indicateurs de mauvaises intentions est structurement en retard sur toute technique nouvelle. Demandez aux fournisseurs de vous montrer une détection spécifique qui a fonctionné avant que l’infrastructure apparaisse sur un flux de menaces.
Quelle télémetrie atteint votre SIEM : seulement les alertes, ou les données de session qui permettent de les investiguer ? Certains outils envoyent des métadonnées d’alertes : violations de politiques, horodatages, utilisateurs impliqués. D’autres transmettent une télémetrie plus large : réutilisation de credentials, connexions à des applications, installations d’extensions, détections de kits de phishing, téléchargements de fichiers, activité du presse-papier, autorisations OAuth. La différence décide si votre SOC peut investiguer depuis l’événement du SIEM lui-même ou si il doit retourner vers la console du fournisseur pour obtenir les preuves.
Comment cela se présente en pratique
Push Security est une plateforme de détection et réponse aux menaces basée sur le navigateur. Elle est déployée comme une extension légère de navigateur qui peut être installée dans une organisation en moins d’une heure sans migration de navigateur nécessaire. Elle traite la visibilité et le contrôle de l’IA comme des fonctionnalités qui s’étendent naturellement depuis l’architecture de base de la plateforme : une télémetrie profonde au niveau du navigateur qui alimente la détection des attaques et la gouvernance de l’IA dans un seul outil.
Avec Push, vous pouvez :
-
Détecter et stopper les techniques d’attaque émergentes basées sur le navigateur, incluant le phishing facilité par l’IA et les attaques de style *Fix qui évoluent vite.
-
Profiter du pipeline de détection agentique de Push, qui recherche continuellement dans les environnements clients pour identifier des menaces émergentes et livrer de nouvelles détections.
-
Transmettre la télémetrie à votre SIEM pour une large variété d’événements, incluant des détections d’attaques, des nouvelles installations d’extensions de navigateur ou de nouvelles applications adoptées, des changements de permissions d’extensions, des téléchargements de fichiers, des copies dans le presse-papier, des connexions à des applications, des réutilisations de credentials, des autorisations OAuth et plus.
-
Bloquer des téléchargements et uploads de fichiers.
-
Bloquer des copies dans le presse-papier de données sensibles, avec des motifs basés sur des regex que vous pouvez définir.
-
Écrire vos propres règles YAML custom qui ciblent des éléments spécifiques du DOM de la page, des requêtes et des réponses web, des headers HTTP comme les cookies et plus.
Les équipes de sécurité ne doivent pas choisir entre stopper les attaques facilitées par l’IA et gérer l’utilisation de l’IA. Elles ne doivent pas payer pour deux outils qui chacun ne voit qu’une partie du tableau.