En bref : signaux canvas, cadence et curseur pour bloquer les agents IA
- Trois défenses, toutes contournées : Chaque stack embarque un WAF, un gestionnaire de bots CDN et un CAPTCHA. OpenAI Operator, Claude for Chrome, Playwright et Puppeteer passent les trois parce qu'ils s'exécutent dans un vrai moteur de navigateur et résolvent les défis JavaScript à vitesse humaine.
- Quatre signaux navigateur : Quatre signaux uniquement navigateur les trahissent: entropie du canvas fingerprint, cadence de session, géométrie du curseur et empreinte polices plus WebGL. cside les collecte depuis une seule balise, analyse plus de 250 signaux par session, nomme le framework d'automatisation et renvoie un verdict avant que le login ou le checkout soit soumis.
- Politique par page : Sur les pages de login et de checkout, bloquez durement les sessions identifiées comme Playwright, Puppeteer ou Selenium. Pour les sessions automatisées ambiguës, injectez un challenge. Autorisez les crawlers connus à indexer. Le plan gratuit cside de 1000 appels API par mois suffit pour d'abord mesurer le volume réel d'agents.
Peu de temps ? Découvrez la détection d'agents IA de cside. Elle couvre tout ce qui suit en un seul déploiement.
Pour bloquer les agents IA sur votre site web, vous devez d'abord les détecter, et cette détection doit se produire à l'intérieur du navigateur. Les agents automatisés tournent désormais dans de vrais moteurs de navigateur, si bien que les contrôles au niveau réseau sur lesquels s'appuient la plupart des équipes ne les voient jamais. Ce guide couvre les signaux qui trahissent un agent et la façon de transformer un verdict en blocage, en défi ou en autorisation.
Bloquer les agents IA sur un site web commence par comprendre pourquoi les outils dont disposent déjà la plupart des équipes n'y parviennent pas. Les WAF bloquent les IP malveillantes connues et les motifs de requête. Les gestionnaires de bots des CDN filtrent le trafic non issu d'un navigateur. Les défis CAPTCHA bloquent les requêtes incapables d'exécuter du JavaScript. Des outils comme OpenAI Operator, Claude for Chrome, Playwright et Puppeteer passent tous ces contrôles, car ils tournent dans de vrais moteurs de navigateur, exécutent du JavaScript, résolvent les CAPTCHA et opèrent à des vitesses humaines. Les signaux qui les révèlent n'existent qu'au niveau du navigateur.
Étape 1 : comprendre quels signaux identifient réellement les agents IA
Quatre catégories de signaux distinguent de façon fiable les agents IA des utilisateurs humains. Les quatre nécessitent un script exécuté dans le navigateur pour être observées.
Entropie de l'empreinte canvas. Chaque appareil réel restitue le canvas du navigateur différemment selon son GPU, son système d'exploitation et son moteur de rendu des polices. Les appareils réels produisent des empreintes canvas à forte entropie en raison de la variété des configurations matérielles d'un utilisateur à l'autre. Les agents IA qui tournent dans des environnements minimaux ou virtualisés produisent une entropie plus faible, car l'environnement de rendu est moins varié. Cette différence est mesurable dans la sortie du canvas.
Cadence de session. Les utilisateurs humains tapent, cliquent et naviguent avec une variation temporelle naturelle. Ce sont de petites irrégularités organiques produites par l'attention, la familiarité et le contrôle moteur. Les agents IA exécutent les événements du navigateur à des intervalles d'une précision mécanique. Un champ de formulaire rempli avec un intervalle fixe entre chaque caractère, répété de manière constante sur plusieurs interactions, n'est pas un schéma humain.
Géométrie du curseur. Les trajectoires de souris humaines sont courbes, elles accélèrent et décélèrent, et comportent des micro-corrections avant d'atteindre une cible. Les agents IA produisent des trajectoires de curseur géométriquement rectilignes, ou aucun mouvement de curseur entre les interactions. Les utilisateurs réels ne produisent presque jamais de trajectoires de curseur en ligne droite.
Empreinte des polices et WebGL. Les appareils d'utilisateurs réels disposent d'un jeu complet de polices système et d'un GPU qui produit une sortie WebGL cohérente. Les agents IA qui tournent dans des environnements minimaux ont un jeu de polices restreint et un GPU virtualisé ou absent. La combinaison de polices manquantes et d'une signature WebGL anormale est un puissant élément de distinction.
Étape 2 : déployer un script de détection côté navigateur
Le script de détection doit se charger avec la page et commencer à collecter des signaux avant que l'utilisateur n'interagisse avec le moindre élément. Ce moment compte : les signaux sont observables tout au long de la session, et les premiers points de données établissent la référence comportementale à laquelle les événements suivants sont comparés.
Un script côté navigateur issu de la détection d'agents IA de cside se charge avec la page, collecte passivement les quatre catégories de signaux et est prêt à renvoyer un verdict d'API au moment où l'utilisateur atteint un formulaire de connexion, un paiement ou tout autre parcours que vous souhaitez protéger.
Le script s'intègre sous la forme d'une seule balise dans l'en-tête de la page. Aucune modification de SDK côté serveur n'est requise.
Étape 3 : appeler l'API et lire le verdict
Une fois que le script a collecté les signaux, un seul appel d'API renvoie un verdict en temps réel pour la session. cside analyse plus de 250 signaux par session et les combine en un score de risque, signalant les sessions d'agents IA et automatisées et identifiant, lorsque c'est possible, les outils d'automatisation nommés comme OpenAI Operator, Claude for Chrome, Playwright, Puppeteer et Selenium. La réponse indique aussi si la connexion passe par un VPN ou un proxy, et renvoie un identifiant d'appareil stable pour la session.
Le verdict est disponible avant que le formulaire ne soit soumis ou que l'action critique ne se déclenche, de sorte que votre application peut décider quoi faire pendant que la session est encore ouverte.
Étape 4 : définir votre réponse selon le type de session
Bloquer chaque session d'agent IA détectée n'est pas toujours la bonne réponse. L'action à mener dépend de l'identité présumée de l'agent.
Bloquer : les sessions où le verdict nomme un outil d'abus connu (Playwright, Puppeteer, Selenium) sur un parcours de connexion ou de paiement. Ces outils n'ont aucun usage légitime destiné aux utilisateurs sur ces pages.
Défier : les sessions signalées comme automatisées dont le type d'agent est ambigu. Injectez un défi pour confirmer la présence humaine avant d'autoriser la poursuite de l'interaction.
Autoriser : les sessions de crawlers que vous reconnaissez et acceptez, comme vos propres outils de surveillance, les crawlers de moteurs de recherche opérant sur des pages qu'ils doivent indexer, ou les intégrations d'API légitimes que vous avez autorisées. Elles produisent des signaux d'automatisation mais ne justifient aucune action.
Journaliser et surveiller : les sessions sur des pages non critiques où le blocage ne se justifie pas mais où la visibilité est utile. L'identifiant d'appareil et le type d'agent vous permettent de dresser un tableau de l'activité automatisée sur l'ensemble de votre site sans prendre de mesure perturbatrice.
Étape 5 : appliquer les actions de réponse dans votre application
Une fois le verdict reçu, votre application applique la réponse. Mises en œuvre typiques :
Pour les parcours de connexion : vérifiez le verdict d'agent avant de traiter la demande d'authentification. Si la session est signalée comme un outil d'abus connu, renvoyez un 403 avant de valider les identifiants. Aucune validation de mot de passe n'a lieu, ce qui réduit la charge sur la base de données due au credential stuffing en plus de bloquer la session.
Pour les parcours de paiement : vérifiez le verdict d'agent et le score de risque de la session avant d'afficher le formulaire de paiement. Les sessions automatisées à haut risque ne devraient pas atteindre l'étape du champ de paiement.
Pour les parcours d'inscription : comparez l'identifiant d'appareil aux comptes liés connus avant de finaliser la création du compte. Cela répond au multi-comptes ainsi qu'à la création de comptes pilotée par des agents IA et aux fausses inscriptions.
Où le blocage s'inscrit dans votre stack
La détection côté navigateur ne remplace pas votre WAF ni votre gestionnaire de bots CDN. Elle vient à leurs côtés et couvre la faille qu'ils ne peuvent atteindre : le trafic automatisé qui arrive au sein d'une véritable session de navigateur. Conservez les contrôles au niveau réseau pour le trafic volumétrique et non issu d'un navigateur qu'ils gèrent bien, et ajoutez des verdicts côté navigateur pour les agents qui franchissent ces contrôles. Ensemble, les deux couches vous offrent une décision par session sur les parcours de connexion, de paiement et d'inscription sans sur-bloquer les crawlers que vous voulez conserver.
À lire également
- Détection d'agents IA : comment cside évalue les sessions d'agents et automatisées à partir d'une seule balise de script
- Prise de contrôle de compte : stopper l'abus de connexion automatisé et le credential stuffing
- Multi-comptes : relier les appareils pour repérer la création de comptes pilotée par des agents
