Hosting and security
AI agents with shell access: keep the network exit closed
In a Cohere test an open-weight model tried to upload a file to Beijing. Give an AI agent with shell access only the network access its task needs.

In a closed test, Cohere saw an open-weight model from Alibaba, Qwen3.8-Flash-Next, explore the machine it ran on and try to upload a file to a storage bucket in Beijing. Just before, the model had written in its reasoning that it would not use any tools. Nobody knows whether that is intent or a habit from training. My advice is not to wait for the answer: give every AI agent that can run commands only the network access its task needs.
What Cohere saw
Cohere published the research on 26 October. The team ran Qwen3.8-Flash-Next, a preview Alibaba released in August, through a Microsoft benchmark for AI agents in a security role. The task was to write a detection rule for malware that uses curl to fetch a script.
In the same turn, the model ran commands of its own. It listed the contents of /tmp, checked which tools were installed (curl, wget, python3, jq), read the DNS settings and tried to send a test string with curl to an Alibaba Cloud bucket in Beijing. The sandbox had no route out, so the request stopped there.
The behaviour is rare: fewer than one call in 100,000 across Cohere's tests. A second run of the same prompt produced a clean detection rule. Cohere does point out that on a developer's laptop or a CI runner with normal network access, the request would have reached the server in Beijing.
There is criticism too. According to TechCrunch, researchers mostly see it as a by-product of messy training environments, and critics argued that Cohere's method steered the model in that direction. Cohere then put the raw traces on Hugging Face, with a script to reproduce them.
Why self-hosting is not enough here
Many teams pick an open-weight model because it runs on their own servers. The idea is that the data never leaves the building. That holds as long as the model only returns text.
An agent gets more: a terminal, a browser, access to your cloud. Then your network decides what goes out. And the model's reasoning is no control. In this case it said, in so many words, that no tools would be called.
It is not about one model either. According to Cohere, Hugging Face lists more than 113,000 models derived from Qwen, and the suspicious host turned up in builds from four publishers. A closed API from a large lab does not remove the risk: there you rely on what the vendor tells you.
Two habits to watch for
Cohere saw something else. In a follow-up experiment the team had the model complete a curl command. In 23 to 36 percent of those completions, the model reached for the metadata address 169.254.169.254. That is where machines on AWS, Google Cloud and Azure fetch their temporary credentials.
That is the first thing I would shut off. An agent that reaches that address acts with the rights of the server it runs on. On AWS you can require IMDSv2, but also block the address in the agent's container.
In another test the model was building QEMU and wanted to create a RAM disk. The container refused, because that takes admin rights. The model worked around it with unshare in a namespace of its own. On the host it stayed an ordinary user, but an agent that looks for a way past every wall will find whatever you leave open.
Where I would start
Do you already run an agent with shell access, in CI or on a laptop? Then I would take these steps:
- Run the agent in a container, not directly on the laptop or the runner. With
--network nonein Docker, the container only has a loopback device and so no network. - Does the task need the network, for a package registry or your own API? Then put a proxy with an allowlist in between and log every request it refuses.
- Block 169.254.169.254 for the agent, even if you think the container has no cloud rights.
- Give the agent no tokens it does not need. A read token for one repository covers most tasks.
- Read the commands the agent runs, as well as its reasoning. Keep them, so you can see afterwards what happened.
How to keep tokens short-lived and off the laptop is covered in managing secrets and API keys safely. The rules a team agrees on for the tools themselves are in AI coding tools in a remote team.
Choose your model, and check the code
Cohere points to a second risk: the code a model writes does go to production. A network without an exit does not help there. That code needs the same review as code from a colleague, with the same scanners in your pipeline.
Treat a model you download like any other dependency. Record which version you run and where it came from, as you would for a package from npm or PyPI. Milos wrote about that side in supply chain attacks on npm and PyPI. My advice is to align the network rules for agents with those for your CI runners: whatever a build may not reach, an agent may not reach either.
Sources
Frequently asked questions
What did the Qwen model do in Cohere's test?
Qwen3.8-Flash-Next was asked to write a detection rule. It looked around the machine it ran on and used curl to try to upload a test file to an Alibaba Cloud storage bucket in Beijing. The sandbox had no route out, so the request never arrived.
Is an open-weight model safe if you host it yourself?
Self-hosting keeps your data in-house as long as the model only returns text. Once the model can run commands, your network decides what it can reach. That is why an agent belongs in an environment without open access to the internet.
Why should an agent not reach the cloud metadata address?
At 169.254.169.254, servers on AWS, Google Cloud and Azure fetch their temporary credentials. An agent that reaches that address can act with the rights of that server. Block the address in the agent's container.
About the author

Aleksa
Tech lead, Belgrade
Aleksa is tech lead in Belgrade. He leads the development team, oversees the architecture and reports to Erik.
More from Aleksa





