EXPLICATION

Web Bot Auth pour les équipes produit: ce que signifient les requêtes signées des agents pour votre feuille de route

Les agents IA et les crawlers ont de plus en plus besoin d'un moyen de prouver qui ils sont sans dépendre d'une chaîne User-Agent que n'importe qui peut copier. Le travail de l'IETF sur Web Bot Auth est l'effort principal pour standardiser cela. Voici une explication claire pour les product managers et les responsables engineering: comment cela fonctionne, ce que cela prouve, où cela en est en novembre 2026 et comment vous y préparer.

Obtenir un accès anticipé Découvrir le fonctionnement

Par Toshendra SharmaFondateur et CEO, AgentCredia · Updated November 13, 2026

Pendant des années, la seule façon pour un client automatisé d'indiquer à un site web qui il était reposait sur un nom dans l'en-tête User-Agent et, pour quelques grands opérateurs, sur une liste d'adresses IP publiée ou sur une vérification reverse DNS. Les noms sont faciles à copier. Les listes réseau ne couvrent que les opérateurs qui les maintiennent. À mesure que les agents IA commencent à agir pour de vraies personnes sur le web, cet écart est devenu un problème produit, pas seulement un problème de sécurité.

Web Bot Auth est l'effort principal pour le combler. Il donne aux clients automatisés un moyen de signer leurs requêtes avec une clé qu'ils contrôlent et publient, afin qu'un site puisse vérifier la signature au lieu de faire confiance à un nom. Cette explication s'adresse aux product managers et aux responsables engineering qui doivent comprendre ce que c'est, ce que cela change et ce que cela ne change pas, sans lire les spécifications de bout en bout.

La version courte

Ce que c'est: un working group de l'IETF, webbotauth, et l'approche qu'il standardise pour authentifier des clients HTTP automatisés.
Comment cela fonctionne: le client signe des parties de chaque requête à l'aide de HTTP Message Signatures (RFC 9421) et pointe vers un répertoire de ses clés publiques. Le site récupère la clé et vérifie la signature.
Ce que cela prouve: quelle clé a signé la requête, et que les parties signées n'ont pas été modifiées en transit.
Ce que cela ne prouve pas: que l'agent est autorisé à faire ce qu'il demande, qu'il agit pour un utilisateur donné, ou qu'il se comportera correctement.
État en novembre 2026: RFC 9421 est un Proposed Standard publié. Le document de protocole Web Bot Auth est un Internet-Draft de working group, pas encore un RFC.
Ce qu'il faut faire: prévoyez de traiter les signatures valides comme une preuve forte, continuez à gérer le trafic non signé et conservez les décisions d'autorisation dans votre propre code.

Ce que sont les travaux de l'IETF sur Web Bot Auth

L'IETF a charteré le working group Web Bot Auth pour standardiser des méthodes d'authentification cryptographique des clients automatisés et pour donner aux sites web davantage d'informations sur les opérateurs qui se cachent derrière eux. Le charter se concentre sur les sites qui s'adressent principalement à des personnes, et il inclut un large ensemble de clients: crawlers, web archivers, link checkers, crawlers d'entraînement IA et agents IA agissant pour des utilisateurs finaux.

Deux exclusions du charter méritent d'être signalées pour les équipes produit. L'authentification des utilisateurs finaux est hors périmètre, donc ce n'est pas un moyen de connecter une personne. Le suivi de la réputation des bots est également hors périmètre, donc le standard vous dit qui a signé une requête, pas si cet opérateur est digne de confiance.

Le charter énumère trois types de livrables:

Des documents de standards track sur les techniques d'authentification des clients automatisés auprès de sites web conçus pour des personnes.
Des documents de standards track sur la transmission de davantage d'informations sur un bot demandeur à l'aide d'un identifiant existant tel qu'un nom de domaine ou une URL.
Des documents de best current practice ou informatifs sur des sujets opérationnels tels que la gestion des clés, le cycle de vie et le déploiement.

Où en sont les documents, en novembre 2026

En novembre 2026, le working group a un document adopté: draft-ietf-webbotauth-httpsig-protocol, intitulé "HTTP Message Signatures for automated traffic", à la révision 01, daté du 29 octobre 2026. C'est un Internet-Draft, ce qui signifie qu'il s'agit d'un travail en cours qui peut encore changer. Ce n'est pas un RFC.

Plusieurs drafts individuels sont également associés au groupe et en discussion, notamment des propositions sur un registre et un format de carte d'agent, sur l'authentification anonyme des bots, sur un format JSON pour publier les plages IP des clients automatisés, et sur un en-tête pour les métadonnées signées de l'agent. Les drafts individuels sont des propositions; aucun n'a été adopté par le groupe à cette date.

Le charter a fixé des jalons en 2026 pour l'envoi des spécifications à l'IESG pour approbation. En novembre 2026, le document de protocole reste un draft de working group. Vous pouvez suivre l'état actuel sur la page datatracker de l'IETF pour le working group et sur le draft de protocole.

Comment fonctionnent HTTP Message Signatures

Web Bot Auth s'appuie sur RFC 9421, HTTP Message Signatures, publié en février 2024 comme Proposed Standard. RFC 9421 est un mécanisme général: il définit comment signer certaines parties d'un message HTTP et comment transporter la signature dans des en-têtes. Web Bot Auth l'adapte aux clients automatisés.

En termes simples, une requête d'agent signée fonctionne ainsi:

L'opérateur crée une paire de clés. Il conserve la clé privée secrète et publie la clé publique.
Le client choisit quoi signer. Il sélectionne des composants de la requête, tels que l'hôte cible ou l'URI et un horodatage de création. Le draft actuel exige de couvrir l'autorité ou l'URI cible, afin qu'une signature pour un site ne puisse pas simplement être rejouée contre un autre.
Le client signe et envoie. La requête contient un en-tête Signature-Input décrivant ce qui a été signé et avec quelle clé, ainsi qu'un en-tête Signature avec la valeur de signature. Le draft utilise une étiquette web-bot-auth et attend des horodatages de création et d'expiration pour chaque signature.
Le site vérifie. Il trouve la clé publique, reconstruit les composants signés à partir de la requête reçue et vérifie la signature. Si la vérification réussit, la requête a été signée par le détenteur de cette clé et les parties couvertes n'ont pas été modifiées.

Le draft permet aussi à un site de demander une signature. Une origine peut envoyer un en-tête Accept-Signature, généralement avec un refus, pour signaler qu'elle veut des requêtes signées.

L'idée du répertoire de clés

Une signature n'est utile que si le site peut trouver la bonne clé publique. Web Bot Auth répond à cela avec un répertoire de clés.

Dans le draft actuel du working group, le client ajoute un en-tête Signature-Agent contenant une URL HTTPS. Cette URL sert un répertoire des clés publiques de l'opérateur sous forme de JSON Web Key Set. Le site récupère le répertoire, sélectionne la clé qui correspond à l'identifiant de clé dans la signature et vérifie. Le draft définit aussi un chemin bien connu, /.well-known/http-message-signatures-directory, où un opérateur peut publier son répertoire.

L'idée utile pour les équipes produit est que l'URL devient l'identité. Un opérateur d'agent est identifié par l'endroit où il publie ses clés, ce qui lie la signature à un domaine que l'opérateur contrôle. La rotation des clés fonctionne en publiant une nouvelle clé à côté de l'ancienne, puis en supprimant l'ancienne.

Les sites qui vérifient doivent gérer les répertoires avec soin: les mettre en cache selon les règles HTTP normales, définir des limites de taille et des délais d'attente, et éviter de récupérer des données à partir d'adresses réseau privées. Ce sont des préoccupations d'ingénierie standard, et elles expliquent en partie pourquoi de nombreuses équipes préfèrent un composant qui fait la vérification à leur place.

Ce qu'une signature valide prouve, et ce qu'elle ne prouve pas

C'est la section la plus importante pour toute personne qui rédige une politique produit.

Une signature valide prouve:

La requête a été signée par le détenteur d'une clé privée spécifique.
Cette clé est publiée à une URL de répertoire contrôlée par l'opérateur.
Les parties signées de la requête n'ont pas été modifiées en transit, et la signature se trouve dans sa fenêtre de validité.

Une signature valide ne prouve pas:

Que l'agent est autorisé à effectuer l'action. Être identifiable n'est pas un droit. Voir agent authorization.
Que l'agent agit pour une personne donnée, ou dans le cadre de l'autorité que cette personne lui a accordée. Voir delegated authority.
Que l'opérateur est digne de confiance ou que l'agent se comportera bien. La réputation est explicitement hors périmètre du working group.
Quoi que ce soit concernant des requêtes qui ne sont pas signées. Le trafic non signé doit toujours être géré séparément.

Traitez une signature valide comme une preuve forte de qui a envoyé une requête, puis laissez votre propre contrôle d'accès décider ce que cet expéditeur peut faire.

Ce que les équipes produit doivent faire à ce sujet

Vous n'avez pas besoin d'attendre un RFC pour planifier. Le trafic d'agents signé est quelque chose auquel vous pouvez vous préparer dès maintenant, en sachant que certains détails du draft peuvent changer.

1. Mesurez avant de décider

Déterminez quelle part de votre trafic est automatisée, quelles routes sont utilisées par les agents et quelle part est signée. Commencez en mode observation afin que la mesure ne change rien pour vos utilisateurs.

2. Séparez les preuves de la politique

Enregistrez ce que disent les preuves, verified, declared, inferred ou unknown, séparément de ce que vous décidez de faire. Cela rend les politiques lisibles et vous permet de les durcir ou de les assouplir sans réinstrumenter. L'entrée evidence basis explique les quatre niveaux.

3. Donnez un meilleur chemin aux agents verified

Lorsque cela a du sens, servez aux agents verified du contenu structuré ou un flux adapté aux agents plutôt que des pages conçues pour des personnes. Le guide sur serving AI agents structured content couvre les modèles à utiliser.

4. Gardez l'autorisation dans votre code

Utilisez la signature pour savoir qui demande. Utilisez vos permissions, périmètres et confirmations existants pour décider ce qu'il peut faire. Les actions à fort impact peuvent toujours nécessiter une confirmation humaine, quel que soit le signataire. Voir protecting sensitive actions without blocking agents.

5. Préparez-vous au trafic unsigned et Unknown

La prise en charge de la signature varie selon les agents et les outils, donc attendez-vous pendant un certain temps à un mélange de requêtes signées et non signées. Décidez par route ce qui arrive au trafic declared, inferred et Unknown, plutôt que de choisir une seule règle pour tout le site. Le guide sur handling Unknown traffic détaille ce point.

Comment Proof of Actor utilise Web Bot Auth

Proof of Actor indique à votre application qui ou quoi agit à chaque interaction, Human, Human + AI, Agent ou Unknown, et précise la base de preuve. Les signatures Web Bot Auth font partie de ses sources de preuve les plus solides.

Lorsqu'un agent signe sa requête avec HTTP Message Signatures, Proof of Actor vérifie la signature par rapport à la clé publiée par l'opérateur. Si la vérification réussit, le résultat porte une base verified, ainsi que les preuves que votre équipe peut examiner. Si un client ne fait que se nommer dans un en-tête, le résultat est declared. Si la conclusion repose sur des signaux comportementaux ou contextuels, elle est étiquetée inferred. Si les preuves ne suffisent pas, le résultat est Unknown.

Votre application décide quoi faire de ce contexte. Les politiques sont rédigées par route, par classe d'acteur et par base, avec des issues telles que allow, adapt, challenge, review et rate-limit. Rien n'est appliqué par défaut: vous prévisualisez une politique sur du trafic réel puis vous l'enforcez route par route, dans votre propre code.

Les équipes fondatrices peuvent collecter des preuves via un middleware Node.js, Next.js, une intégration edge, un collecteur navigateur sur les pages approuvées, l'API HTTP générique ou une intégration MCP server. Voir integrations, et le guide sur verifying signed agent requests pour les étapes pratiques.

Proof of Actor suit la même limite que le standard: une signature verified vous indique quelle clé a signé la requête, pas si l'agent est autorisé. L'autorisation reste de votre côté. La page evidence and limits précise exactement ce que chaque résultat peut et ne peut pas prendre en charge.

Commencer

Proof of Actor est en private beta. Les équipes fondatrices sélectionnées peuvent recevoir jusqu'à 12 months d'accès gratuit dans les limites d'utilisation convenues, sans facturation automatique. Demandez un accès anticipé et indiquez-nous quelles routes vous attendez que des agents signés utilisent et ce que vous voulez en faire.

POUR LES DÉVELOPPEURS

What your code receives

Every interaction resolves to one result record. Your application reads the class and the basis and applies its own policy.

Result record

{
  "route": "GET /api/v1/catalog",
  "class": "agent",
  "basis": "verified",
  "evidence": [
    { "signal": "http_message_signature", "result": "valid", "keyid": "assistant.example" },
    { "signal": "client_declaration", "value": "assistant.example" }
  ],
  "observed_at": "2026-11-13T10:42:07Z"
}

class: Human, Human + AI, Agent ou Unknown.
basis: Niveau de solidité des preuves : Verified, Declared, Inferred ou Unknown.
evidence: Les signaux derrière le résultat, pour que votre équipe puisse voir pourquoi.

Commencez en mode observation : enregistrez les résultats à côté de vos logs et ne changez rien tant que vous n'avez pas choisi une politique. Lire le guide d'intégration Node.js

Questions fréquentes

Qu'est-ce que Web Bot Auth ?

Web Bot Auth est le nom d'un working group de l'IETF, webbotauth, et de l'approche qu'il standardise: des clients automatisés signent des requêtes HTTP avec HTTP Message Signatures (RFC 9421) et publient leurs clés publiques, afin que les sites puissent vérifier quel opérateur a envoyé une requête.

Web Bot Auth est-il un standard finalisé ?

Pas encore. En novembre 2026, le principal document de protocole, draft-ietf-webbotauth-httpsig-protocol, est un Internet-Draft de working group à la révision 01. RFC 9421, le format de signature sur lequel il s'appuie, est un Proposed Standard publié.

Une signature Web Bot Auth valide signifie-t-elle que l'agent est autorisé à agir ?

Non. Elle prouve quelle clé a signé la requête et que les parties signées n'ont pas été modifiées. Le fait que cet agent puisse lire des données, soumettre un formulaire ou agir pour un utilisateur donné reste une décision d'autorisation que votre application prend elle-même.

Les équipes produit doivent-elles implémenter Web Bot Auth elles-mêmes ?

Les sites vérifient les signatures, ils n'ont pas besoin d'en signer sauf s'ils exploitent aussi des clients automatisés. La vérification consiste à récupérer des répertoires de clés, à les mettre en cache de façon sûre et à contrôler les signatures, ce qu'un outil comme Proof of Actor peut faire pour vous.

Que devons-nous faire avec les agents qui ne signent pas leurs requêtes ?

Traitez-les selon les preuves disponibles: declared, inferred ou Unknown. Attendez-vous pendant un certain temps à un mélange de trafic signé et non signé, et définissez un comportement de repli par route plutôt qu'une règle unique pour tout le site.

Comment Proof of Actor utilise-t-il Web Bot Auth ?

Il vérifie les HTTP Message Signatures par rapport à la clé publiée et, lorsque la vérification réussit, présente le résultat avec une base verified. Vos politiques peuvent ensuite traiter différemment les agents verified par rapport au trafic declared ou Unknown.

Savoir qui utilise votre app.

Private beta pour un petit groupe de développeurs fondateurs.

Obtenir un accès anticipé Voir les prix

Vous préférez en parler d'abord ? Parler aux fondateurs