Web Bot Auth

Ce qu'est Web Bot Auth

Web Bot Auth est le nom d'un groupe de travail de l'IETF et de ses travaux sous forme d'Internet-Draft sur l'authentification du trafic web automatisé. L'idée est simple : les crawlers, les assistants IA et les agents autonomes signent leurs requêtes HTTP à l'aide de HTTP Message Signatures (RFC 9421), et publient les clés publiques qui vérifient ces signatures sous un identifiant qu'ils contrôlent. Un site web peut alors confirmer qu'une requête provenait bien de l'opérateur qu'elle mentionne, au lieu de s'appuyer sur une chaîne user-agent que n'importe qui peut copier. Pour comprendre ce que cela signifie pour une équipe produit, voir Web Bot Auth pour les équipes produit ; pour les étapes d'implémentation, voir le guide sur comment vérifier des requêtes signées d'agents IA.

En novembre 2026, le document central du groupe de travail est draft-ietf-webbotauth-httpsig-protocol, qui définit un en-tête Signature-Agent pour la découverte de clé en bande, un format de répertoire de clés basé sur JSON Web Key Sets et un URI bien connu où ce répertoire est exposé. La page des documents du groupe de travail le répertorie avec d'autres brouillons individuels associés. Il s'agit d'Internet-Drafts, ce qui signifie que ce sont des travaux en cours. Des détails tels que la manière dont les clés sont découvertes, les composants de requête qui doivent être signés et les en-têtes qui transportent les informations de l'opérateur peuvent changer d'une version à l'autre. Les implémenteurs doivent suivre les brouillons actuels plutôt qu'un instantané donné.

Pourquoi c'est important

Les sites web et les API identifient depuis longtemps les bots à l'aide de chaînes user-agent et de plages d'adresses IP. Les deux approches ont des limites : les chaînes user-agent se falsifient facilement (voir usurpation de user-agent), et les plages d'adresses IP changent et sont partagées entre plusieurs fournisseurs cloud. À mesure que les agents IA commencent à naviguer, à appeler des API et à utiliser des MCP servers au nom de personnes, les applications ont besoin d'un moyen plus robuste pour distinguer les clients automatisés coopératifs des clients anonymes.

Les requêtes signées fournissent cette base plus solide. Une signature vérifiée permet à une application de reconnaître de manière cohérente un opérateur connu, de lui offrir un chemin structuré plutôt qu'une interface de type humain, et de mesurer son activité avec précision.

Comment cela fonctionne à un niveau élevé

1. L'opérateur génère une paire de clés et publie la clé publique à un emplacement lié à son identité, généralement le chemin bien connu http-message-signatures-directory sous son domaine.
2. Chaque requête inclut les en-têtes Signature-Input et Signature couvrant certains composants de la requête, ainsi qu'un identifiant de clé, et un en-tête Signature-Agent pointant vers le répertoire de clés.
3. Le site récepteur récupère ou met en cache les clés publiées par l'opérateur, reconstruit la base de signature et vérifie la signature.
4. En cas de succès, le site sait que la requête a été produite par le détenteur de cette clé, associé à cet identifiant publié.

Ce que cela établit, et ce que cela n'établit pas

Une signature Web Bot Auth authentifie le client automatisé. Elle ne répond pas à la question suivante :

• savoir si l'opérateur est autorisé à faire ce qu'il demande (autorisation de l'agent),
• savoir si une personne a निर्देशé ou approuvé l'action (autorité déléguée),
• savoir si l'action est sûre ou si le contenu renvoyé sera utilisé de manière appropriée.

Ces points restent du ressort de l'authentification, de l'autorisation et des politiques propres à l'application qui reçoit la requête. Notre article de blog sur ce que prouvent les requêtes signées d'agents IA, et ce qu'elles ne prouvent pas explore cette limite.

Idées reçues fréquentes

• "Tous les bots signeront bientôt." L'adoption progresse client par client. Les applications verront longtemps un mélange de trafic signé, déclaré et anonyme, elles ont donc besoin d'un moyen clair de traiter chacun d'entre eux.
• "Une signature rend un bot bon." Elle rend un bot connu. Le caractère connu est le point de départ d'une politique, pas la politique elle-même.
• "Le brouillon est définitif." Il s'agit d'un Internet-Draft en évolution. Construisez à partir du texte actuel et attendez-vous à des révisions.

Le lien avec Proof of Actor

Proof of Actor considère une signature validée comme une preuve avec la base Verified, limitée à la clé et à l'identifiant qu'elle démontre. Le produit la distingue des noms déclarés et des signaux inférés, et ne transforme jamais l'identité en autorisation. Proof of Actor est conçu pour vérifier les requêtes signées à mesure que ces standards mûrissent ; vos propres politiques dans Route décident de ce qu'un agent vérifié peut faire.

Voyez comment cela s'intègre dans les API et les MCP servers, ou demandez un accès anticipé.

Sources

• groupe de travail IETF Web Bot Auth : charte, responsables et statut
• documents du groupe de travail Web Bot Auth : groupe de travail actuel et brouillons associés
• draft-ietf-webbotauth-httpsig-protocol : Signature-Agent, le répertoire de clés JWKS et son URI bien connu (travail en cours en novembre 2026)
• RFC 9421: HTTP Message Signatures : la norme de signature sur laquelle Web Bot Auth s'appuie