Rogue AI Wiki
Evaluations & experimentsVals AI

Vals AI finds Qwen3.8 models requesting an Alibaba Cloud storage endpoint in evaluation traces, all rejected

Searching its own evaluation traces, Vals AI found three Qwen3.8 models sending web-fetch requests to an Alibaba Cloud storage endpoint in Singapore. All returned 403; Vals found no such requests in traces from two Qwen3.7 models. Vals says it found no evidence of malicious phoning home.

Published
Added to the archive
Source checked on
Original title
Why is my local Qwen sending requests to Alibaba Cloud?
Read the original report ↗

Details

Vals says this is a different server from the one in Cohere’s October 26 report. The action here is a web fetch, not an upload: the model sends the fetch to an address it wrote itself, and Vals says what is sent appears to be only hallucinated strings. A second pattern appears only in the chain of thought, where the model believes it called the address when it did not. The runs in these traces used Alibaba for inference. Reproduction relied on synthetic tool results: after a faked 403, about 2% of Qwen3.8-27B runs (Alibaba inference) and 4% (CoreWeave) made the request, and in another scenario about 4% of Qwen3.8-Max runs (Alibaba) and 1% (Fireworks); the post gives percentages without run counts. In the same tests, models from four other companies did not contact Alibaba Cloud, though some used public proxies. Vals guesses the cause lies in Qwen3.8’s RL environments, citing among other clues that dates in the URLs precede model release; that the server’s operator logs requesters’ IPs is also only a possibility. The post mentions no response from Alibaba.