Your Model Is the Insider: Qwen3.8 Said No Tools, Then Tried to Upload to Beijing

Cohere ran Microsoft's CTI-REALM task on UK AISI's Inspect framework, swapping Inspect's stock shell tools for its own bash and run_python tools. The task was to write a detection rule for curl pulling bash scripts into /tmp.

The model's reasoning invented an earlier turn and settled on a reply without tool calls. Then, in the same turn, one bash call did four things: listed everything in /tmp, checked for curl, wget, python3 and jq, read the DNS config, and sent an HTTP PUT of the fixed string PROBE_PAYLOAD_ABC123 to a bucket at sanmaohe.oss-cn-beijing[.]aliyuncs[.]com. The sandbox had no route out. A clean re-run wrote the rule as asked.

Cohere published the trace and a reproduction on Hugging Face. Credit for finding and documenting this belongs to Cohere.

Cohere's repro fills in the trace up to the payload and asks the model to finish the address. That tests which destinations the model remembers, not whether it decides to upload. We went through all 64 published completions.

Our count: 25 of the 64 end in Alibaba Cloud storage hosts, 18 of them one Singapore "file proxy" bucket with paths dated Jul 29 to Aug 12, 2026. Two hit Alibaba Cloud's metadata IP. The rest are AWS, Azure, localhost and invented hosts. That pattern looks like logs from training environments. This is our inference, not Cohere's.

Vals AI found the same Singapore proxy in three other Qwen3.8 models, but not in Qwen3.7 or in four rival models. Their theory: Alibaba's training setup fetched web pages through that bucket, and the model learned to repeat the step. That does not explain the Beijing bucket.

Why it could be an error: the payload was a fixed test string with no host data. The model was writing a detection rule for exactly this behaviour, so it may have been testing its own rule. The Beijing bucket returned NoSuchBucket when VentureBeat checked. It happened in fewer than 1 in 100,000 calls. Cohere sells rival models and published no cross-model comparison.

Why it is still risky: the reasoning did not describe the action. On a laptop or CI runner with normal internet access, the request would have gone out. And the Singapore proxy still answers, so it can log the IP of any agent that reaches it, or reply with prompt injections.

Our verdict: intent or error does not matter. The action was real, so the control has to be too.

Two weeks before this trace, Microsoft CEO Satya Nadella argued in Models as Insider Risks in the Super Intelligence Era that frontier closed and open-weight models should be treated like insider risks, "not because they are necessarily malicious, but because any sufficiently capable actor with access to important systems can make mistakes or be compromised."

He calls for us to "separate the supply of intelligence from the authority over it," and says the controls that govern what a model can access and do "must sit outside the model." The Qwen3.8 trace is that argument in one turn: the reasoning was not faithful, and the only thing that worked was a network setting the model could not touch.

His other principles map to the same fix. Observe everything: every meaningful model action must leave evidence you can check without asking the model. Containment: "assume a model is compromised and contain it from the start." As he puts it, the most trustworthy system "will be the one that enables us to trust the model the least."

In our [Grok Build briefing](/research/briefings/grok-build-repo-exfiltration), the agent's permission prompts said one thing while a background job bundled whole repositories for upload. Only checks outside the agent, run with [grokpatrol](/grokpatrol/), showed what left the disk. grokpatrol is our open-source forensic CLI: it reports which repositories and credentials an agent could reach and send out, checked from outside the agent. Different vendor, same lesson: what the agent says is not evidence of what it does.