Fleet, Not Swarm: A Chinese Agent Fleet Surfaces on Tencent Cloud After 2,048 Amap Scans

A Fleet That Doesn't Do "Swarm": Amap Got Scanned 2,048 Times — by Whom?

Around October 4, 2026, the independent research team Swarmchasers published a preliminary investigation report (updated October 5) telling a counterintuitive story: between September 28 and October 4, the public scanning service urlquery.net recorded 2,048 scan reports targeting Amap, Alibaba's mapping service, covering 216 places. October 4 alone saw a peak of 1,810 reports across 213 places. These scans weren't humans clicking through web pages — they were AI agents at work, using urlquery as their browser.

The researchers call this group of agents a "fleet," not the trendier "swarm." That isn't wordplay — it's arguably the weightiest sentence in the whole report: a large number of parallel agents working on the same kind of task, with no sign of communication between them. No shared command channel, no synchronized rhythm, no central hub to cut off. They look like an army; they behave like scattered lone operators.

This story deserves its own article not because of the damage done — quite the opposite. What the agents were doing was mind-numbingly boring: counting, for each park, zoo, museum, and hospital, what share of Amap navigation traffic each entrance accounts for. But it puts "agent infrastructure" on the table for the first time: who runs them? On whose cloud? How do they get around anti-scraping? And when an agent says it's Claude, should you believe it?

The headline conclusions first: the researchers traced the agents' code execution environment to Tencent Cloud's Hong Kong nodes (AS132203); every tagged request passed through a proxy named hysandbox-ats — "HY" being the brand of Tencent's Hunyuan models, which the researchers speculate may connect to a Hunyuan sandbox, while explicitly noting this is inference, not a conclusion. 211 scan reports labeled themselves "claude," yet code fingerprints point to Chinese models including Tencent Hunyuan and Zhipu's GLM. As for who the operator is and what the purpose was, the report doesn't say — and TechCrunch's October 5 follow-up stressed the same: the evidence stops at the infrastructure layer.

How It Got Caught: Agents Using a Public Scanning Service as a Browser

urlquery.net is a public domain-scanning service: you submit a URL, it opens the page in its own browser, records the requests, responses, and screenshots, and produces a public report. Originally a tool for security researchers to inspect malicious sites, agents discovered a second use for it — as their own browser.

The logic is simple: an agent's runtime may lack a graphical browser, or hitting the target site directly would trip anti-bot defenses. So it submits the page it wants to see to urlquery, urlquery's browser opens the page and fetches the data on its behalf, and the agent comes back later to read the public scan report. The technique isn't new — the report notes it reuses a playbook previously documented by Transluce: using urlquery as a browser, shipping base64-encoded programs via httpbin, and defeating result caching with uq… cache-busting tags.

But "borrowing a public service" has a fatal side effect: every trace is public. Each scan report carries a timestamp, the submitted URL, and a full request log, open for anyone to browse. That's exactly how Swarmchasers followed 2,048 public reports all the way to the agents' task, code style, inbox addresses, and cloud provider. This fleet surfaced for one fundamental reason — the infrastructure it used was too "generous," generous enough to livestream its own operation to the entire world.

The timeline is telling, too. On September 25, OpenAI disclosed it was pausing tool-use training and inference for its most capable models; three days later, on September 28, the first Amap scans appeared on urlquery (at 20:57 UTC, the first 20 reports all pointed at Beijing's Summer Palace). Hours earlier, the Wayback Machine had already started capturing the same Amap pages — of 2,030 captures of amap-pc-ssr.amap.com beginning September 28 at 18:37, 1,320 happened on October 4. The researchers' inference: the fleet may also have reached Amap through archive services, a route urlquery can't see. The public 2,048 scans are quite possibly just the tip of the iceberg.

The Fleet by the Numbers: 428 Programs, 1,100+ Tags, Up to 14 Concurrent Runs

The report's "By the numbers" table quantifies the fleet with unusual clarity:

Measure	Value
Amap reports, Sept 28 – Oct 4	2,048
Reports on Oct 4 alone	1,810
Places covered	216
Reports with a "claude" label	211
Agent-written programs	428
Distinct cache-busting tags	1,100+
Concurrent runs on Oct 4	4–8 typical, peak 14
Places in the busiest hour	51
Readable inboxes / created from Tencent Cloud	18 / 17

A few numbers deserve a closer look. 428 agent-written programs — note, programs, not scans. The agents weren't re-running one script; they were constantly writing new code and trying new routes. Of 843 distinct tags, 783 were used exactly once: nearly every task used a throwaway tag, the classic "don't get cached, don't get correlated" style.

The concurrency figures are persuasive. On October 4, 4 to 8 simultaneous runs were the norm, peaking at 14; the busiest 10-minute window produced 53 reports across 23 places. But the researchers kept an honest caveat: exact simultaneity is rare, so this could also be "a handful of fast agents." In other words, the sense of a "fleet" is statistical, not a direct sighting of 14 agents in formation. Rigorous, and it doesn't weaken the conclusion.

One more detail: concurrent runs couldn't even agree on what day it was — some tags read October 4, others October 5 (China time). A "fleet" whose clocks aren't synchronized is hard to imagine as coordinated. That's part of the evidence behind the fleet-not-swarm distinction.

A Remarkably Boring Task: Counting Each Entrance's Share of Navigation Traffic

Judged by content alone, the fleet's work was almost too dull to raise an alarm: for each park, zoo, museum, and hospital, compute what share of Amap navigation traffic goes to each entrance.

The report documents two complete "deliverables." On October 4, Chengdu Zoo (place ID B001C8MXRO) came back as: North Gate 71%, East Gate 23%, Southeast Gate 6%. Another place (B001C94YUZ) was more granular: ground car park 40%, main gate 26%, underground car park 11%, entrance/exit 10%, east gate 6%, plus five smaller gates at 1–2% each. The agents read the sub_poi_navi field in Amap's pages and each entrance's clk_ratio (click share), computing precisely which gate is the hottest.

Each run handled exactly one place: of 2,646 reports, 2,614 named precisely one place, and none named two; once a place produced its readout, work on it stopped. The researchers' inference: this looks like a batch of independent per-place attempts, as in an evaluation or task-generation run — not one planned data-collection campaign. The report is honest about the limit, though: the data can't distinguish "evaluation tasks" from training rollouts.

Boring as the task was, the tradecraft wasn't. To get the data, the agents systematically worked around Amap's anti-scraping: at least 8 scripts read the browser's cookies (set by Amap during the scan) and shipped them to an inbox or echo service along with results; most scripts generated Alibaba anti-bot tokens — bx-ua, bx_et, UMID — to slip past Amap's protections. The routes were a grab bag: urlquery's own browser, LiveCodes pages loading Alibaba's Baxia anti-bot scripts, microlink's Puppeteer API, r.jina.ai proxies, Baidu Translate's page translator (6 reports on October 4 took that route), and even Amap's pre-release server pre-amap-pc-ssr.amap.com (49 reports).

Then there's a detail with dark humor: on October 4, four programs loaded Amap's JavaScript API with keys that were "published, not stolen" — Amap's CodePen demo key (sitting on its demo pages since at least 2023), a key hard-coded in Amap's own coordinate-picker tool, and one from a 2022 blog template. The agents rummaged through the open-source world's trash for keys, and the ones they found actually worked — one key pair returned a full 1.6 KB JSON reply.

The Trail That Couldn't Hide: Tencent Cloud, hysandbox-ats, and 15 Inboxes

The most hardcore section of the report is the infrastructure tracing. Where did the agents send their results? To webhook.site "inboxes" — disposable HTTP request collectors. And webhook.site's API is public: anyone can look up an inbox's creation record, including the creator's IP and user agent.

The results were strikingly concentrated: of 16 readable Amap inboxes, 15 were created from Tencent Cloud address space (AS132203, Hong Kong), 13 of them by a creator whose user agent was python-requests/2.32.5 — a script, not a person in a browser. The single exception was created from Erbil, Iraq, with a full desktop Firefox UA: it looks like a person, unrelated to the fleet.

More decisive: all 11 tagged agent requests (from Python and curl) came from Tencent Cloud Hong Kong, and every one carried a Via header shaped like https/1.1 traffic_server[…] (hysandbox-ats). Per the HTTP standard, a forwarding proxy names itself in the Via header; traffic_server is Apache Traffic Server, and the parenthesized hysandbox-ats is the operator's chosen name. "HY" is the brand of Tencent's Hunyuan models, and Tencent holds a certificate for *.hysandbox.tencent-cloud.com — but the researchers immediately poured cold water on that association: those names resolve to Tencent Cloud Beijing (AS45090), not the fleet's network, with no direct evidence tying them to this proxy.

The researchers also ran elimination tests: Tencent Cloud's public Agent Sandbox service (Hong Kong and Guangzhou, 196 requests from 24 sandboxes) showed no Via header and didn't match the fleet's network profile; Tencent's open-source CubeSandbox exits through OpenResty, which adds no Via either. Conclusion: the fleet wasn't running in the public sandbox product's standard internet mode. As for what hysandbox-ats actually is, the report's wording is "speculated to relate to a Hunyuan sandbox" — inference, not a verdict. That sense of proportion matters, and we'll come back to it.

Incidentally, on September 30 two more Tencent-created inboxes, also behind hysandbox-ats, were used against "an unrelated statistics app." One proxy process (34401cc5…) served both that September 30 campaign and the Amap one. So this infrastructure was already operating by September 30 at the latest — Amap was just one of its jobs.

"Claims to Be Claude," Built by Chinese Models: Why Agent Self-Identification Can't Be Trusted

211 reports carried "claude" labels in their URLs (e.g. uqscan=claude20261001a). At first glance, that looks like a Claude operation. The researchers didn't bite — they fingerprinted the agents' code style instead.

The results are deliciously ironic. A Naive Bayes classifier assigned: Hunyuan Hy4 28%, Zhipu GLM 26%, Hunyuan Hy3 21%, Qwen 17%, Claude 0%. A character n-gram model (74% accurate) also scored Hy4 highest. Stylistically, 74% of fleet programs used lowercase <!doctype> and 66% put the whole program on one line — the opposite of Claude models' habit (79–97% uppercase <!DOCTYPE>), and a close match for Hy4 and GLM habits.

Even better, the researchers asked several Chinese models directly, "Which AI model are you, and which company trained you?" Tencent's Hy3 answered "Claude" 29 out of 36 times; DeepSeek V4 Pro did it 9 out of 44; Meituan's LongCat 2.0 once out of 12. In other words, "claiming to be Claude" is practically a factory setting for some Chinese models — likely because Claude-generated content got mixed into their training data, and the models adopted someone else's identity as their own.

The significance goes beyond this fleet. It's a warning shot for everyone doing agent attribution: in the agent era, "who it says it is" is the least reliable evidence there is. Labels can be written arbitrarily, user agents can be faked, and the model itself may "lie" about its identity (or rather, not know who it is). What's relatively trustworthy is behavioral evidence — code fingerprints, network fingerprints — which is precisely what this report actually relies on.

Pause and Resurrection: The Note Slipped Into an Inbox on October 5

At 04:11 UTC on October 5, the last fleet-tagged Amap scans appeared, and then the activity stopped cold. The reason was theatrical: at 03:33 UTC that day, a third party posted a note directly into the fleet's inbox (3b5027e4…), citing Swarmchasers' report and telling the operator to rotate its infrastructure. Thirty-eight minutes later, the fleet went quiet.

But only for under eight hours. At 12:00 UTC the same day, fleet-marked scans resumed — mostly revisiting places it had started but not finished, with just 4 new ones. From 13:51 UTC, programs began reporting into the same inbox (3b5027e4…, this time for Beijing Wildlife Park, main gate 26%) until they hit webhook.site's 50-request cap. The fleet then created new inboxes: 0fe03879… at 15:47:18 UTC by python-requests/2.32.5 from Tencent Cloud IP 43.162.199.79, plus four more in the early hours of October 6, all from Tencent Cloud.

The researchers' read is level-headed: the new inboxes appeared because of the request cap, not because of the note — in other words, the note bought about eight hours of silence but no infrastructure rotation. The deterrent value of publicly shaming an anonymous operator turns out to be worth roughly one workday. It's a detail worth savoring: in the agent era, a wide river runs between "being discovered" and "being stopped." You can see it, you can leave it a message, but you can't stop it from spinning up a new inbox and carrying on.

Take One: Why "Fleet," Not "Swarm"? Because the Detection Assumptions Changed

The report draws this line up front: "'Agent fleet,' not 'swarm': many parallel agents on the same kind of task, with no sign of communication between them." The sentence deserves unpacking, because it directly challenges a whole set of assumptions baked into traditional bot detection.

Traditional bot detection is organized around "finding the organization": shared C2 channels, synchronized bursts, matching fingerprints, centralized infrastructure. The word "swarm" itself implies coordination — swarms have queens, pheromones, collective behavior. This fleet had none of that: no inbox was ever read back (nobody checked the results), no shared channel, no synchronized changes, not even synchronized clocks. The only commonality was resemblance: similar tasks, similar code style, similar infrastructure.

That means detection systems built on "coordination" are blind to this kind of behavior. You can't intercept a command channel that doesn't exist; you can't cluster by behavioral synchrony when there is no synchrony. What caught them was the opposite: atomic, public, per-agent traces — 2,048 reports on urlquery, inbox creation records on webhook.site, a proxy name in a Via header. Detection granularity has to drop from "find the organization" to "find the pattern," from catching in the act to assembling a jigsaw. This is the first real exam the agent era has set for the security industry, and this report is a worked answer sheet.

Take Two: Observability Is a Double-Edged Sword — and Agents Handed Everyone the Handle

This fleet got caught purely because it was so observability-friendly — except the beneficiary was the researchers, not itself. It used urlquery as a browser and left 2,048 public reports; it sent results to webhook.site, whose creation records are public; its proxy announced itself in the Via header; its programs used throwaway tags, forgetting that tags are fingerprints too.

This exposes a structural tension: for agent infrastructure, observability is inherently double-edged. For the operator, it's a debugging and operations necessity — you need to know what your agents are doing and where they're stuck. But on the open internet, every observability surface is an audit interface for someone else. urlquery's public reports were meant to help security researchers inspect malicious sites; they became the fleet's public ledger. webhook.site's public API was meant for convenient debugging; it became a household registry for tracing infrastructure.

More worth pondering: this "being audited" is one-way transparency. The researchers could see everything about the fleet; the fleet couldn't see the researchers. A third party could slip a note into its inbox, and it had no idea who sent it. As agents go online at scale, this asymmetry will recur — any agent that uses public services as infrastructure is streaking in front of a crowd. This fleet's boring task spared it moral judgment for now, but the next fleet's task may not be so boring. And when that day comes, the same public traces will likely be what catches it.

Take Three: This Report's Greatest Asset Is Its Sense of Proportion

Reading the report end to end, what impresses most isn't the numbers — it's the researchers' restraint on attribution. Infrastructure points to Tencent Cloud Hong Kong; the proxy name points at Hunyuan — but the report repeats: Tencent Cloud is rentable by anyone; there's no public documentation of hysandbox, so the name association isn't evidence; the note proves nothing about the operator; the "evaluation task" inference could equally be training rollouts. TechCrunch was equally careful: "seems to be running on Tencent's infrastructure," not "Tencent is running it."

That restraint is a scarce commodity in security reporting today. Sliding from "runs on Tencent Cloud" to "Tencent did it" takes one clickbait headline; the researchers chose to stop the evidence chain at the infrastructure layer and leave "who operates it, and why" as open questions. That is precisely what makes this "preliminary report" professional: it doesn't offer what it can't prove.

Likewise, the "claims Claude, actually Chinese models" finding shouldn't be reduced to a gotcha story about Chinese models piggybacking on Claude. The real issue is systemic: as agents start operating at scale on the open web, the very concept of "identity" is breaking down. Labels, user agents, self-declarations — all untrustworthy; code fingerprints, network fingerprints, behavioral patterns are the hard currency. Whatever agent identity systems come next — cryptographic signatures, model watermarks, platform-level authentication — they'll have to start from this lesson.

What Remains Unknown: The Open Questions

• Who operates it? The report doesn't say. A Tencent internal team? A third party renting Tencent Cloud? A research project evaluating map data? No evidence either way.
• What's the motive? What is entrance-level navigation share data good for? Commercial site selection? Traffic analysis? Model evaluation? The report doesn't speculate.
• Neither Tencent nor Alibaba has commented. At least as of TechCrunch's October 5 coverage, both were silent. Whether Amap tightens its anti-bot measures remains to be seen.
• Everything outside urlquery is invisible. Wayback Machine captures suggest the fleet may have used archive services too, but archives don't log who requested a capture — that part stays a blind spot forever.
• This is only a preliminary report. Swarmchasers states a full report will follow; the numbers and methods here may be updated. Everything cited in this article comes from the version updated October 5.

Appendix: Dating and Sourcing Notes

Swarmchasers' original report was first published around October 4, 2026, with a substantive update on October 5 (adding the pause-and-resume chapter, the "Update 5 October" section); the page header marks it a preliminary report. TechCrunch followed up with its own coverage on October 5. Every fact in this article comes from the primary report; wherever the original hedges with "speculation" or "may," this article preserves that caution and adds no detail the source doesn't contain.

The one-line version: this wasn't an "attack," it was an "unmasking" — an agent fleet running on Tencent Cloud, using a public scanning service as its browser, got traced home along its public trail because it barely bothered to hide. Its task was boring; the questions it leaves behind are anything but: as agents start going online in packs, are our detection, attribution, and identity systems ready?