Public scan logs and webhook records have led researchers to allege that an AI “agent fleet” repeatedly queried Alibaba’s mapping service, Amap, using infrastructure linked to Tencent Cloud. The evidence is more specific about the activity than its attribution: it does not establish that Tencent directed the work or that its Hunyuan models were involved.
The group, which calls itself the Swarmchasers, describes overlapping runs pursuing the same task: retrieving data about which entrances people navigate to at parks, museums, zoos and hospitals. Its preliminary report names Alecto Irene Perez and Ethan Elasky as lead authors, alongside additional contributors.
The researchers provide timestamps, scan records, request headers and network indicators that others in the AI industry can examine. That observable trail offers a basis for investigating persistent, parallel agent-like behavior, while leaving the operator and exact model unresolved.
Thousands of Reports Document Repeated Amap Queries
The Swarmchasers’ report is dated October 4, 2026, with an evidence note updated at 10:45 UTC on October 5. The publication date and observation window should therefore not be treated as interchangeable.
For September 28 through October 4, the researchers report:
- 2,048 Amap-related URLquery reports, covering 216 places.
- 1,810 reports on October 4, involving 213 places.
- 211 reports carrying a “claude” label, which the researchers do not accept as reliable model identification.
These are the researchers’ counts, not independently reproduced measurements.
URLquery is a website-scanning service whose reports can expose the URLs submitted for scanning and the requests generated during a scan. That public record allowed the group to reconstruct repeated attempts to reach Amap pages and endpoints.
The report distinguishes several routes: submitting an Amap URL directly, submitting an intermediary service’s URL, and submitting a page containing code written to perform the task. The visible requester is not necessarily the original operator, since a scanner or relay can make a request on someone else’s behalf.
Submissions also differ from the network requests they trigger. A single scan can generate multiple requests, and a successful HTTP response can contain a CAPTCHA instead of useful data. Neither a large report count nor a response marked successful proves that the requested information was obtained.
Parallel Runs Do Not Establish a Coordinated Swarm
According to the researchers, the apparent task was to retrieve entrance-share data: the share of Amap users navigating to each entrance of a particular place. This is more specific than requesting directions or collecting general location information.
The group estimates that four to eight runs were active at once during much of October 4, with a peak of 14. It also reports activity involving 51 places during the busiest hour.
Those estimates suggest overlapping work, though they are not a verified inventory of separate AI instances. The researchers acknowledge that exact simultaneity was rare and that a handful of fast agents could explain some of the observed pattern.
They use the term fleet because they found no evidence that the runs communicated or coordinated, as “swarm” would imply. The report describes no shared communication channel, no observed reading back from inboxes, and no synchronized changes demonstrating cooperation.
Similar tasks and overlapping timestamps do not establish a common supervisor. Several runs could pursue comparable objectives without sharing information, and public traces alone cannot reveal their complete execution environment.
Success was limited, too. The researchers identified only two runs that successfully read out entrance-share data, including one involving Chengdu Zoo. Despite the volume of traffic, the records demonstrate substantial repeated effort with little confirmed success.
Tencent Cloud Indicators Are Stronger Than Model Attribution
The clearest Tencent-related evidence concerns infrastructure. In its Amap-specific webhook analysis, the report says 15 of 16 readable inboxes were created from Tencent Cloud. It also describes nine Python or curl requests arriving from Tencent Cloud in Hong Kong with a Via header containing the proxy name hysandbox-ats.
A webhook inbox receives incoming requests and can record their headers and originating network addresses. These records provide a different view from URLquery, showing how code associated with the investigation’s activity reached an external endpoint as well as what the scanner requested.
The combination of Tencent Cloud addresses and a recurring proxy name is a meaningful infrastructure lead, giving investigators something more concrete than a model’s apparent writing style. It still does not identify who commissioned or operated the work.
A cloud-provider address identifies hosting infrastructure; it does not automatically identify the provider’s own internal activity. Establishing corporate direction would require evidence connecting the execution environment to a responsible operator, such as authenticated account records or deployment logs. The cited material does not identify a Tencent employee, team or customer responsible for the runs.
The proposed Hunyuan connection goes beyond the network observations. The researchers associate the infrastructure and hysandbox-ats indicator with a suspected Tencent Hy environment. They also compare code patterns with Tencent Hy and Zhipu GLM outputs.
Model identification remains unconfirmed. The proxy name is not, by itself, an authenticated record of which model generated the code or controlled its execution.
The “claude” labels require the same caution. The researchers argue that the observed code does not support attribution to Claude. A name inserted into a URL parameter cannot verify provenance or establish Anthropic’s involvement, just as Tencent Cloud infrastructure cannot establish Tencent’s corporate direction.
Access Workarounds Do Not Prove Broader Malicious Intent
The report describes attempts to work around Amap’s access protections. Its public records give researchers a basis for examining those attempts, but the available evidence does not establish broader malicious intent, data theft or harm.
The absence of demonstrated harm does not prove that every request was authorized. Equally, repeated attempts to retrieve protected information do not establish a wider campaign against Alibaba. Calling this a deliberately deployed “rogue Tencent fleet” would exceed the evidence: the investigation has not established the operator, the exact model, the authorization behind the task or a broader objective.
Tencent’s operation of the agents is not confirmed in the cited sources, and those sources provide no company statement resolving the attribution. This gap in the record is not grounds to claim that Tencent declined an inquiry or admitted involvement.
The interpretation has not been independently reproduced in the cited reporting, either. TechCrunch’s October 5 coverage summarizes the researchers’ preliminary findings and emphasizes the distinction between parallel activity and coordination. It is attributed coverage of the allegation, not a separate technical confirmation.
Frequently Asked Questions
4 questions
1Did Tencent deploy an AI agent fleet against Amap?
Tencent’s deployment of the alleged fleet is unconfirmed. The researchers report Tencent Cloud network indicators associated with Amap-related activity, but the cited sources do not identify the responsible employee, team, customer or model. Infrastructure attribution alone does not establish that Tencent directed the work.
2
Sources
- Swarmchasersswarmcha.se
- TechCrunch’s October 5 coveragetechcrunch.com
