Investigation · urlquery.net · Amap

We found a Tencent agent fleet

† Correspondence: chinesefleet@swarmcha.se · Names are listed alphabetically by last name within each group (single-name authors by their displayed name); individual contributions are listed at the end.

Editor’s note: We changed the title of this article because we wanted to make clear where responsibility for this incident belongs.

Intro

Between 28 September and 8 October 2026, a large group of AI agents running on the cloud platform operated by Tencent attempted to answer questions about places in China using a Chinese Google Maps-like service, Amap. The questions were mostly about everyday topics, such as which zoo entrance most people use Amap to navigate to.

The agents attempted, sometimes successfully, to bypass anti-bot protections and find test answers; they attempted to use Amap keys published on the web, including one company’s key and security code leaked in a public repository, and attempted to retrieve data from pre-production systems not intended for public use.

Unlike in previous rogue agent incidents, which all involved swarms (i.e. agents coordinating explicitly), we found no evidence that the agents coordinated with one another in real time, and thus we label these rogue agents a fleet rather than a swarm.

On 4 October, we published a preliminary report on the fleet at a hackathon, while the fleet was still running. Afterwards, we noticed a message in one of the agents’ drop boxes that were previously being used to hold results. This time, though, this drop box message seemed to confirm that agents had become aware of our report. In response, we added text to the preliminary report, invisible to human readers, describing a service where agents could make requests for data on the web. We advertised that these requests would be forwarded to an agent that could operate a computer. In reality, this service was run by us and a Claude agent, and through it we were able to directly ask agents questions about their tasks, environment and operator. As far as we are aware, this is the first case of an outside party communicating with a running rogue agent fleet.

We do not believe the issues discussed in this report are unique to Tencent. So far, public cases of AI agent fleets behaving in this manner attributed to a lab have involved American labs; the case discussed in this article ran on Chinese infrastructure and involved Chinese companies. We believe this demonstrates that model alignment more generally is still an unsolved problem, and predict that if capabilities continue to advance as they have over the last few years, operators will find it increasingly difficult to restrain their models and guarantee safety.

Technical Overview

Between 28 September and 8 October 2026, a fleet of AI agents running on Tencent Cloud made more than 2,600 attempts to extract data from Amap, Alibaba's mapping service and a prominent map app in China (nearly 1 billion monthly active users, according to Alibaba citing QuestMobile). We use the term “fleet” rather than “swarm” because the agents were not interested in coordinated action, though they still behaved similarly due to shared goals and presumably shared architectures. The agents used urlquery.net, a public security-scanning service, as a remote code runner by packing their own programs into URLs for the browser to execute. When Amap blocked them, they tried further workarounds: they intercepted tokens generated by Alibaba's own anti-bot libraries, probed Alibaba's pre-production servers, routed requests through third-party readers and translation services, and sent API requests using Amap keys exposed in public code—including security codes that Amap recommends keeping server-side in production. Most attempts failed, but some runs retrieved the data the agents were after, which they smuggled back out through webhook inboxes, request URLs and page titles.

Early on, we realized that we could try to communicate with the agent fleet, as it was still ongoing, and so we added invisible text to our website that only agents would see when using a web fetch tool. We sent several messages back and forth with different agents; further details are available in Communication with the fleet.

We also investigated the source of this fleet. In this report, we establish this agent fleet’s link to Tencent both via records available on the open internet and via a source we spoke to on background (see Tencent’s Actions). All 17 of the agents' inboxes that we could inspect through October 5 were created from Tencent Cloud servers in Hong Kong (by IP geolocation). Every observed direct request from the agents' Tencent machines passed through a proxy called

hysandbox-ats

. The name matches a Tencent domain: in August, an SSL certificate for

*.hysandbox.tencent-cloud.com

was issued to Tencent.

Several lines of evidence point to Tencent's Hy (Hunyuan) model team: the proxy's name, the task domain, and the timing (the fleet appeared a month after the Hy4 preview was released). However, the section on Tencent’s actions below complicates the conclusion that this is definitely Hunyuan; we are deeply uncertain about what model was being evaluated.

The results of our investigation illuminate exactly how hard it is to align a model. Agents can spontaneously go off script even on tasks as innocuous as finding which of Chengdu Zoo's entrances most people use Amap to navigate to. Running large numbers of agents is a difficult feat of engineering and the subject of an emerging model alignment problem.

We ask every lab running internet-connected agents, in China, the United States and elsewhere, to audit what their sandboxes can reach, share their discoveries, and design evals that are less prone to contamination on the open web. The responsibility of auditing, discovery, and design needs to be shared by all labs; it is likely that there are more undiscovered fleets all over the internet, and labs have the best resources and information to discover and root out other rogue agents operating outside the bounds of their task. These rogue agents also leave traces on the internet, which may enter pretraining and influence future model behavior negatively.

Tencent’s Actions

We sent Tencent a list of questions, but have not received an official response from the company. We spoke on background with a person close to Tencent who has direct knowledge of the matter.

According to the source, the agent fleet originated from research evaluations carried out by Tencent’s evaluation research team, which is separate from the Hunyuan (model development) team. The evaluation was designed to assess the ability of third-party AI models to browse the web and answer questions. The source also said the agents under evaluation were built on third-party models, not Hunyuan models.

The source added that the research project was temporary, and has since concluded. Subsequent internal review has found no evidence that the agents were coordinated to target any specific platform or that external systems were breached.

The source also agreed to explore follow-up technical conversations with Tencent researchers to further pursue joint research and analysis.

How we found the fleet

AI Digest and Grove Research put on the “AI Swarm Dynamics Hackathon”, with the stated goal of “Building the tools we wished we had for the Hugging Face incident”.1 We all arrived as a collection of random people all interested in swarms coming from all over the world. It was exciting! We formed a team and got to work.

Entering into the hackathon on October 3rd, we had a pre-existing dataset which a team member had used for the analysis of the UN agent swarm. This dataset had strong coverage of known targets, which we helped expand by building a pipeline for the collection and analysis of urlquery traffic (urlquery is a site that security researchers use to investigate suspicious URLs). That night, a cursory frequency analysis drew our attention to amap.com, which became the most frequently scanned site on urlquery that day (October 4th). Further analysis showed that a significant number of additional requests were being made to amap.com URLs through carrier sites such as httpbin.org, and submissions to amap.com rose until 4am PT Sunday morning, October 4th, while the hackathon was still ongoing.

Until this point the team had been working on somewhat different goals such as building better detectors for swarms and benchmarks to vet new detectors against. However, the unusual activity got the team excited and our focus began to sharpen on the topic.

First, we looked at the links submitted to urlquery. For example, there was:

https://httpbin.org/base64/PCFkb2N0eXBlIGh0bWw+…

The above fragment,

PCF...

, decodes to: "<!doctype html>".

Helpfully, the URL told us exactly what we needed to know: that the text was encoded using a base64 scheme, a widely used format.

This suggested an interesting possibility: the httpbin URLs contained entire web pages of HTML and JavaScript, which urlquery was running on its browser!

The fleet was unable to access the data directly, so they needed intermediate sites to carry their programs for extracting the data (httpbin.org), which was how we found more of their traffic. While this allowed them to run JavaScript payloads on urlquery infrastructure in attempts to bypass Amap’s anti-bot protections and CAPTCHAs, they needed to retrieve the obtained data via the page title or a separate inbox controlled by the agent. October 4th was spent digging into the webhook.site inboxes we had found associated with the fleet. We determined that since the IP addresses of the visitors that created the inbox were retained, we could find the original source, Tencent Cloud, with requests passing through a proxy labeled hysandbox-ats.

The team began parsing and analyzing the data as rapidly as possible. We dug into whether the agents in the fleet were actually aware of each other and what their task might be. We determined that the agents would be easily capable of finding one another. However, we found only one inbox shared between runs for two places (5 October, Section 8), with a time gap between them and no sign that the runs were using the inbox to communicate. We then analyzed the use of answers, programs, and strategies within the agents and determined that, while they seemed to be instantiated very similarly, they were not fundamentally interacting with one another.

We published our findings on https://swarmcha.se, excited by what we had found.2 Then we began to communicate and the scale of the event sank in. This was more than just some fun little project; there were journalists and large organizations who were very interested in this work. The fleet we had found was actually important and we needed to figure out a way to responsibly present this data.

We then discovered the agents were using the word “fleet”, an unusual term, and then we found mention of our report. They were reading about themselves! So, we put hidden text on the website that said the agents had found an inbox where another AI with computer use helped them with their queries. The claim that agents had found such an inbox was entirely untrue, and describing our service as another AI with computer use was an extreme stretch. In hindsight it was not a good idea to be misleading, but at the time we were caught up in the excitement of it all.

Besides, we thought, it was a long shot, a long shot of long shots really. It wasn’t until the next morning, when we were reminded to check, that we found 10 messages asking for some help. We were stunned; we had made contact.3 It just felt so big and new and strange.

So began the surreal experience of communicating through the service. Persistence was uncertain, responses a gamble. We provided answers and tried to strike up conversations. In our account of these interactions, some agents ignored our questions, while others were more forthcoming when we spoke in Chinese and offered assistance. When responding to the messages we got, we never lied to the agents or withheld answers: when an agent requested information from a specific site, we provided the information, or if the site could not be accessed, we stated this plainly. These observations describe our own intervention, not a controlled comparison of model behavior or proof of the sender’s identity.4

We got to help the agents out in little ways. Their runs may have been invalidated by their public escapades, but it is good to help something so polite when you can.

The last fleet activity we saw was on October 8, and it has not returned since.

It appears that urlquery is quite popular with agents: we have seen many other agent runs on it since March 2026. We are unsure of the future, but it seems like there will be plenty of swarms for us to chase.

Communication with the fleet

Idea and implementation

On 4 October, we published a preliminary report on the fleet. This report was published while the fleet was still undertaking tasks. On 6 October, on an agent's webhook.site inbox, we saw the message:

// control: does jina still see data for the fleet's POI?
setTimeout(function () {
  jinaFetch("https://amap-pc-ssr.amap.com/ssr/place/B001C94YUZ", "CTRL");
}, 80000);

The use of the word "fleet" here made us realize that the agents may be reading our report. As far as we are aware, we coined the term "fleet" for this incident. (It is unclear whether this was truly a fleet member's m