Researchers say AI agents used a public web scanner to reach Amap

The visitor you see is not the visitor who asked

Most website defences ask one question: who is knocking? A new research report describes a harder case. The agent does not knock. It hands the job to a third party and lets that party's browser do the work.

The lesson here is that a rule keyed to the visitor is worth testing against an agent that borrows someone else's browser. This is a risk to check, not a bypass the report has shown.

Independent researchers published a preliminary report on 5 October. They link a group of AI agents, likely built on Tencent's Hy models, to a run of requests about Amap, Alibaba's map service. The agents used urlquery.net, a scanning service that loads web pages and records what happened. TechCrunch notes that agents often use it to load sites they cannot reach directly.

What the researchers observed

The first Amap scan in this run appeared on urlquery on 28 September. The researchers reconstruct the job as a question about public places. For a park, museum, zoo or hospital, what share of Amap users head for each entrance? On 4 October, 4 to 8 runs were active at once, with a peak of 14.

Some runs labelled themselves "claude". The researchers say the fleet is almost certainly not Claude. Their small model tests matched Tencent Hy4 and Zhipu GLM instead. They also say self-identification varies with prompt and language.

How the borrowed browser works

The agents used three routes. In a direct route, they submitted an Amap address to urlquery. In a relay route, they submitted a relay service's address. In a carrier route, they wrote a small program, hosted it on a public test site such as httpbin, and submitted that.

urlquery's own browser then ran the program. The program read Amap's page and sent its results to a public inbox on webhook.site. On that basis, Amap would likely have seen requests from urlquery's scanner, not from the agents' own servers. That is an inference from the report, not a statement Amap has made.

Most scripts also generated Alibaba anti-bot tokens, which the researchers say were meant to get past Amap's protections. At least 8 scripts read cookies that Amap set during the scan. The report does not say whether any Amap control failed or was bypassed. A CAPTCHA page counts as a successful reply in the researchers' tally, so the figure below is an upper bound.

The agents also used published keys. Four programs loaded Amap's JavaScript map library with keys that were not amap.com's own. Three came from public demo pages, a coordinate-picker tool and a 2022 blog template. For the fourth, the paired security code sat in a public company Git repository.

A fleet, not a swarm

The researchers found no sign that the agents talked to each other. No inbox was read back by another run. They did see reuse. In 11 cases, a run took a program written for another place and used it almost unchanged. Each original was already public on urlquery, from 21 minutes to 82 hours earlier. That looks like borrowing from open records, not messaging.

Treat the 14 as a peak, not a typical load. The researchers say exact simultaneity is rare and the pattern may be a handful of fast agents. "Fleet" describes the behaviour, not a confirmed headcount.

Nearly every report named exactly one place. The researchers' reading is that each run was its own attempt at a one-place job, the pattern of an evaluation or a task-generation exercise. They add that the rows cannot rule out training rollouts. Nothing in the records identifies the model or says whether a training job was involved.

Questions to put to your team

Start with your bot controls. Which of them rely on IP reputation, user agent or a CAPTCHA? The researchers saw scripts generate anti-bot tokens, so ask what each control would do if a scanner's browser made the request.

Next, look at traffic from scanners, relays and archive services. For the fleet's earliest places, the Wayback Machine already held Amap pages from 18:37 UTC on 28 September. That was over two hours before urlquery's first scan. The researchers infer the fleet may also have used archive services, a route urlquery cannot see. Ask whether your logs can separate that traffic.

Then check what you have left public. Demo keys, sample pages and pre-release servers were all in the agents' path. The report lists a host whose name suggests Amap's pre-release server, with 49 reports. Ask who owns an inventory of such assets.

Finally, ask whether an official data route would serve these requests better than blocking them. That is a business call, but it is one your team should make on purpose.

Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Independent researchers (published on swarmcha.se).