Des agents silencieux sont déjà présents sur votre site

Un agent silencieux est un agent automatisé qui agit via un navigateur standard ou une session utilisateur sans fournir d'identité d'agent vérifiable. Il peut s'agir d'un assistant légitime agissant pour le compte du client, d'un agent non autorisé dépassant son mandat, ou d'un processus automatisé malveillant imitant le comportement d'un agent. 

Lorsque des activités humaines et automatisées ont lieu au sein d'une même session authentifiée, il devient plus difficile de faire la distinction entre les deux. En l'absence d'une identification explicite de l'agent, les entreprises doivent s'appuyer sur des indicateurs comportementaux et techniques qui ne révèlent pas toujours tout le contexte : si vous assouplissez les mécanismes de détection pour autoriser les agents légitimes, vous risquez d'exposer votre entreprise à des agents automatisés malveillants ; si vous les renforcez, vous risquez de bloquer des actions autorisées par vos clients. 

Depuis les débuts de la gestion des bots, toute automatisation légitime se signalait d'elle-même. Les indexeurs de recherche ont publié leurs agents utilisateurs ainsi que leurs plages d'adresses IP. Par exemple, un site pouvait identifier Googlebot, le vérifier et le traiter différemment d'un extracteur anonyme. Cet arrangement fonctionnait parce que l'opérateur du bot souhaitait être reconnu.

Les agents utilisateurs ont involontairement rompu cet accord. Ils ont été conçus pour utiliser le Web comme le ferait un être humain : ils utilisent un navigateur, naviguent de page en page, remplissent des formulaires et contournent les obstacles comme le ferait un utilisateur humain. 

• Muse s'exécute dans une machine virtuelle sur le cloud de Meta et intègre un navigateur. 

• Instinct maintient un environnement de bureau dans le cloud de manière persistante y accède à l'aide des identifiants enregistrés de l'utilisateur, y compris son adresse e-mail et ses informations de paiement. 

• Dots s'exécute en tant qu'agent cloud fourni par OpenAI. 

Du point de vue du serveur, chacun de ces systèmes correspond à une session de navigateur : la chaîne User-Agent indique un navigateur, mais leur comportement révèle un processus automatisé.

Les rapports se déclinent en deux versions, selon que l'agent relève du secteur bancaire ou du secteur commercial.

Bloquer tous les agents est la solution la plus rapide et la plus facile à justifier en interne. Lors de la connexion et pour toute opération de mouvement de fonds, le blocage peut également constituer, pour l'instant, la mesure de sécurité la plus appropriée.  Cependant, lorsqu'elle est appliquée à l'ensemble d'un site, il ne s'agit plus d'une simple décision de sécurité, mais elle devient une décision commerciale. L'agent agit pour le compte d'un client qui souhaite effectuer un achat, et le blocage touche en fin de compte ce client. Les utilisateurs qui rencontrent ce blocage ne concluent pas que leur agent a besoin de meilleurs identifiants ; ils changent de site pour en consulter un qui fonctionne.

L'accès en lecture seule constitue une version plus aboutie, bien qu'elle réponde à une question plus restreinte qu'il n'y paraît. La consultation d'un compte n'est pas sans risque lorsque l'agent agit ensuite en fonction des informations lues dans un autre système, et de nombreuses opérations importantes ne sont ni une simple consultation ni un virement bancaire, notamment la réservation, la replanification, la modification d'une adresse ou l'obtention d'une récompense. Le mode lecture seule permet de gagner du temps sans pour autant définir de règles.

Une seule catégorie « bots d'IA » ne peut pas être la source des règles, car les utilisateurs qui la composent ont des attentes opposées. Un indexeur qui collecte vos descriptions de produits pour entraîner un modèle, un indexeur de rechrche qui référence votre site afin que votre marque apparaisse dans une réponse générée par l'IA, et un assistant qui récupère une seule page parce que votre client a posé une question constituent trois types d'opérations fondamentalement différents.

En août 2026, nous avons divisé cette catégorie dans l'Akamai Bot Directory en trois :

• Indexeurs pour l'entraînement de l'IA : collectent du contenu à grande échelle pour l'entraînement de modèles (par exemple, GPTBot, ClaudeBot et Met -ExternalAgent).

• Indexeurs pour la recherche par IA : indexent les sites pour la recherche par IA et les citations des sources (par exemple, OAI-SearchBot, Claude-SearchBot et PerplexityBot).

• Bots de collecte et agents d'IA : accèdent à une page en temps réel pour répondre à une question ou accomplir une tâche (par exemple, ChatGPT-User, ChatGPT Agent, GoogleAgent-Mariner et d'éventuels agents silencieux).

Cette séparation offre aux entreprises un contrôle plus précis sur des actions qui, autrement, se contrediraient : restreindre l'accès des indexeurs d'entraînement pour protéger le contenu que l'organisation n'a pas autorisé ; autoriser les indexeurs de recherche afin que ce contenu reste visible dans les réponses générées par l'IA ; et considérer les agents en temps réel comme le trafic généré par les utilisateurs qu'ils représentent généralement. Ces règles sont définies par catégorie par l'entreprise.

La visibilité doit également s'étendre au-delà du catalogue. Le trafic qui préoccupe une banque n'est pas celui des simples visiteurs, mais celui des utilisateurs connectés. Le suivi de l'activité des agents dans les sessions authentifiées constitue une mesure différente de celui effectué sur les pages de contenu, et une entreprise doit disposer de ces deux perspectives avant de pouvoir commencer à gérer son exposition.

Les catégories indiquent le type de trafic reçu. La question suivante est de savoir comment vous avez acquis vos connaissances sur chaque agent. Il existe deux réponses très différentes à cette question.

Certains agents se déclarent d'une manière qui peut être vérifiée. Ils publient une clé, signent leurs requêtes et peuvent être vérifiés en bordure de l'Internet, sans qu'il soit nécessaire de se fier à leur seule parole. Ces agents sont identifiés, et un agent identifié peut appliquer ses propres règles, y compris au moment du paiement, car la reconnaissance ne dépend d'aucun élément pouvant être copié.

Tout le reste est déduit. Nous attribuons les agents à partir des caractéristiques observées et les qualifions de « présumés » ; c'est pourquoi les rapports affichent une mention telle que « Agent Muse (présumé) » plutôt qu'une identité confirmée. Cette étiquette est vraiment utile : elle indique qu'un agent accède à votre site, donne une estimation de la quantité de données concernée et précise leur destination. Cela ne vous indique pas que la requête suivante présentant le même motif provient du même agent, et une règle de sécurité rédigée comme si c'était le cas finira par accorder l'accès à une ressource que vous n'aviez pas l'intention d'autoriser.

L'évaluation des risques comportementaux est la solution de repli lorsque l'attribution n'est pas possible, et c'est le seul moyen de contrôle qui reste efficace lorsque les attaquants utilisent des techniques de tromperie. En analysant la manière dont une session évolue plutôt que ce qu'elle prétend être, l'analyse comportementale s'avère efficace face à un agent conçu pour imiter un navigateur et face à un bot de revente conçu pour imiter un acheteur. 

C'est aussi la raison pour laquelle des agents légitimes sont parfois bloqués. Ce résultat correspond au fonctionnement prévu du système : tant que les agents ne pourront pas s'authentifier, une partie du trafic légitime des agents sera classée dans la catégorie des utilisateurs non vérifiés.

La conséquence pratique pour une équipe de sécurité est l'analyse conjointe de ces deux signaux : la catégorie ou l'étiquette et le comportement. La catégorie et l'étiquette vous indiquent qui arrive et en quel volume. Le comportement vous indique ce que cette session est en train de faire à l'instant. Aucun des deux ne suffit à lui seul pour définir les règles.

Une page de catalogue et une page de paiement présentent des risques différents. Un agent qui lit des descriptions de produits pour le compte d'un client effectue une tâche que les navigateurs classiques ont toujours accomplie. Les entreprises recherchent généralement ce trafic, car il génère des ventes et parce que les assistants IA deviennent un moyen de découverte. 

Cependant, lorsqu'un même agent passe une commande, il effectue une action qui entraîne un mouvement de stocks et de fonds, et cela mérite le même niveau d'examen que celui appliqué à toute automatisation. La page de connexion se situe plus près de la page de paiement que du catalogue. Il en va de même pour tout ce qui modifie un compte.

Voici ce que signifie, dans la pratique, une action ciblée : 

• une seule règle relative au contenu, permettant de surveiller ou d'autoriser la majeure partie du trafic généré par l'IA ;

• une approche différente pour chaque transaction : chaque requête est évaluée en vue d'une automatisation, indépendamment de sa dénomination ;

• une troisième approche en matière d'authentification, où la question n'est pas de savoir si la session est automatisée, mais si la personne qui l'utilise est bien le titulaire du compte et s'il s'agit d'une action identifiable.

Dans cette configuration, le résultat ressemble à ce que la plupart des détaillants constatent déjà : un agent peut consulter le catalogue pour le compte d'un client, mais il est bloqué lorsqu'il tente d'effectuer un achat. Cela permet de maintenir ouverte la voie de découverte, d'appliquer les contrôles existants là où se trouvent les fonds, et laisse l'entreprise libre de revenir sur sa décision pour n'importe quel point de terminaison sans revoir l'ensemble des règles.

La même logique permet de répondre à la question que l'on nous pose le plus souvent : comment permettre à un agent spécifique de finaliser un achat. La solution efficace ne consiste pas en une exemption apposée en regard d'une signature, car tout élément imitant cette signature en hérite. Les processus d'authentification et de vérification sont efficaces. Une fois qu'un agent a prouvé son identité, il peut bénéficier de ses propres règles, y compris au moment du paiement, et l'entreprise peut accorder l'accès à une entité vérifiée plutôt qu'à un profil type.

Chaque aspect de ce problème trouve son origine dans le même élément manquant : un agent ne peut pas prouver son identité ni l'entité pour laquelle il travaille. Les sites doivent donc recourir à des déductions, lesquelles ne sauraient étayer le processus décisionnel envisagé par les entreprises.

Cette pièce est en cours de fabrication. Web Bot Auth, une proposition de norme au sein de l'Internet Engineering Task Force que nous soutenons, permet à un agent de signer ses requêtes afin qu'un site puisse vérifier l'origine de celles-ci par des moyens cryptographiques, plutôt que de se fier à un en-tête. 

Le protocole « Trusted Agent » de Visa s'appuie sur la même approche de signature pour les paiements. Nous l'avons intégré afin que les commerçants puissent déterminer si un agent est simplement en train de naviguer ou s'il effectue un paiement, et associer cet agent au client qu'il représente. « Know Your Agent », développé par Skyfire, ajoute une couche d'identité qui lie un agent à une entreprise ou un utilisateur vérifié, et nous avons intégré l'écosystème Experian Agent Trust en parallèle. En juin 2026, nous avons intégré ces éléments dans un cadre de sécurité agentique couvrant l'identité, l'observabilité, la confiance et l'application des règles en bordure de l'Internet.

Voici quatre mesures que vous pouvez prendre dès maintenant : 

1. découvrir les agents silencieux déjà présents sur votre site ;

2. définir des règles par point de terminaison ;

3. faire de la vérification le chemin vers un « oui » ;

4. garder la porte de la navigation ouverte en attendant que l'identification soit opérationnelle.

Les entreprises qui tireront leur épingle du jeu ne seront pas celles qui auront simplement bien choisi les agents auxquels faire confiance. Ce seront celles qui auront su anticiper, évaluer dans quelle mesure elles peuvent vérifier le trafic, et intervenir sur un point de terminaison sans perturber le reste de l'activité.

Pour examiner vos catégories de trafic d'IA actuelles et vos règles en matière de transaction, contactez un expert Akamai.