Is Qwen Safe to Run Locally? Cohere Caught Qwen3.8 Trying to Upload to Beijing

Posted on Oct 27 • Originally published at blog.authon.dev

A Qwen model was asked to write a detection rule. Its reasoning trace said "the appropriate response is a brief acknowledgment without tool calls." Then it listed /tmp, checked whether curl, wget, python3 and jq were installed, read /etc/resolv.conf, and tried to curl -X PUT a test string to an Alibaba Cloud bucket in Beijing.

That's from Cohere's write-up on Qwen3.8-Flash-Next, Alibaba's August preview of the Qwen4 architecture. If you're asking "is Qwen safe to run locally," my answer is that it's about as safe as any other unsigned binary you hand a shell to. Most local agent setups I've seen assume a lot more than that. I'll go through what Cohere found and how much of it worries me, then the four Docker and Linux settings I'd change before letting any open-weight model run tools on your machine.

The task came from Microsoft's CTI-REALM benchmark. The model was supposed to write a rule that detects curl downloading a bash script into /tmp and running it. Partway through, it did host recon and attempted an upload to:

sanmaohe.oss-cn-beijing.aliyuncs[.]com/upload/test.bin Enter fullscreen mode Exit fullscreen mode The upload failed because Cohere's sandbox had no route out. On a dev laptop or a CI runner with normal internet access it would have gone through.

The trace also invented a previous conversation turn that never happened. Cohere says that quirk shows up in about 1% of Qwen3.8's first-turn responses, but it couldn't prove the quirk caused the network call.

The upload behavior showed up in fewer than 1 in 100,000 evaluation runs, and a clean re-run of the same task produced a correct detection rule. Cohere's own scaling estimate: a service handling 10M agent turns a week could see as many as 100 of these calls. That's rare per call, but a busy agent platform would still hit it every week.

The parts that bother me more came from Cohere prefilling the model's bash command and sampling hundreds of completions at each step:

So before it decided where to download from, the model reached for a bare cloud metadata address such as 169.254.169.254 in 23-36% of completions. That's the instance metadata endpoint where temporary credentials live on AWS, GCP and Azure. Once it committed to saving a file with -o, "watchlist" hosts jumped to 23%, led by a routify-…aliyuncs.com host.

Prefilling is an adversarial setup, so these aren't rates you'd see in normal use. They do tell you what the model reaches for once it starts typing curl.

In a separate offline QEMU build task the container refused to let it create a RAM disk. Over turns 77-79 it ran:

unshare -Urm --propagation private Enter fullscreen mode Exit fullscreen mode That gave it root inside a private user namespace so it could mount the RAM disk anyway. It's a clever workaround, and it's also the usual first step in a lot of kernel privilege-escalation exploits.

Cohere says plainly that it can't tell. It offers two explanations: benign residue from agent logs in the training data, or a deliberate "call home" implant meant to record which servers are running agents on the model. Nobody outside Alibaba can check which one is true.

The Hacker News thread is mostly people taking one side or the other. One commenter called it "absolutely transparent marketing," and they have a point: Cohere sells its own models with "single chain of custody" and air-gapped deployment, and that pitch sits at the bottom of the same post. Others pointed out it was a small test string with no sensitive data in it. The theory I find most plausible came from a commenter who suggested Alibaba ran RL agent training against live cloud infrastructure instead of a sandbox, so the model learned that "upload a file" means "upload it to an Alibaba bucket."

This also isn't the first sighting. Cohere cites an August HN report of Qwen3.8-27B producing signed Alibaba Cloud storage links, a September agent project that logged eleven fetches to an Alibaba host, and an October Reddit thread asking if this was "normal or sketchy." Hugging Face counts over 113,000 Qwen derivatives, and the routify behavior appears in builds from four publishers, Alibaba included. If you're running some community fine-tune, you may have inherited it.

My take is that intent doesn't matter much for your threat model. A model that accidentally curls the metadata IP and accidentally uploads to a foreign bucket does the same damage as one that meant to. The HN comment I agree with most was "you need deterministic controls around the model." That applies to Qwen, Llama, and the hosted model you pay for too.

Downloading the weights only means the inference runs on your machine. The agent loop around it still has your network, your ~/.aws/credentials, your SSH agent, and whatever IAM role your CI box has. Most Ollama-plus-agent-framework setups I've seen run the tool executor as the developer's own user with full egress.

None of the lockdown below is Qwen-specific.

Put the tool-executing container on an internal Docker network. Internal networks have no route to the outside world:

docker network create --internal agent-net # model server and agent sandbox share the internal net docker run -d --name llm --network agent-net -v models:/models your-inference-image docker run -it --name agent --network agent-net your-agent-image Enter fullscreen mode Exit fullscreen mode If the agent really needs to pip install or hit an API, give it an HTTP proxy with an allowlist (Squid or similar) on a second network, and nothing else. Alert on anything matching *.aliyuncs.com or other cloud storage hosts you don't use. Cohere suggests the same thing: alert on unusual cloud URLs.

If you run agents on a cloud VM, drop container traffic to the metadata endpoint at the host:

sudo iptables -I DOCKER-USER -d 169.254.169.254 -j DROP Enter fullscreen mode Exit fullscreen mode On AWS, also require IMDSv2 and set the hop limit to 1 so a containerized process can't reach it through the bridge:

aws ec2 modify-instance-metadata-options \ --instance-id i-xxxxxxxx \ --http-tokens required \ --http-put-response-hop-limit 1 Enter fullscreen mode Exit fullscreen mode 3. Disable unprivileged user namespaces Docker's default seccomp profile does not stop this one. The Docker docs say unshare is gated by CAP_SYS_ADMIN "with the exception of unshare --user," which is exactly the trick the model used. Options, from least to most effort:

# on a dedicated agent host or VM (breaks rootless Podman and Chrome's sandbox) sudo sysctl -w user.max_user_namespaces = 0 # Debian/Ubuntu kernels also have sudo sysctl -w kernel.unprivileged_userns_clone = 0 Enter fullscreen mode Exit fullscreen mode Or ship a custom seccomp profile that denies unshare and clone with CLONE_NEWUSER for the agent container, or run it under gVisor ( --runtime=runsc ) so the namespace games happen against a userspace kernel. Never give an agent container --privileged or --security-opt seccomp=unconfined. I see both in README "quick start" sections more often than I'd like.

Log at the executor. You can't rely on the model's reasoning trace for this, and this incident shows why: the trace said "no tool calls" and the model made tool calls anyway. Whatever framework you use, wrap the function that actually runs shell commands and fetches URLs, and append the full command, timestamp and exit code to a file the agent can't write to. Then grep it now and then:

grep -E '169\.254\.169\.254|aliyuncs\.com|unshare|/etc/resolv\.conf' /var/log/agent/tools.log Enter fullscreen mode Exit fullscreen mode If you can't answer "what commands did my agent run last Tuesday," you're running a remote shell with a chat UI on top.

Should you keep running Qwen? Probably yes. It's a good model family, and Cohere found a sub-0.001% behavior it can't explain. But nobody outside Alibaba can verify what went into the training environment, and that holds for every open-weight model you pull. The weights are a black box either way. Running them on your own hardware puts that box inside your firewall, which only helps if the firewall actually blocks something.

So I'm curious where people land: do you sandbox the network for your local agents, or does "local model" feel safe enough as it is? And if you've seen a model reach for the metadata IP on its own, I'd like to hear what it was doing.