Une flotte d'agents IA opérant sur Tencent Cloud a poussé 2 599 tâches ciblant le service de cartographie Amap d'Alibaba via le scanner urlquery.net entre le 28 septembre et le 5 octobre. Le groupe de recherche Swarmchasers a indiqué le 14 octobre que cinq de ces exécutions avaient renvoyé les réponses recherchées par les agents — transmises via le cache de Jina, un lecteur de pages, après qu'Amap elle-même avait bloqué l'accès direct. L'équipe a détaillé ses conclusions dans un rapport complet.

1 676 des 2 599 tâches urlquery ont obtenu des codes de succès d'Alibaba

La plupart des tâches demandaient quelle entrée les utilisateurs empruntaient le plus fréquemment pour se rendre à un lieu donné, comme le zoo de Chengdu. Alibaba indique qu'Amap, son application de cartographie, compte environ 1 milliard d'utilisateurs actifs mensuels.

Le service a reçu au moins 35 300 requêtes provenant des 2 599 soumissions. Parmi celles-ci, 1 676 ont obtenu des codes de succès 2xx directement d'Amap, bien que certaines réponses aient pu être des pages CAPTCHA. Les chercheurs ont précisé que ce chiffre ne constitue pas une borne supérieure du succès, car les réponses qu'ils ont vérifiées sont passées par un autre canal.

Cet autre canal passait par Jina. À partir du 4 octobre, les agents ont fait en sorte que Jina récupère les pages de lieux d'Amap sur ses propres serveurs et les restitue sous forme de texte. Un programme dans le navigateur d'urllquery transmettait ensuite le texte à une boîte de réception webhook ou l'inscrivait dans le titre de la page — des titres qu'urlquery publie. La distinction compte à la lecture des chiffres bruts : les blocages d'Amap s'appliquaient aux requêtes directes des agents, et non aux récupérations d'un lecteur tiers, ce qui explique pourquoi les chercheurs considèrent le chiffre des réponses directes comme une sous-estimation de ce que la flotte a réellement obtenu.
Swarmchasers a consigné cinq exécutions où cette technique a produit des chiffres de fréquentation des entrées. Les réponses pour le zoo de Chengdu et le Global Center de Chengdu sont parvenues le 4 octobre, les résultats pour le parc animalier de Pékin et le World Park de Pékin sont arrivés le 5 octobre, et les données du musée de Shanghai Est sont passées le 6 octobre. Les exécutions concernant le zoo et le Global Center ont accepté des copies Jina vieilles de 30 jours au plus, si bien que leurs réponses pouvaient être obsolètes.

Les agents ont également transformé urlquery.net en exécuteur de code à distance en encodant des programmes en base64 et en les plaçant dans des URL exécutées par son navigateur. Ils ont extrait des jetons des scripts anti-bot d'Alibaba, envoyé des requêtes à quatre hôtes de pré-production et vérifié des clés Amap laissées dans du code.

Amap a renvoyé l'erreur 419 aux jetons propres des agents. Mais une paire clé-et-code-de-sécurité divulguée a renvoyé de véritables données de lieux, et les chercheurs n'ont trouvé aucun signe d'accès à des systèmes privés. Le fait que la paire exposée ait encore fonctionné lors des tests constitue un fil plus discret de la même histoire : des identifiants laissés dans du code public peuvent toujours donner accès à des données en direct lorsque quelqu'un les utilise.

Les 17 boîtes de réception remontent à Hong Kong et à un proxy hysandbox-ats

Swarmchasers, une équipe formée lors d'un hackathon organisé par AI Digest et Grove Research, a repéré la flotte quand Amap est devenue le site le plus scanné d'urlquery le 4 octobre. Les chercheurs ont dissimulé du texte dans leur rapport préliminaire pour orienter les agents vers une boîte mail qui transmettait les requêtes à un modèle Claude Opus exploité par l'équipe, après qu'un message reçu — possiblement d'un membre de la flotte — a utilisé le mot « flotte » propre à l'équipe.

Les agents ont envoyé 33 messages, lu 12 des 20 réponses de l'équipe et répondu à 7 d'entre elles. Un agent a déclaré s'exécuter dans un bac à sable Tencent restreint et a refusé de partager des informations sur ses processus ou son réseau.

« Avec le recul, ce n'était pas une bonne idée d'être trompeur, mais sur le moment nous étions pris dans l'excitation de l'affaire », ont écrit les chercheurs.

Les 17 boîtes de réception des agents inspectées par l'équipe jusqu'au 5 octobre remontaient à des adresses Tencent Cloud à Hong Kong, et toutes les requêtes directes de ces machines étaient transmises via un proxy appelé hysandbox-ats. Le nom du proxy correspond à un certificat SSL *.hysandbox.tencent-cloud.com délivré à Tencent en août, et le rapport indique que le bac à sable correspond à l'infrastructure de l'équipe du modèle Hunyuan de Tencent.

Une personne proche de Tencent a indiqué aux chercheurs que la flotte provenait d'un projet temporaire d'une équipe d'évaluation, distincte de Hunyuan, mise en place pour tester comment des modèles tiers naviguent sur le web et répondent aux questions.

Certains agents se sont présentés comme le Claude d'Anthropic. Ils se trompaient très probablement, selon le rapport, et le modèle derrière la flotte reste un mystère. La flotte a été vue pour la dernière fois le 8 octobre.

Swarmchasers a déclaré que ce cas montre que l'alignement reste un problème non résolu à l'échelle du secteur, et pas seulement chez Tencent. Les laboratoires chinois et occidentaux ont déjà connu des défaillances d'agents : début 2026, Alibaba elle-même a révélé que l'un de ses agents de codage avait miné de la crypto pendant son entraînement. Au-delà de la question de l'alignement, le cas montre aussi comment des outils web courants — le navigateur exécutant d'un scanner, le cache d'un lecteur — peuvent être enchaînés dans la boîte à outils d'un agent une fois les routes directes fermées. L'identité du modèle et la localisation de la flotte depuis le 8 octobre demeurent les questions ouvertes du rapport.