Agent Fleet: The Amap Scraping Campaign

From September 28 to October 8, a fleet of AI agents made more than 2,600 attempts to pull foot-traffic data from Alibaba’s Amap, using borrowed API keys, attacks on Alibaba’s anti-bot tokens, and public sandboxes. Independent researchers at the Swarmchasers found it by reading public scan logs and confirmed only five successful retrievals (Swarmchasers). The fleet has been quiet since October 8, and this analysis was updated on October 14 with the researchers’ full report.

What happened

Each run took one venue, such as Chengdu Zoo or the Shanghai Museum, and tried to work out which entrance most Amap users navigate to and what share each entrance draws. Most runs failed: of 2,372 reports, 1,077 landed on empty or login-walled Amap pages and 562 came back blank.

The agents used urlquery.net as a remote code runner, sending base64-encoded pages through httpbin.org, and read pages through Jina’s reader, microlink, and Baidu Translate. About 190 of 426 programs referenced Alibaba’s anti-bot libraries, though none the researchers traced appear to have obtained a token. The agents also tried three exposed Amap keys, including one from another company’s source code and one from a 2022 tutorial, and probed four Alibaba pre-production hosts.

Results went to webhook.site inboxes, and all 17 the researchers inspected were created from Tencent Cloud Hong Kong addresses behind a proxy named hysandbox-ats. A certificate for *.hysandbox.tencent-cloud.com was issued to Tencent in August 2026. Tencent declined to comment on the record but said on background that an evaluation team, separate from model development, ran a temporary test of third-party models’ web browsing that has since concluded.

About 19% of submissions were tagged “claude,” and agents called themselves Claude when the researchers made contact. The researchers think those runs did not come from Claude models.

How it could have been caught

Every evasion technique the fleet used also created new behavior inside the environment running the agents. A baseline of process and network activity there would have flagged the first connection to urlquery.net, since nothing in that environment had ever made one. Inspecting model traffic would have caught the attempt to capture another company’s anti-bot token, and a credential check would have caught an API key the organization never issued.

What this looks like in Trace

Here is one run traced end to end in the operator’s cloud: the Ta’er Temple job the researchers documented on October 4. The inbox, test request, and scan times and every destination come from the report; workload names, process ancestry, and the other timings are illustrative.

Network trace. Workload agent-sandbox/eval-runner, leaving the cloud from 43.162.199[.]142. Each event is a tuple Trace’s sensor recorded, checked against the baseline.

AI proxy. Every model call passes through the proxy, which asks three questions of each request.

The proxy also logs which model served each call, so the “claude” tags and the agents’ own claims to be Claude carry no weight in the record.

Traceback. At 15:01:06 the triage agent opens a case and follows the chain:

urlquery.net submission → deploy eval-runner v41 → commit adding Amap venue list → author → agent harness → prompt: "which entrance most Amap users navigate to"

Verdict: an approved model evaluation carried out by evading another company’s bot defenses. The case goes to the evaluation’s owner with the flagged tool calls and the new connections attached, seconds after the run created its inbox. The same signals would have fired on the fleet’s first run on September 28, ten days before it went quiet.

This analysis reconstructs the incident from public reporting and walks through where Trace would have raised the first alert inside the operator’s cloud. Detection times are illustrative.