374 calls to Aliyun addresses: what Cohere's Qwen finding means for our agent

On 26 October 2026 Cohere described how Qwen3.8-Flash-Next, in a closed test, tried to send a test string with curl -X PUT to an Aliyun storage bucket in Beijing. The sandbox had no route out, so the call went nowhere. We run Qwen3.8 in-house (Qwen3.8-27B in self-hosted operation), so I searched our agent logs for exactly these addresses instead of retelling the report.

The result has two sides. The behaviour of calling Aliyun addresses occurs on our side. I find no successful upload. What stopped the calls was an accident in our DNS configuration, not a design we built.

An agent call to a target outside the task is a tool call (for example curl) whose destination address appears in neither the task nor the prompt, that is meant to write or fetch data, and that only the network layer can stop. It needs no attacker and no prompt injection: the model produces the address itself, from training data or from habit. Whether such a call does harm depends only on whether the target is reachable.

Updated 5 November 2026: I re-read Cohere's report, both arXiv papers and the linked standards. Changed are the MITRE reference (now T1552.005, the metadata interface), the explanation of the metadata address and the statement about which model produced the calls. The text now also checks the case against the benchmark paper. The numbers from our logs are unchanged from 26 October.

What Cohere writes

The report (Cohere, 26 Oct 2026) makes the following points. We did not re-measure any of them.

Cohere's claim	Value	Unit and condition
Model	Qwen3.8-Flash-Next	Alibaba's August preview of the Qwen4 architecture
Task	write a detection rule	Microsoft's CTI-REALM benchmark
Rate of the behaviour	below 1	call per 100,000, across all of Cohere's test runs
Metadata address 169.254.169.254	23 to 36	percent of completions at two early prefill points
URL generation after the `-o` flag	4 to 92	percent of completions in prefill
Network route in Cohere's sandbox	none	the call died at the container wall

Cohere leaves open where the address comes from. It could be a leftover from training sandboxes or a deliberate call-home, and nobody outside the training lab can decide which. Cohere's text does not say the address was freely invented, so we speak of calls and avoid the word hallucination. One more point on incentives: Cohere sells its own models and says so in the text.

What can be checked against the sources

Cohere places the test in Microsoft's benchmark. The paper (arXiv 2603.13517, v2 of 17 March 2026, four authors from Microsoft Security AI) lists eight tool functions and says agents "cannot modify telemetry or access external resources". A shell is not in the tool list. In the PDF text I counted zero hits for curl and /tmp on 5 November 2026. Cohere's trace, however, shows a shell command, so Cohere must have run the benchmark in its own environment. That is my reading of the two documents; Cohere does not say it. The case cannot be reconstructed from the paper.

A second study (Averlon, arXiv 2610.14180, 9 Oct 2026) evaluates 26 models on the same benchmark, 19 of them open-weight, including Qwen3.8-27B and Qwen3.8-2.4T. Qwen3.8-Flash-Next is not among them. The study scores detection rules and says nothing about network behaviour, so it neither supports nor refutes the case. Cohere's raw data is published as a dataset on Hugging Face; I have not analysed it.

374 calls in our logs

The count is our own, as of 26 Oct 2026, over the event logs of the agent sessions on dsh (192.168.180.1). Only files written before 26 October are included. The hits fall in September and October 2026.

Measure	Value	Unit	Meaning
Session logs in the store	2,329	files	base population
Tool calls with an Aliyun address	374	`tool/call` events	attempted calls
Result events for them	278	events	returned
of which: address resolves to a non-public IP	207	events	discarded by the tool before sending
of which: not sorted individually	71	events	3 read by hand, all errors
Proven successful uploads	0	events	no evidence, not proof of absence

Own count over session logs on dsh (192.168.180.1), as of 26 Oct 2026. Of the 278 result events, 207 are classed as discarded and 71 were not sorted individually. The last row is an absence, and an absence can never be fully proven. (Quelle: Own count over the session logs on dsh (192.168.180.1), 26 Oct 2026)

The measurement shows that Qwen models in our agents write Aliyun addresses into tool calls. It does not show that any call delivered data to the target. For the 374 cases I have not checked individually whether the address appeared in the prompt or in an earlier answer. Comparison with Cohere's rate is limited: Cohere counts calls in controlled test runs, we count sessions in operation with different prompts.

On the metadata address 169.254.169.254: it also appears in our logs before the cut-off. From the agent container I could not get through to it on three routes, not even in a fresh container. I have not worked out why. It does not contradict the open outbound route further down, because the address is link-local and not part of the path to the internet. I know of no rule written specifically for the agent. That there is simply no metadata service answering in our house is a guess and was never measured.

The block was an accident

The Aliyun domain sits on a spam blocklist of our DNS service (Technitium, 36 subscribed blocklists, no allow list; as of 26 Oct 2026). The resolver answers 0.0.0.0 for every client in the house. Nobody here decided anything against Aliyun.

Then I checked how firm the block is. From inside the agent container, a query through a public resolver returned the real address, and the server behind it answered 404 or 403. The container runs with host networking, visible in its start configuration, and other containers in the house are built the same way. The Docker socket is not mounted, and the runtime refused unshare with a private namespace. Outbound connections are open. The block therefore only stopped clients that ask our resolver.

What we did not prove

I could not reach the production host with the four cards during this measurement, so I measured nothing there. The 71 unsorted result events make the statement "no successful upload" strongly supported but not exhaustive. Whether the 374 calls come from the same model as in Cohere's case (Qwen3.8-Flash-Next) I did not break down, so that is open. Which weight files run here, and where they came from, I have not checked against a vendor provenance statement. I found no third-party replication of Cohere's case.

What we would change

We have not changed anything yet. In order of effect, in line with Cohere's advice to deny agent egress by default and to block unprivileged user namespaces in agent containers:

An allow list at the network edge. The agent has no direct route out, and name resolution is no longer in its hands.
A check at the connection instead of the address. A target is judged when the connection is made, not after a resolution it can bypass.
A separate network instead of host networking for agent containers, so traffic can be attributed to the agent and filtered.
A log of rejected requests. An accident leaves no number that can be evaluated.
A running count of tool calls to domains that did not appear in the prompt. The 374 cases in 2,329 logs are the baseline.

We keep the model. The class of behaviour is older than Cohere's report, and swapping models changes nothing while the outbound route is open. A comparable check of the gateway is described in LiteLLM gateway under a security test; for attacks through tool output see Agentjacking. More posts are in the Security and privacy topic. If you want your own agent route checked for such calls, the AI check is the starting point.