AUTOMATISATION VÉRIFIÉE

Reconnaître les demandes automatisées vérifiées

Lorsqu'un client automatisé signe ses demandes, votre application peut vérifier cette signature et traiter l'appelant en conséquence. Proof of Actor transforme ce contrôle en un résultat clair, exploitable pour le routage.

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

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

Tout le trafic automatisé n'est pas identique

Les clients automatisés atteignent votre application à chaque minute: robots d'exploration, outils de supervision, intégrations partenaires, assistants IA qui récupèrent des pages pour un utilisateur, et agents autonomes qui exécutent des tâches. Pendant des années, la plupart des applications n'ont pu les distinguer qu'au moyen de l'en-tête user-agent, une chaîne que n'importe quel client peut définir comme il veut.

Cela place les équipes applicatives dans une situation délicate. Traitez toute automatisation avec méfiance et vous dégradez l'expérience des agents légitimes dont vos clients dépendent. Faites confiance à l'en-tête et vous laissez n'importe qui se prétendre un robot d'exploration connu.

Les demandes automatisées vérifiées changent la donne. Lorsqu'un client automatisé signe ses demandes avec une clé qu'il a publiée, votre application peut vérifier la signature et savoir, cryptographiquement, quel client a signé la demande. Proof of Actor intègre ce contrôle dans un résultat d'acteur unique et cohérent sur lequel votre code peut s'appuyer pour le routage. Pour comprendre plus précisément ce que ce contrôle établit, et ce qu'il n'établit pas, lisez ce que prouvent les demandes d'agent IA signées.

Comment fonctionne la signature des requêtes

L'approche émergente pour le trafic automatisé utilise les HTTP message signatures, normalisées dans RFC 9421, qui définissent comment créer, encoder et vérifier des signatures sur des composants d'un message HTTP. Le client signe certaines parties de chaque demande avec une clé privée et inclut la signature ainsi que ses paramètres dans les en-têtes. Il publie la clé publique correspondante à un emplacement lié à un identifiant qu'il contrôle, généralement son domaine.

Lorsque la demande arrive, le destinataire récupère ou recherche la clé publiée, reconstruit le contenu signé et vérifie la signature. Si elle est valide, la demande a été signée par le détenteur de cette clé. Les travaux sur la signature du trafic automatisé se poursuivent au sein du groupe de travail IETF Web Bot Auth, dont le mandat couvre l'authentification cryptographique de clients automatisés tels que des robots d'exploration et des agents IA agissant pour des utilisateurs finaux; l'entrée du glossaire Web Bot Auth en fait la synthèse. L'article de blog sur ce que prouvent les demandes d'agent IA signées déroule un cas vérifié de bout en bout, et le cas d'usage APIs montre où la vérification apporte le plus de valeur en premier.

Le guide sur la vérification des demandes d'agent signées décrit le mécanisme en détail, y compris les horodatages, les fenêtres de rejeu et la mise en cache des clés.

Ce qu'une signature vérifiée prouve, et ce qu'elle ne prouve pas

Cette distinction est la partie la plus importante pour bien gérer les demandes automatisées vérifiées.

Une signature valide prouve que la demande a été signée avec une clé associée à l'identifiant publié. Si la clé appartient au domaine d'un opérateur, la demande provient d'un client qui détient la clé de cet opérateur.

Une signature valide ne prouve pas:

qui a demandé à l'agent d'agir, ou si une personne a demandé cette action;
qu'une personne a délégué une autorité à l'agent;
l'identité juridique réelle derrière l'opérateur;
que l'action demandée est sûre ou autorisée dans votre application.

Ce sont des questions distinctes. Votre application y répond avec ses propres identifiants, son modèle d'autorisation et sa politique. Proof of Actor les maintient volontairement séparées, et la page Détection et limites précise exactement ce que chaque type de preuve peut établir.

Comment Proof of Actor gère les demandes automatisées vérifiées

Détecter

Votre intégration transmet à Proof of Actor le contexte de la demande, y compris les en-têtes de signature éventuels. Les signatures sont vérifiées par rapport aux clés publiées. Les demandes validées sont consignées avec une base vérifiée. Les clients qui ne se nomment que eux-mêmes sont consignés comme déclarés. Les schémas comportementaux sont consignés comme inférés. Lorsqu'il n'y a pas assez d'éléments, le résultat est Unknown. Rien n'est promu au statut vérifié sans qu'un contrôle cryptographique ait réussi.

Comprendre

Voyez quels opérateurs vérifiés appellent votre application, quelles routes ils utilisent, à quelle fréquence, et comment cela se compare à l'automatisation déclarée et inconnue. Le résumé des preuves sur chaque résultat indique quelle clé et quel identifiant étaient impliqués, afin que votre équipe puisse enquêter rapidement sur n'importe quelle demande.

Router

Utilisez la base dans vos politiques. Les schémas courants incluent:

Donner aux agents vérifiés une réponse structurée sur les routes en lecture seule, comme une API ou une version Markdown d'une page.
Augmenter les limites de débit pour les opérateurs vérifiés que vous reconnaissez, tout en conservant des limites standard pour les clients déclarés.
Conserver votre autorisation existante sur chaque route d'écriture, quelle que soit la signature.
Définir un repli explicite pour les appelants non signés et Unknown sur chaque route.

Vos politiques décident; Proof of Actor fournit les preuves.

Pourquoi l'en-tête user-agent ne suffit pas

Les chaînes user-agent sont des déclarations. N'importe quel client peut envoyer n'importe quelle valeur, et le spoofing de user-agent ne demande aucune compétence. C'est pourquoi les opérateurs de robots d'exploration publient leurs propres contrôles: Google documente les recherches DNS inverses et directes ainsi que les plages d'IP publiées pour vérifier Googlebot, Bing documente un contrôle DNS pour vérifier Bingbot, et OpenAI publie des fichiers de plages d'IP pour chacun de ses crawlers et user agents. Proof of Actor traite une déclaration user-agent comme une preuve déclarée, jamais comme une vérification. Cela signifie qu'un client qui prétend être un robot d'exploration connu sans signature valide est signalé avec une base déclarée ou inférée, et votre politique peut le traiter différemment d'un client qui a prouvé son identité.

C'est ce qui rend les demandes automatisées vérifiées utiles: elles vous donnent un moyen fiable d'étendre votre confiance aux clients qui la méritent, sans l'étendre à tous ceux qui copient leur en-tête.

Preuves d'identité, identifiants et autorisation

Trois niveaux fonctionnent ensemble dans toute application qui sert des clients automatisés:

Preuve d'identité: quel client a signé cette demande? Une signature vérifiée répond à cette question.
Identifiants: quel compte est responsable? Votre clé API, votre token ou votre session répond à cette question.
Autorisation: cet appelant peut-il faire cela? Votre modèle de permissions répond à cette question.

Proof of Actor renforce le premier niveau et le rend visible. Il n'émet pas d'identifiants d'identité ou de délégation, et il ne remplace pas votre autorisation. Conserver ces niveaux séparés vous permet d'être généreux avec les agents vérifiés sur les routes à faible risque et prudent sur celles à fort impact.

Où cela s'intègre

Proof of Actor s'insère aux côtés de votre passerelle, de votre authentification et de votre limitation de débit. Les intégrations s'exécutent comme middleware côté serveur, en périphérie, dans votre MCP server ou via une intégration HTTP générique, avec un accompagnement concret pour chaque équipe fondatrice. Si votre trafic est principalement constitué d'APIs et d'outils, les cas d'usage APIs et MCP Servers montrent les schémas les plus importants.

Commencer en mode observation

Chaque intégration démarre en mode observation. Les résultats sont enregistrés sans modifier la manière dont votre application répond, afin que vous puissiez voir quelle part de votre trafic automatisé est vérifiée, quels opérateurs signent, et où le taux Unknown est le plus élevé. Les politiques viennent plus tard, route par route, lorsque les preuves les justifient. Comment ça marche décrit le flux complet.

Détails pratiques qui rendent la vérification fiable

La vérification des signatures n'est aussi bonne que les détails qui l'entourent. Quelques pratiques rendent les demandes automatisées vérifiées fiables en production.

Vérifier la fraîcheur

RFC 9421 définit les paramètres de signature created et expires, et les demandes signées les transportent généralement. Rejetez les signatures en dehors d'une fenêtre courte, afin qu'une demande capturée ne puisse pas être rejouée plus tard.

Mettre les clés en cache de manière raisonnable

Récupérer les clés publiées par un opérateur à chaque demande ajoute de la latence. Mettez-les en cache pendant une durée raisonnable et actualisez-les lorsqu'une signature échoue avec un identifiant de clé inconnu, afin qu'une rotation de clés n'entraîne pas de faux échecs.

Signer les bonnes parties de la demande

Une signature qui ne couvre qu'un horodatage prouve très peu. Vérifiez que les composants signés incluent la méthode, le chemin et l'hôte, afin que la signature soit liée à la demande réellement reçue par votre application.

Enregistrer les preuves

Conservez l'identifiant de clé, l'identifiant publié et le résultat pour chaque demande vérifiée. Lorsqu'un événement inhabituel se produit, votre équipe peut voir exactement quel client a signé quoi, et quand.

Proof of Actor prend en charge ces vérifications dans l'étape Detect et renvoie le résultat sous la forme d'une base que vos politiques peuvent lire, afin que le code de votre application reste simple.

Rejoindre le programme développeur fondateur

Proof of Actor est en bêta privée. Les équipes fondatrices sélectionnées peuvent recevoir jusqu'à 12 mois d'accès gratuit, dans les limites d'utilisation convenues, avec une assistance d'intégration directe de nos ingénieurs.

Si des clients automatisés atteignent votre application et que vous souhaitez traiter différemment ceux qui sont vérifiés, demandez un accès anticipé. Parlez-nous de votre application et des appelants automatisés que vous observez, et nous vous montrerons comment Proof of Actor s'intègre.

Sources

RFC 9421: HTTP Message Signatures, IETF, February 2024.
Web Bot Auth (webbotauth) working group charter, IETF.
Verifying Googlebot and other Google crawlers, Google Search Central.
How to verify that Bingbot is Bingbot, Bing Webmaster Blog.
Overview of OpenAI crawlers, OpenAI.

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 qu'une demande automatisée vérifiée ?

C'est une demande provenant d'un client automatisé dont la signature cryptographique est validée par rapport à une clé publiée pour un identifiant connu, comme le domaine de l'opérateur. Elle montre quel client a signé la demande.

Une signature vérifiée signifie-t-elle que l'agent est autorisé ?

Non. Une signature associe une demande à une clé et à son identifiant publié. Le fait que ce client puisse effectuer une action est une décision d'autorisation distincte, prise par votre application.

Que faire des clients automatisés qui ne signent pas leurs demandes ?

Proof of Actor les classe quand même, en utilisant des éléments de preuve déclarés et inférés lorsque c'est possible, et renvoie Unknown lorsque les preuves ne sont pas suffisamment solides. Chaque résultat indique sa base.

Une chaîne user-agent peut-elle vérifier un client ?

Non. Les chaînes user-agent sont faciles à imiter, elles comptent donc comme une déclaration, pas comme une vérification. Ce sont les signatures cryptographiques qui rendent une demande vérifiable.

Comment commencer ?

Demandez un accès anticipé. Les équipes fondatrices démarrent en mode observation et les équipes sélectionnées peuvent recevoir jusqu'à 12 mois gratuits dans les limites d'utilisation convenues.

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