Web Bot Auth & Know Your Agent : pourquoi l’identité n’est pas suffisante
Le trafic généré par les agents IA augmente rapidement, et il n’est pas toujours bienvenu. Certains agents sont légitimes. D’autres extraient, sondent les sites ou automatisent les pratiques abusives.
80% des agents IA ne déclarent pas correctement leur identité lorsqu’ils visitent des sites web, et même ceux qui le font ne sont pas nécessairement sûrs ou bénéfiques pour votre modèle économique spécifique.
Même les agents construits à l’aide de plateformes IA bien connues comme OpenAI, Perplexity et Meta ont été utilisés pour mener des attaques, y compris des injections SQL, des attaques de scripts intersites et la création de faux comptes. Un fournisseur reconnaissable ou l’identité vérifiée d’un agent peut établir sa provenance, mais cela ne peut garantir un comportement inoffensif.
Web Bot Auth et Know Your Agent sont deux frameworks émergents conçus pour responsabiliser le trafic des agents : l’un au niveau cryptographique, l’autre au niveau de la gouvernance. Les deux constituent des avancées significatives.
Vérifier l’identité d’un agent ou la source d’une requête signée ne vous dit pas ce qu’il fait à l’instant présent, qui dirige ses actions, ou si son comportement est digne de confiance.
L’authentification peut établir qu’un agent ou un identifiant est légitime à un moment donné. Elle n’évalue pas le comportement en continu, ne détecte pas les activités anormales, ni n’empêche un agent vérifié d’agir de manière malveillante ou en dehors de son champ d’action prévu. Pour cela, vous avez besoin d’une troisième couche : la détection continue des bots et agents basée sur l’intention.
Voici une comparaison des deux normes leurs limites respectives, et ce à quoi ressemble réellement une protection complète des agents.
Qu’est-ce que Web Bot Auth?
Web Bot Auth (WBA) est un protocole cryptographique IETF émergent qui permet aux agents IA de prouver quelle plateforme a émis une requête. Considérez-le comme un passeport numérique tamponné par le fournisseur de l’agent.
Le mécanisme fonctionne via des signatures cryptographiques Ed25519 sur les requêtes HTTP, vérifiées par rapport aux répertoires de clés publiques hébergés sur /.well-known/http-message-signature-directory sur leur propre domaine.
Lorsqu’un agent fait une requête, il la signe avec une clé privée. Le site récepteur ou la couche de sécurité (un WAF, par exemple) vérifie cette signature par rapport au répertoire de clés publiques de l’opérateur. Si la signature est valide, la requête est confirmée comme provenant d’une plateforme IA spécifique, telle qu’OpenAI ou AWS Bedrock.
Ce que WBA établit :
- quelle plateforme a envoyé la requête,
- que la requête a été signée cryptographiquement.
Ce que WBA n’établit pas :
- à qui appartient l’agent,
- ce que l’agent est autorisé à faire,
- si le comportement de l’agent est sûr.
Comment fonctionne Web Bot Auth dans la pratique?
Le processus est simple une fois que vous comprenez les composants:
- Génération de clé : l’opérateur de l’agent génère une paire de clés de signature (publique + privée)
- Hébergement de répertoire : la clé publique est hébergée dans un répertoire de clés sur le domaine de l’opérateur
- Configuration de la vérification : le propriétaire du site configure son service de sécurité ou de périphérie pour valider les signatures et appliquer des politiques basées sur le statut de vérification
- Signature de requête : chaque requête que l’agent fait est signée avec sa clé privée
- Vérification : le service récepteur vérifie la signature par rapport au répertoire de clés publiques, valide la signature et applique les règles d’accès appropriées
En pratique, cela peut réduire les ostacles pour les agents légitimes et donner aux propriétaires de sites un signal plus fort que les chaînes d’agent utilisateur ou la réputation IP seule. Parmi les utilisateurs actuels de Web Bot Auth figurent le programme « Verified Bots » de Cloudflare et le navigateur AWS Bedrock AgentCore.
La valeur ajoutée est réelle, mais la limite est tout aussi importante : Web Bot Auth vérifie d’où provient une requête signée. Il n’évalue pas l’intention.
Qu’est-ce que Know Your Agent (KYA)?
Know Your Agent (KYA) est un cadre général qui lie chaque agent IA à un propriétaire humain vérifié et définit ses capacités autorisées, son niveau de conformité et ses limites comportementales.
Là où WBA vérifie qu’une requête a été signée par un agent ou un opérateur reconnu, KYA établit qui est responsable de cet agent et ce qu’il est autorisé à faire.
Le cadre s’inspire des pratiques établies de vérification d’identité, comme Know Your Customer (KYC) et Know Your Employee (KYE). KYA est conçu pour apporter de la structure au cycle de vie d’un agent, pas seulement à la requête devant vous.
KYA est construit autour de cinq piliers:
- Identité : qui ou quoi est l’agent
- Capacité : ce qu’il peut et ne peut pas faire
- Autorisation : ce qu’il est autorisé à faire
- Comportement : comment il agit au fil du temps
- Vérification : validation continue de la confiance, pas seulement un contrôle ponctuel
Ce que KYA établit:
- Une responsabilité en matière de propriété ou de représentation
- Un périmètre et une autorisation bien définis
- L’auditabilité
- La conformité au réglementations
Ce que KYA n’établit pas:
- Si l’agent se comporte de manière sûre en ce moment, car une autorisation passée n’équivaut pas à un comportement actuel sûr
Pourquoi KYA est-il important? Exemples concrets
L’intérêt de KYA n’est pas théorique. Les incidents récents ci-dessous montrent exactement ce qui se passe en l’absence de gouvernance de l’identité des agents.
Faille de Lilli chez McKinsey
En mars 2026, des chercheurs en sécurité chez CodeWall ont utilisé un agent IA autonome pour sonder Lilli, la plateforme IA interne de McKinsey, découvrant 22 points de terminaison API non authentifiés. L’un d’entre eux contenait une vulnérabilité d’injection SQL qui a exposé 46,5 millions de messages de chat, 728 000 fichiers et 57 000 comptes d’utilisateurs.
Suppression de la base de données PocketOS
En avril 2026, un agent Cursor IA a supprimé une base de données de production entière en moins de 10 secondes. L’agent a trouvé un jeton API avec une autorité plus large que son champ d’application assigné et a agi en conséquence. L’agent ne dysfonctionnait pas – il agissait selon son propre jugement avec un périmètre d’accès trop étendu.
Automatisation « orpheline »
Lorsqu’un développeur quitte une organisation, ses agents IA peuvent continuer à fonctionner en utilisant leurs propres identifiants, malgré l’absence de supervision humaine. Le processus de départ ne parvient pas à attraper ces « agents fantômes », car les identifiants d’un agent sont séparés de ceux d’un employé.
Web Bot Auth & Know Your Agent: Quelle est la différence?
WBA et KYA sont complémentaires, pas concurrents. Ils répondent à des questions différentes et opèrent à différents niveaux de la pile.
| Dimension | Web Bot Auth (WBA) | Know Your Agent (KYA) |
| Question centrale | Cette requête a-t-elle été signée par un agent ou un opérateur reconnu ? | Qui est responsable de cet agent, et qu’est-ce qu’il est autorisé à faire ? |
| Ce qu’il vérifie | Signature cryptographique → source de la requête vérifiée | Relation agent/principal + autorisation + portée + responsabilité |
| Type de norme | Protocole cryptographique IETF (brouillon) basé sur les signatures de messages HTTP | Cadre avec plusieurs implémentations |
| Niveau d’application | CDN / pare-feu / périphérie / origine | Gouvernance / politique |
| Portée | Authentification au niveau de la requête / vérification de la source | Cycle de vie complet de l’agent |
| Application en temps réel | Dépendant de la politique | Dépendant de l’implémentation |
| Cas d’utilisation principal | Authentifier le trafic automatisé ; réduire les frictions pour les bots et agents vérifiés ; informer la politique d’accès | Identité, autorisation, responsabilité et gouvernance |
WBA et KYA renforcent tous deux l’identité, mais aucun ne fournit une détection et une protection continues basées sur l’intention.
Pourquoi aucun des deux n’est suffisant à lui seul
Un agent authentifié cryptographiquement et disposant d’identifiants KYA établis peut encore se comporter de manière malveillante ou en dehors de son champ d’application prévu lorsqu’il atteint votre site.
WBA seul vérifie d’où provient une requête signée, pas son intention. Un agent authentifié d’un grand fournisseur IA peut encore extraire vos prix de manière agressive, rechercher des failles, ou déclencher des limites de débit.
KYA seul peut établir la responsabilité, l’autorisation et la portée, mais ces signaux de confiance ne garantissent pas que chaque action de l’agent est sûre. Un agent autorisé pour un accès en lecture seule peut encore exploiter un point de terminaison mal configuré ou agir en dehors de l’objectif prévu.
Le point commun est que les signaux d’identité, de source et d’autorisation seuls ne peuvent pas déterminer si le comportement actuel d’un agent est sûr. Une analyse continue du comportement et de l’intention est toujours nécessaire lorsque l’agent interagit avec vos systèmes.
Et l’environnement de menace continue de changer. Avec la montée des violations de données alimentées par l’IA et une augmentation de 180% d’une année sur l’autre des attaques de fraude en plusieurs étapes, l’identité et l’autorisation seules ne suffisent pas à sécuriser les points de terminaison.
Ce dont vous avez besoin : l’identité associée à l’intelligence comportementale
L’identité aide à déterminer d’où provient une requête d’un agent et d’en établir la responsabilité. L’intelligence comportementale vous dit s’il faut faire confiance à ce qu’il fait en ce moment.
Un modèle de protection complet combine trois couches :
Couche 1 : Vérification de l’identité (WBA + KYA)
WBA et KYA fournissent des signaux complémentaires d’identité et de responsabilité:
- l’identité vérifiée associée à la requête signée,
- la personne ou l’organisation responsable de l’agent.
Cela crée un signal fort de responsabilité, mais pas de sécurité en soi. Les clés compromises ou les identifiants volés peuvent passer les contrôles d’identité, ce qui rend indispensable la détection continue basée sur le comportement et l’intention.
Couche 2 : Autorisation (KYA)
KYA peut établir ce que l’agent est autorisé à faire:
- portée,
- permissions,
- contraintes de politique,
- objectif visé.
L’autorisation aide à prévenir les abus, mais un agent peut encore se comporter de manière malveillante ou inattendue dans son champ d’application autorisé.
Couche 3 : Application comportementale
Le contrôle comportemental évalue et agit en continu sur ce que l’agent fait réellement. C’est là que la protection en temps réel intervient.
L’application comportementale ajoute ce que les signaux d’identité et d’autorisation seuls ne peuvent pas fournir :
- Détection de l’intention en temps réel : analyse de chaque requête en millisecondes pour déterminer si le comportement de l’agent s’aligne avec une utilisation légitime ou indique une intention malveillante
- Évaluation de confiance : mise à jour en continu du score de confiance de chaque agent IA basé sur la force de l’identité, l’intention comportementale et la réputation
- Analyse des motifs au niveau de la session : évaluation du comportement sur l’ensemble d’une session pour identifier des motifs et des activités en plusieurs étapes qui peuvent ne pas être apparents à partir d’une seule requête
- Atténuation automatique : limitation du débit, défis ou blocage sans perturber les utilisateurs légitimes ou nécessiter une intervention manuelle
Si le comportement semble risqué, le système peut limiter le débit, demander une vérification ou bloquer l’accès en temps réel. C’est la couche manquante entre l’identité et la sécurité.
Comment les propriétaires de sites devraient-ils aborder l’identité et la protection des agents?
La bonne approche n’est pas de choisir entre WBA et KYA. Il s’agit d’utiliser les deux là où c’est approprié et de combiner leurs signaux avec l’application de règles comportementales.
Une stratégie pratique se présente ainsi :
- Enregistrez et reconnaissez les agents légitimes. Utilisez WBA et d’autres mécanismes de bots vérifiés pour authentifier le trafic des agents reconnus et réduire les frictions inutiles.
- Appliquez KYA là où c’est approprié. Pour les systèmes IA que vous déployez ou autorisez, établissez une responsabilité, une portée et une autorisation claires.
- Ajoutez des mesures de contrôle comportemental et surveillez en continu. Utilisez une couche de confiance en temps réel pour les bots et agents, comme DataDome, qui évalue le comportement et l’intention en parallèle des signaux d’identité et d’autorisation disponibles.
- Protégez le trafic, qu’il soit vérifié ou non. Votre protection ne doit pas dépendre de la fourniture d’informations d’identification par chaque agent.
DataDome rassemble ces signaux, prenant en charge à la fois Web Bot Auth et Know Your Agent aux côtés de l’intelligence comportementale et de l’application en temps réel. DataDome peut vérifier les signatures WBA et incorporer le contexte d’identité et d’autorisation fourni par les partenaires KYA pour prendre des décisions de confiance plus éclairées en temps réel.
Nommé Leader dans The Forrester Wave™: Bot and Agent Trust Management Software, Q2 2026, DataDome analyse l’intention pour arrêter la fraude en moins de 2 millisecondes avec une précision de détection de 99,99%.
Réservez une démo pour découvrir comment les fonctionnalités de confiance des agents de DataDome vous offrent une visibilité et un contrôle complets sur chaque agent, qu’il soit vérifié ou non.
Web Bot Auth est un protocole cryptographique qui vérifie la source associée à une requête signée. Know Your Agent est un cadre de gouvernance qui lie un agent à un propriétaire humain vérifié et définit son périmètre d’autorisation. WBA répond à la question « De quelle plateforme s’agit-il ? », tandis que KYA répond à la question « Qui est responsable et qu’est-ce qu’il est autorisé à faire ? ». Ces deux solutions opèrent à des niveaux différents et résolvent des problèmes distincts.
Pas à lui seul. WBA vérifie la source associée à une requête signée, mais il n’évalue pas si cette requête est légitime ou malveillante. Un agent authentifié provenant d’un grand fournisseur d’IA peut toujours effectuer un scraping agressif, rechercher des vulnérabilités ou exécuter des actions non autorisées. WBA réduit les frictions pour les agents reconnus ; il n’empêche pas les comportements malveillants.
Oui. KYA permet d’établir la responsabilité, l’autorisation et le périmètre d’action, mais ces signaux ne garantissent pas que chaque action effectuée par l’agent soit sûre. Un agent opérant dans son périmètre autorisé peut toujours exploiter un terminal mal configuré, dépasser les limites de débit ou accéder à des données présentant un risque. La détection basée sur l’intention apporte le contexte comportemental en temps réel nécessaire pour identifier les activités malveillantes ou à risque.
Ils répondent à des problèmes différents ; utilisez donc chacun d’eux là où cela s’avère pertinent. La WBA peut réduire les obstacles pour les agents reconnus, tandis que le KYA apporte la responsabilité, l’autorisation et la portée. Aucun des deux ne remplace l’application comportementale, qui aide à détecter les activités risquées ou malveillantes même lorsqu’un agent dispose de signaux d’identité ou d’autorisation valides.
L’application des règles comportementales consiste en une analyse en temps réel de ce qu’un agent fait réellement, et non pas uniquement de son identité ou de son autorisation vérifiées. Elle évalue les modèles de requêtes, le comportement au cours des interactions, les appels d’outils et l’accès aux données afin de déterminer si les actions d’un agent correspondent à une utilisation légitime. Lorsque ce n’est pas le cas, le système peut limiter le débit, demander une confirmation ou bloquer l’accès sans attendre qu’un humain examine les journaux.