Cloudflare publie un texte de position sur les agents et les sites et annonce la coalition TAD : quatorze difficultés côté site et un plan fondé sur Web Bot Auth et MOLE, mais les normes sont surtout des brouillons, le livre blanc n’est pas sorti et les contrôles livrés ne couvrent que le trafic Cloudflare

Le 5 novembre 2026, Cloudflare a publié « Agents aren't humans (but they kinda are) », un long texte de position de Bryan Becker, et annoncé la coalition Trusted Agent Delegation (TAD). Il fait suite à l’article produit du 4 novembre sur la visibilité et le contrôle des agents personnels, que ce numéro ne reprend pas ; la nouveauté est l’argumentaire et le plan de normalisation. Le texte est un plaidoyer d’un fournisseur qui vend des contrôles contre les robots et d’accès, de sorte que les affirmations sur les coûts et les besoins relèvent du cadrage propre à Cloudflare.

Le point de départ est qu’un agent d’IA personnel est un intermédiaire. Il agit pour un utilisateur, est en général exploité par un opérateur comme service géré et atteint un site depuis l’infrastructure de cet opérateur. Le site voit l’agent et non l’utilisateur, et un même agent peut porter de nombreux utilisateurs. Cloudflare dit que, pour gérer cette relation, un site a normalement besoin de trois choses : identité, réputation et responsabilité. Son principe organisateur, qu’il appelle principe d’intermédiation, est que la relation commerciale entre utilisateurs et sites, ainsi que les responsabilités de sécurité de chacun, doivent être maintenues quoi qu’il y ait entre les deux. Le texte cite deux exemples d’opérateurs, Muse de Meta et dots d’OpenAI, et dit que le trafic des agents pourrait éclipser la navigation humaine ordinaire dans un avenir proche, ce qui rendrait inopérante l’ancienne réponse consistant à bloquer les intermédiaires.

Pour rendre le problème concret, le texte raconte l’histoire d’une assistante personnelle, Ezra, qui s’occupe des courses et démarches de quatre clients, puis présente un tableau de quatorze difficultés côté site. On y trouve le partage de compte, la fraude amicale, l’usurpation d’identité, le mélange de trafic (quand un client abuse d’un agent partagé, le site ne peut bloquer que l’agent, donc tous ses utilisateurs), l’épuisement de ressources, la consommation de contenu sans contrepartie, et le fait que les CAPTCHA et l’authentification fondée sur le risque ne fonctionnent plus comme prévu. Cloudflare conclut que, presque toujours, le site supporte l’essentiel du coût. C’est une affirmation appuyée sur un raisonnement et des exemples, pas sur des mesures, et le texte ne chiffre aucune des quatorze difficultés.

Cloudflare explique aussi pourquoi deux propositions courantes sont insuffisantes. Transmettre un CAPTCHA à l’utilisateur prouve seulement qu’un humain quelconque est présent à cet instant, ne dit pas pour qui l’agent agit le reste du temps et remet la friction que les agents servent à supprimer. Les accès à portée étroite sont rarement utilisés en pratique, car les agents demandent la permission de tout faire, et même une portée étroite dit ce que l’agent peut faire, pas qui répond en cas d’erreur.

La direction proposée est un ensemble de normes existantes et émergentes. Pour l’identité, Cloudflare préfère Web Bot Auth, où un agent signe ses requêtes ; sa documentation indique qu’il repose sur des brouillons de l’IETF, utilise des clés Ed25519 et attend un répertoire de clés à un chemin bien connu fixe. Le texte note un cas non résolu, celui d’un agent qui en utilise un autre dans un navigateur, où le site doit voir toute la chaîne. La documentation ajoute que Cloudflare expérimente l’en-tête Forwarded pour transporter l’identité d’un opérateur le long d’une telle chaîne, et précise que c’est expérimental et susceptible de changer. Pour la limitation de débit sans identifiants d’utilisateur, il cite MOLE, qu’il présente comme le successeur prévu de Private Access Tokens, et pour les paiements x402. Il décrit quatre niveaux d’information d’identification, de rien du tout, en passant par la session et le compte, jusqu’à un identifiant unique fourni par un tiers, et dit que les sites ne devraient demander que le nécessaire. Il souhaite aussi un moyen de transmettre des attestations comme avoir plus de 18 ans ou être titulaire de la carte, et un moyen lisible par machine pour que les sites publient ce que les agents peuvent faire, en notant que le groupe de travail AI Preferences de l’IETF traite des préférences d’usage comme l’entraînement et la recherche mais, selon Cloudflare, pas le besoin plus large.

L’annonce proprement dite est la coalition TAD. Son objectif déclaré est de réunir des représentants de l’écosystème pour discuter de l’ensemble des problèmes, examiner les protocoles existants et porter des problèmes bien définis devant l’IETF, avec des réunions parallèles lors des réunions de l’IETF et des ateliers. Le site de la coalition annonce un livre blanc prochainement et montre un cas d’usage visé : un client qui revient change d’agent, tandis que le site conserve sa relation avec lui et limite les informations personnelles partagées. Le texte dit que les agents locaux et libres exécutés sur l’appareil de l’utilisateur ne sont pas le premier centre d’intérêt.

Le texte se termine par ce que les clients de Cloudflare peuvent faire dès maintenant, ce qui reprend les fonctions du 4 novembre : Security Analytics compte les assistants personnels comme une catégorie de trafic distincte, des politiques d’accès par agent permettent d’autoriser un agent, de le bloquer seulement sur les pages avec publicité ou de le bloquer entièrement, et Account Abuse Protection, en accès anticipé, indique si une connexion ou une inscription vient d’un agent personnel et lequel, de sorte qu’un compte donné peut être traité par une règle WAF sur son identifiant d’utilisateur haché. Le texte nomme aussi Business Insights, un outil de rapport pour les clients Enterprise Bot Management, pour une vue plus large du trafic des robots d’IA.

Notre lecture : l’utile est le vocabulaire et la liste des cas d’échec, qui permettent à un propriétaire de site de vérifier lesquels des quatorze le concernent. Les normes sont pour la plupart des brouillons, MOLE est décrit comme prévu, le livre blanc n’est pas encore publié et les contrôles livrés ne couvrent que le trafic passant par Cloudflare. Il faut voir la coalition comme une intention déclarée, pas comme une norme adoptée.