Agents IA derrière Cloudflare : comment arrêter les boucles reCAPTCHA sur votre site

Pourquoi les agents IA derrière Cloudflare déclenchent des boucles reCAPTCHA

Nous avons utilisé une flotte d'agents IA contre notre propre site — audits de contenu, scans SEO, générateurs de pages, pousse de brouillons. Tous accèdent à sengo.com via HTTPS, exactement comme le ferait un visiteur régulier. Cela a fonctionné sans problème pendant des mois. Puis un matin, les visiteurs mobiles ont commencé à signaler une superposition de style Cloudflare sur la page d'accueil avec le message “Ce site dépasse le quota gratuit de reCAPTCHA Enterprise.”

La connexion fonctionnait toujours. Wp-admin allait bien. Mais les pages marketing publiques étaient cassées pour une partie des vrais visiteurs. Après avoir exclu notre plugin de sécurité et le CAPTCHA de notre formulaire de contact, nous avons trouvé la vraie source : nos agents eux-mêmes. Chaque script que nous exécutâmes était, du point de vue de Cloudflare, un robot — et un robot qui revenait des centaines de fois par jour d'une seule IP résidentielle.

C'est la première leçon sur les agents IA derrière Cloudflare : votre propre automatisation est un trafic hostile par défaut. Cloudflare ne sait pas que l'appel curl de votre ordinateur portable est inoffensif. Il voit les mêmes modèles d'empreintes qu'il voit dans les outils de bourrage d'identifiants et les scrapers — et il les traite de la même manière.

Comment la protection anti-bots de Cloudflare voit le trafic des agents

La gestion des bots de Cloudflare repose sur des signaux superposés — chaînes User-Agent, empreintes TLS JA3/JA4, ordre des en-têtes, modèles comportementaux et réputation IP. Les défenses naïves que vous pourriez utiliser échouent de manière prévisible.

• Falsifier l'User-Agent n'est pas suffisant. Cloudflare met en corrélation la chaîne UA avec l'empreinte TLS. Une requête qui se déclare être Chrome mais utilise le profil TLS de curl est immédiatement signalée.
• Changer d'adresses IP n'aide pas les petites équipes. Les proxys résidentiels sont faciles à détecter, et un seul développeur martelant une IP voit sa réputation marquée en quelques heures.
• Même les bibliothèques légitimes sont évidentes. Python requêtes, Nœud chercher, Go's http.Client — chaque navire un handshake TLS reconnaissable.

Sur le plan Pro, cette application s'appelle Mode Super Combat de Robots. Il classe le trafic en Absolument automatisé, Probablement automatiséet Bots vérifiés, et vous permet de choisir une action pour chacune. Par défaut, “ Automatisé sans aucun doute ” reçoit un Défi géré — ce qui signifie que vos agents sont bloqués derrière un CAPTCHA qu'ils ne peuvent pas résoudre.

La cascade de défi mis en cache : pourquoi cela a affecté de vrais visiteurs

Voici la partie que la plupart des équipes manquent. Lorsque Cloudflare émet un défi géré, la page de défi utilise Google reCAPTCHA Enterprise en arrière-plan — mais n'utilise pas votre projet Google Cloud. Elle utilise la clé reCAPTCHA partagée de Cloudflare, qui est mutualisée entre tous ses clients.

Cette clé mutualisée dispose d'un quota de niveau gratuit. Lorsque le trafic des agents sur de nombreux sites s'accumule, le quota est épuisé et Google commence à refuser d'émettre des jetons. La page de défi s'affiche alors avec le message “Ce site dépasse le quota gratuit de reCAPTCHA Enterprise.”

Jusqu'à présent, juste une expérience de défi dégradée pour les bots. Les vrais dégâts viendront ensuite : sur le plan Pro, L'Optimisation Automatique de Plateforme (APO) de Cloudflare pour WordPress met en cache les réponses HTML en périphérie — y compris, dans certains cas limites, la page de défi elle-même qui est cassée. Un visiteur humain réel, accédant au même PoP de Cloudflare, se voit servir cette page cassée mise en cache. Soudain, votre page d'accueil est inutilisable, et le symptôme semble sans rapport avec quoi que ce soit que vous ayez fait.

C'est pourquoi l'hygiène des agents est importante, même si la protection contre le scraping ne vous intéresse pas. Par conséquent, les mesures que vous prenez pour que les agents d'IA derrière Cloudflare fonctionnent proprement ont un effet direct sur l'expérience de chaque visiteur réel de votre site marketing.

La solution : une règle WAF Skip et un en-tête secret

La solution propre est une information d'identification privée que les agents présentent à chaque requête, et une règle WAF Cloudflare qui la reconnaît et contourne la couche de gestion des bots. C'est le même schéma que Cloudflare recommande lui-même pour l'automatisation provenant de sources fiables.

Le mécanisme est simple :

1. Générez un long jeton secret aléatoire. Traitez-le comme une clé API : stockez-le dans un fichier .env ignoré par Git, ne le commitez jamais.
2. Faire en sorte que chaque script d'agent envoie ce jeton dans un en-tête personnalisé tel que X-Agent-Token.
3. Configurer une règle personnalisée WAF Cloudflare : si l'en-tête correspond à la valeur secrète, Passer toutes les fonctionnalités de sécurité (règles gérées WAF, mode Super Bot Fight, limitation du débit).

Comme la règle dépend d'un secret privé plutôt que d'une IP ou d'un User-Agent, elle survit aux changements de portable, à la rotation VPN et au télétravail. Et comme elle saute la sécurité plutôt que de la désactiver, les vrais visiteurs bénéficient toujours de la pleine enveloppe de protection.

Pour un traitement plus approfondi de la place de ceci dans le langage d'expression plus large de Cloudflare, le Documentation des règles personnalisées WAF Cloudflare est la référence canonique.

Implémenter la liste d'autorisation pour agents IA Cloudflare

Voici la recette concrète en cinq étapes, tirée de la manière dont nous expédions cela sur sengo.com.

1. Générez le secret. 32 octets aléatoires, c'est largement suffisant. Dans PowerShell: [System.BitConverter]::ToString([System.Security.Cryptography.RandomNumberGenerator]::GetBytes(32)).Replace('-','').ToLower(). Enregistrer la sortie sous JETON_AGENT dans votre .env.local (ignoré par git).
2. Ajoutez la règle WAF Cloudflare. Tableau de bord → votre site → Sécurité → WAF → Règles personnalisées → Créer. Expression : (http.request.headers["x-agent-token"][0] est égal à ""). Action : Passer. Cochez toutes les cases : Règles gérées WAF, règles de limitation de débit, mode Super Bot Fight, toutes les règles personnalisées restantes. Déployer.
3. Branchez l'en-tête dans vos scripts d'agent. Tout script qui accède au site doit envoyer l'en-tête. Pour shell : curl -H "X-Agent-Token: $AGENT_TOKEN" …. Pour Python : ajouter {"X-Agent-Token": os.environ.get("AGENT_TOKEN", "")} aux en-têtes de requête du dictionnaire. Pour un script Node utilisant chercher: inclure dans le en-têtes option.
4. Documentez la convention dans votre dépôt. Une courte note dans CLAUDE.md, README, ou l'invite système de votre agent, indiquant aux futurs scripts d'inclure l'en-tête. Sans elle, les nouvelles automatisations seront à nouveau confrontées silencieusement.
5. Optionnellement, ajoutez une liste d'autorisation de bots vérifiés pour les robots d'indexation IA légitimes. Si vous souhaitez que ClaudeBot, GPTBot, PerplexityBot et autres accèdent à votre contenu à des fins de citation, ajoutez une deuxième règle qui ignore lorsque cf.client.bot est vrai et que l'User-Agent correspond à l'un de ces noms. La cf.client.bot le champ est le signal de bot cryptographiquement vérifié de Cloudflare — il ne peut pas être usurpé.

Vérifier que la règle Cloudflare pour agents IA fonctionne

Nous avons constaté qu'un simple test en deux appels détecte toutes les erreurs de configuration. De n'importe quelle machine, avec un User-Agent similaire à celui d'un robot :

• Requête 1 — sans le jeton : curl -A "curl-test/1.0" https:///. Attendu : HTTP 403, titre de la réponse , et un en-tête de réponse cf-atténué : défi.
• Requête 2 — avec le jeton : curl -A "curl-test/1.0" -H "X-Agent-Token: $AGENT_TOKEN" https:///. Attendu : HTTP 200, corps de page complet, aucun cf-atténué en-tête.

Si les deux renvoient 200, votre mode bot est peut-être défini sur Autoriser quelque part — vérifiez le mode Super Bot Fight dans le tableau de bord Sécurité → Bots. Spécifiquement, si les deux renvoient 403, votre règle n’est pas encore déployée ou le nom de l’en-tête ne correspond pas.

Après 24 à 48 heures de trafic normal, le Sécurité → Événements Le journal montrera la règle qui s'active à chaque demande d'agent. Filtrez par le nom de votre règle et confirmez que l'automatisation réelle la fait correspondre. En bref, si vous voyez les appels de votre script dans le journal "Skip", vous avez terminé.

Leçons pour exploiter des agents IA en production

Cet incident nous a appris quelques éléments que nous appliquerions à toute équipe gérant des agents IA derrière Cloudflare ou toute couche d'edge comparable.

• Ne passez pas inaperçu — travaillez avec la couche de protection. La falsification de User-Agent et la rotation d'IP sont des contournements de courte durée. Une liste d'autorisation basée sur un identifiant privé est durable et auditable.
• Planifiez les effets de cascade de cache. La mise en cache périphérique (APO, LiteSpeed, CDN) peut transformer un incident bot ponctuel en une panne pour de vrais visiteurs. Tenez toujours compte du chemin entre le défi en amont et la livraison mise en cache en aval.
• Utilisez le signal verified-bot de Cloudflare pour les véritables robots d'exploration. La correspondance UA falsifiable donne un laissez-passer à n'importe qui. Le bot-vérifié champ cf.client.bot est ce que vous voulez lorsque vous autorisez ClaudeBot, GPTBot, Bingbot et les autres.
• Faites tourner le jeton d'agent comme n'importe quel autre secret. Une rotation trimestrielle est raisonnable. Mettez à jour la règle WAF et votre fichier .env de manière synchronisée.
• Informez vos agents de la convention. Qu'il s'agisse d'une note CLAUDE.md ou d'une norme de codage documentée, la règle doit survivre au développeur qui l'a mise en place.

Le patron plus large ici est que les agents IA derrière Cloudflare — ou toute couche périphérique en production — méritent un traitement opérationnel de première classe, pas des bricolages a posteriori. Traitez votre automatisation comme une partie de votre infrastructure, donnez-lui des identifiants et auditez son accès comme vous le feriez pour un membre humain de votre équipe.

Comment Sengo aide les équipes à exploiter les agents IA en toute sécurité

Nous avons été des deux côtés de ce problème — à la fois dans la création d'agents d'IA qui fonctionnent contre les sites web des clients et dans la protection des sites web des clients contre la mauvaise automatisation. Le schéma décrit dans cet article est directement issu d'un incident réel sur notre propre site, et c'est le même plan que nous déployons pour les clients intégrant Claude Code, des agents d'IA personnalisés ou des robots d'exploration de recherche d'IA tiers dans leur Protégé par Cloudflare infrastructure.

Si votre équipe commence à utiliser des agents IA contre votre propre site de production — ou si vous craignez que les robots d'exploration de recherche IA soient mis au défi et que votre contenu ne soit pas cité — c'est un problème que nous pouvons évaluer rapidement. Notre permettre aux équipes avec IA La solution couvre exactement ce type de renforcement opérationnel pour les sites déjà en production. Nous avons aidé des clients dans les secteurs des services financiers, de l'enseignement supérieur et du commerce de détail à mettre en place leur trafic d'agents et de robots explorateurs sans affaiblir leur posture de sécurité.