Certifiés, fiables, authentifiés : pourquoi il faut authentifier les agents IA

Contexte

Bien avant l’essor des grands modèles de langage (LLM), une multitude de services de bots étaient utilisés pour explorer des sites web à des fins diverses et variées, notamment la collecte de données, la veille économique et la surveillance de la disponibilité des services.

Il arrive parfois que vous souhaitiez autoriser ce type de trafic automatisé. Le principal défi consiste à authentifier le trafic. Si vous ne le faites pas, des acteurs malveillants pourraient facilement imiter le service de bot et obtenir un accès non autorisé. Dans cette optique, nous pouvons définir un « bot vérifié » comme suit :

• les requêtes du bot sont automatisées mais non malveillantes. Il ne doit pas se livrer à des activités nuisibles comme les attaques par Distributed Denial of Service (DDoS), le scalping, les account takeovers (ATO), le scraping intensif ou l’exploitation de vulnerabilités ;
• il a un objectif clair et utile. La fonction principale du bot est d’assister les humains dans une tâche spécifique et bien définie ;
• ses requêtes sont authentifiées par un système dédié exclusivement à son service ;
• ses opérations sont transparentes. Le but, le comportement et l’origine du bot sont documentés publiquement et régulièrement mis à jour.

Cet article examine comment l’essor de l’IA agentique transforme le paysage de l’authentification des bots. Nous commencerons par passer en revue les méthodes d’authentification traditionnelles courantes avant de nous pencher sur la norme moderne qui devrait être adoptée aujourd’hui.

Pourquoi l’IA agentique change-t-elle la donne en matière d’authentification des bots ?

Alors que le nombre d’agents d’IA augmente, la vérification d’un service de bot devient plus cruciale que jamais. La mission principale de ces agents d’IA est d’agir au nom des humains, en nous assistant dans des tâches complexes et fastidieuses. Par exemple, ils peuvent être utilisés pour trouver et réserver un hôtel, comparer différents sites web pour trouver le produit idéal, etc.

Les agents d’IA posent un défi particulier car leur modèle opérationnel (exécuter leur propre navigateur ou fonctionner comme une extension côté utilisateur) les fait apparaître comme des menaces très sophistiquées. Sans mécanisme d’authentification fiable, ils sont pratiquement impossibles à discerner des bots malveillants les plus intelligents.

Cela met en évidence une différence fondamentale de motivation : les agents d’IA légitimes ont un objectif vérifiable et utile, ce qui devrait les inciter à authentifier leurs requêtes. À l’inverse, les bots malveillants chercheront toujours à échapper à l’identification pour poursuivre leurs activités illicites.

Authentification traditionnelle (et imparfaite)

La grande majorité des services de bots peuvent être identifiés grâce à leur user agent. Cependant, comme un user agent n’est qu’un simple en-tête HTTP, il peut être facilement falsifié. Cette méthode suffit pour bloquer le trafic indésirable, mais elle est totalement insuffisante pour l’autoriser.

En bref, un agent utilisateur peut identifier un service de bot, mais il ne peut pas l’authentifier. Pour utiliser une analogie, c’est comme si quelqu’un vous appelait au téléphone et prétendait être le PDG, mais n’avait aucun moyen de prouver son identité.

Authentification traditionnelle (et plus fiable)

Des méthodes plus restrictives et fiables ont été largement adoptées, notamment :

• les listes blanches d’adresses IP : limitation du trafic à une liste fixe d’adresses IP autorisées,
• vérification DNS inversée : vérifier qu’un pointeur DNS inversé est configuré sur les adresses IP d’origine.

Pour que cette approche fonctionne, le service de bot doit :

• documenter publiquement ses adresses IP et/ou ses enregistrements DNS inversés ;
• maintenir la précision de cette documentation ;
• s’assurer que ces IP sont utilisées exclusivement pour le service de bot, afin d’éviter leur utilisation par des acteurs malveillants.

C’est là que ces méthodes traditionnelles montrent leurs limites. Elles sont extrêmement restrictives pour le service de bot et, parfois, elles ne fonctionnent tout simplement pas. Un service de bot peut utiliser un fournisseur cloud, ce qui signifie qu’il n’a pas le contrôle de ses adresses IP. Ces IP peuvent changer à tout moment ou être partagées avec d’autres services. De plus, un agent d’IA exécuté dans le navigateur d’un utilisateur aura une adresse IP d’origine imprévisible, ce qui rend cette méthode d’authentification totalement inapplicable.

En résumé, bien que les listes blanches d’adresses IP et de DNS inversé soient efficaces, elles ne sont pas évolutives. Cela revient à authentifier une personne à l’aide de son justificatif de domicile, mais à l’échelle nationale. Imaginez un pays qui tente de produire une liste précise et en temps réel des justificatifs de domicile de tous ses citoyens : ce modèle n’est tout simplement pas réalisable.

À la pointe : suivre la voie tracée par OpenAI

Nous utilisons tous la cryptographie moderne depuis des décennies, souvent sans même nous en rendre compte. L’exemple le plus courant est HTTPS.

Le protocole Transport Layer Security (TLS) permet à un client d’authentifier le serveur auquel il se connecte. Le processus est simple :

• le client envoie un challenge cryptographique au serveur ;
• le serveur répond avec une réponse signée ;
• le client vérifie la réponse et sa signature. Si elles sont valides, un canal chiffré est établi pour toutes les requêtes suivantes.

Un service de bot peut utiliser ce même principe cryptographique pour s’authentifier. Il peut signer chacune de ses requêtes, et le site web peut vérifier cette signature. Cette approche implique certains éléments.

Pour le service de bot :

• générer une paire de clés, composée d’une clé privée et d’une clé publique ;
• signer chaque requête avec sa clé privée ;
• fournir un chemin public pour que d’autres puissent découvrir sa clé publique.

Pour le site web :

• obtenir la clé publique du bot ;
• recueillir la signature qui accompagne chaque requête ;
• utiliser la clé publique pour vérifier la signature de la requête. Si la signature est valide, la requête est traitée, sinon elle est bloquée.

Source : https://datatracker.ietf.org/doc/html/draft-meunier-web-bot-auth-architecture

Cette méthode élimine tous les inconvénients des approches précédentes. Il s’agit d’un modèle d’authentification à la pointe, évolutif, qui fonctionne indépendamment de l’infrastructure ou de l’adresse IP d’un bot.

Comment un service de bot procède : l’agent OpenAI

OpenAI est l’un des premiers services d’agents IA à adopter ce nouveau standard. Le 25 juillet, il a annoncé que ses requêtes seraient authentifiées à l’aide de signatures cryptographiques. Cela répond immédiatement à deux des exigences clés que nous venons d’évoquer.

La dernière exigence pour un service de bot est la méthode de publication de sa clé publique. OpenAI contribue à définir cette pratique dans le domaine. Pour y répondre, l’IETF propose un RFC fournissant une méthode standardisée de découverte de clé publique. Le service Agent d’OpenAI adopte cette norme.

Cette initiative peut être résumée ainsi : le service de bot place sa clé publique dans

/.well-known/http-message-signatures-directory sous un domaine dont il est propriétaire.

Vous reconnaîtrez peut-être ce chemin /.well-known/ ; c’est la même méthode utilisée par Let’s Encrypt pour générer un certificat TLS (Transport Layer Security). Cette similitude n’est pas un hasard, car ce processus repose également sur des signatures cryptographiques. Une fois encore, ces mécanismes éprouvés sont le moyen le plus fiable d’authentifier une entité sur Internet.

Du côté du site web

Le nouveau RFC offre une méthode standard pour qu’un site web obtienne la clé publique du service de bot. Cela peut se faire via le serveur web lui-même ou via un service périphérique (edge), comme une plateforme anti-fraude (Origin sur l’image ci-dessous).

La deuxième étape consiste à collecter la signature de la requête. Le RFC précise que cette signature doit être envoyée via des en-têtes HTTP. Pour simplifier, ces en-têtes ont trois rôles :

• Signature-Agent : indique pour quel agent la signature est destinée ;
• Signature-Input : signer l’ensemble du corps de la requête serait inefficace. Cet en-tête définit les parties spécifiques de la requête à signer. Il inclut également des protections anti-replay, telles qu’un nonce, une fenêtre de validité et un identifiant unique de requête ;
• Signature : il s’agit de la signature cryptographique réelle, encodée en Base64.

Source : https://datatracker.ietf.org/doc/html/draft-meunier-web-bot-auth-architecture

Point de sécurité essentiel concernant l’en-tête Signature-Agent : pour que le protocole reste sécurisé, vous ne devez jamais vous fier aveuglément à la valeur de cet en-tête pour récupérer la clé publique. La clé publique doit être récupérée à partir d’un canal distinct et fiable afin d’empêcher un acteur malveillant de se faire passer pour un bot légitime.

Détecter les imposteurs

Pour simplifier, les requêtes signées offrent une forme d’authentification solide, éprouvée et évolutive. C’est comme si un pays délivrait un certificat unique et signé à chaque citoyen. Lorsqu’un citoyen doit prouver son identité à une autorité, il lui présente simplement son certificat. L’autorité peut rapidement vérifier son authenticité.

Le diagramme ci-dessous illustre le mécanisme de signature des requêtes avec un fraudeur qui imite l’agent OpenAI (OpenAI agent).

Ne disposant pas de la clé privée authentique de ChatGPT, un fraudeur tente de falsifier une requête. Il construit une requête prétendant être l’agent ChatGPT dans l’en-tête Signature-Agent et prépare les autres en-têtes comme s’il s’agissait d’un bot légitime. Cependant, il ne peut pas produire une signature valide.

Lorsque cette requête atteint un service comme DataDome, nous notons d’abord sa prétention à provenir de l’agent OpenAI. Suivant le principe « faire confiance mais vérifier », nous lançons immédiatement le processus d’authentification. Nous procédons ensuite ainsi :

• nous récupérons la clé publique officielle de l’agent ChatGPT ;
• nous vérifions que toutes les informations dans Signature-Input sont valides ;
• nous tentons de valider la signature à l’aide de la clé publique authentique de ChatGPT.

Comme la requête ne possède pas de signature valide, la vérification cryptographique échoue immédiatement. La signature est déclarée invalide et la requête frauduleuse est bloquée avec succès.

Conclusion

Nous sommes en 2025, et l’ère des méthodes d’authentification obsolètes et facilement falsifiables doit prendre fin. Il est temps d’adopter pleinement les solutions évolutives, durables et fiables que la cryptographie moderne offre depuis longtemps.

En tant que service de bot engagé pour la transparence et de bonnes intentions, vous devez montrer l’exemple en adoptant ce nouveau standard cryptographique. En promouvant le RFC pour la découverte de clé publique et en l’utilisant pour authentifier vos requêtes, vous pouvez instaurer la confiance avec les services avec lesquels vous interagissez.

En fin de compte, si l’authentification cryptographique fournit un moyen robuste de vérifier l’identité d’un bot, les mécanismes traditionnels de détection d’intention restent une couche essentielle pour identifier et prévenir les abus d’un service IA.