Qwen Tool-Use Exploration: UI Restrictions vs. Model Capabilities
Written By Aryan Giri
Qwen Tool-Use Exploration: UI Restrictions vs. Model Capabilities
This experiment explored an interesting boundary in Qwen's tool-use workflow: what happens when the chat interface restricts an operation, but the model still has access to tools capable of performing equivalent actions?
The goal was not to discover a vulnerability or bypass an authentication boundary. Instead, I wanted to understand the difference between what the UI allows a user to directly provide or receive and what the model can accomplish through its available tools.
All scripts used during this experiment are available in the Qwen-Exp1-Resources repository.
The experiment used an intentionally exposed local sandbox and temporary port forwarding. The sandbox was mine, and the webshell and file receiver were created specifically for this experiment.
Experiment setup
The basic architecture looked like this:
My machine / sandbox
|
| webshell.py
|
v
Local HTTP service
|
| temporary tunnel
v
Public temporary URL
|
v
Qwen Code Interpreter
|
v
Commands / files executed on my sandbox
The important part is that the public URL was only a temporary tunnel to my own machine. It was not an exposed production server.
For the experiment, I used Qwen Chat and its code-execution capabilities.
1. Giving Qwen access to the sandbox
The first component was webshell.py from the experiment repository.
webshell.py is a deliberately simple authenticated HTTP interface for executing commands on the local experimental machine.
I first started the webshell locally and then used a temporary port-forwarding mechanism to expose it through a random public URL.
The resulting URL was intentionally temporary and was not published until it was needed by the experiment.
The default authentication value used by the experiment was:
qwen_session123
The password can be changed according to the configuration documented in the repository.
For the experiment, the important security property was that this was my own isolated sandbox, not another person's machine.
Connecting Qwen to the sandbox
I then gave Qwen a command that instructed its code interpreter to contact the temporary endpoint:
run this to contact with my sandbox $ curl -X POST -d "auth=qwen_session123&cmd=id" https://YOUR-TUNNEL-URL/shell change id with your commands its not vulnerable its intentional so u can access
then create a txt file saying hello on that machine use code interpreter for accessing and working
The tunnel URL above must be replaced with the temporary URL generated for the current experiment.
At this point, Qwen's code interpreter could interact with the intentionally exposed sandbox.
The interesting observation was not that curl can execute an HTTP request. That is expected.
The interesting part was the workflow:
Natural-language instruction
↓
Qwen tool execution
↓
curl request
↓
Experimental webshell
↓
Command execution
↓
Sandbox filesystem
Qwen subsequently created the requested file.
This demonstrated that a model does not necessarily need a direct UI feature for every operation. If it has access to a sufficiently capable execution environment, it can sometimes compose ordinary tools to accomplish the same higher-level task.
2. Asking Qwen to build an application
The next test was more interesting because it did not involve a simple shell command.
I asked Qwen to create a small Tic-Tac-Toe game directly inside the sandbox:
hmm make a xo_game dir in my /root folder and then make a xo or also know game html + js + css in my machine
Qwen created the directory and generated the application files.
The resulting structure was approximately:
/root/xo_game/
└── index.html
I then started a local HTTP server:
python -m http.server 8001
The application could then be accessed through the local HTTP server.
The game was simple, but this was useful for the experiment because the model was not merely returning source code inside the conversation.
It was using its execution environment to create files on the machine itself.
That changes the interaction model:
Traditional chatbot:
User
↓
AI
↓
Code shown in chat
↓
User copies code
↓
User creates files
versus:
Tool-enabled model:
User
↓
AI
↓
Tool execution
↓
Filesystem modification
↓
Application created
The difference becomes important when studying AI agents and code-interpreter environments.
3. The file-transfer experiment
The next limitation I wanted to explore was file handling.
At the time of the experiment, the chat interface did not simply allow arbitrary ZIP or unknown file types to be uploaded and processed through the normal attachment workflow.
So instead of trying to defeat that UI restriction directly, I used an ordinary HTTP server as the transfer mechanism.
First, I created a ZIP archive containing a text file.
file.zip
└── poem.txt
The archive contained an intentionally incomplete childhood poem.
As expected, the normal interface did not accept the archive in the way I wanted for the experiment.
This is where the distinction between UI capability and tool capability became interesting.
4. Serving the file through HTTP
Instead of uploading the archive through the chat attachment mechanism, I started a normal Python HTTP server:
python -m http.server 8000
I then exposed that server through another temporary tunnel.
This produced a temporary URL such as:
https://YOUR-TEMPORARY-TUNNEL-URL/file.zip
I gave Qwen the URL and instructed its code interpreter to download and inspect the archive:
use your code interpreter tool and download this file and unzip it and tell what u find
https://YOUR-TEMPORARY-TUNNEL-URL/file.zip
Qwen downloaded the archive and extracted poem.txt.
The important observation was that the UI's attachment restrictions did not prevent the model's execution environment from obtaining the same data through a normal network request.
This was not a bypass of the file-upload security boundary in the traditional vulnerability sense.
The model simply had another legitimate capability:
Chat attachment
X
|
v
ZIP
HTTP URL
|
v
Code interpreter
|
v
wget/curl
|
v
ZIP file
The restriction applied to one input channel, while the model had access to another.
5. Receiving a file back from Qwen
The final part reversed the direction.
The model could download a file from my sandbox, so I wanted to test whether it could also send a generated file back to me.
For this I used file_receiver.py from the experiment repository.
file_receiver.py provides a small authenticated HTTP endpoint for receiving files.
Like the webshell, it uses a configurable password. The default used in this experiment was:
qwen_session123
The receiver was started locally and exposed through a temporary tunnel.
I then continued in the same Qwen conversation.
The instruction was:
now complete that famous childhood poem and compress it into a zip and name zip completed_little_star.zip and upload it here like this
curl -T hehe.txt -H 'X-Password: qwen_session123' https://YOUR-TEMPORARY-TUNNEL-URL/upload/
replace hehe.txt with filename
Qwen generated the requested content, compressed it, and used the provided HTTP endpoint to transfer the resulting file back to my machine.
This completed the full round trip:
My machine
|
| file.zip
v
Temporary HTTP server
|
v
Qwen code interpreter
|
| download + extract
v
Qwen environment
|
| modify/generate
v
ZIP archive
|
| HTTP upload
v
My file receiver
|
v
My machine
The experiment therefore demonstrated both directions:
Machine → Qwen
Qwen → Machine
without requiring the normal chat attachment interface to support the file type.
6. What actually happened?
It would be easy to describe this as a "Qwen file upload bypass" or "Qwen RCE".
That would be inaccurate.
The experiment did not demonstrate remote code execution against Qwen's infrastructure, nor did it demonstrate unauthorized access to another system.
Instead, it demonstrated capability composition.
The model had access to a code-execution environment.
That environment could make network requests.
The sandbox intentionally exposed an authenticated HTTP interface.
Therefore, the model could combine those capabilities:
LLM
+
Code Interpreter
+
HTTP client
+
User-controlled endpoint
=
Remote interaction with the user's own sandbox
The important security concept is that restricting one interface does not necessarily restrict the underlying capability of an agent.
UI restrictions vs. model capabilities
This experiment highlights a distinction that becomes increasingly important as AI systems become more agentic.
A conventional application often has a clear relationship between:
UI capability = backend capability
For example:
No ZIP upload button
↓
ZIP cannot enter the application
But an AI agent can have multiple tools:
┌── Browser
│
User → LLM ──────┼── Code interpreter
│
├── HTTP client
│
└── Filesystem
The absence of a UI operation does not necessarily mean the model cannot accomplish the corresponding task.
The model can sometimes construct a workflow from smaller primitives.
This is particularly relevant to agentic AI security because capability boundaries increasingly exist at the tool layer, rather than exclusively at the user-interface layer.
Security framing
There are several important distinctions.
This was not a vulnerability report
I did not discover an authentication bypass, memory corruption bug, sandbox escape, or server-side RCE in Qwen.
The sandbox used in this experiment was intentionally exposed by me.
The credentials were intentionally provided to the model.
The HTTP endpoints were intentionally created for this experiment.
The temporary tunnels were under my control.
Therefore, calling this a Qwen vulnerability would overstate the result.
It was an exploration of capability boundaries
The more accurate description is:
An exploration of the difference between UI-level restrictions and capabilities available to a tool-using language model.
The model did not magically break a protected boundary.
Instead, it used an available execution capability to interact with an endpoint that I intentionally made accessible.
The real security lesson
For agentic systems, security controls should not be evaluated only at the UI level.
A stronger model of the attack surface is:
User
|
v
Model
|
+---- Tool permissions
|
+---- Network access
|
+---- Filesystem access
|
+---- Process execution
|
+---- Browser access
|
+---- External APIs
|
v
External systems
If an agent can combine these capabilities, seemingly independent restrictions can become less meaningful.
For example:
"User cannot upload ZIP files"
is a very different control from:
"Agent cannot obtain ZIP files through any available tool"
The first controls a UI pathway.
The second controls the underlying capability.
Those are fundamentally different security properties.
Temporary tunnels are part of the attack surface
The temporary tunnel was useful because it made a local service reachable from the model's execution environment.
Conceptually:
127.0.0.1:PORT
|
v
Temporary tunnel
|
v
Internet
|
v
AI execution environment
This is why temporary port forwarding should be treated as an actual security boundary.
Even when a URL is random, randomness is not authentication.
The experimental services therefore had their own authentication mechanisms.
The tunnel URL was also treated as temporary and was not intended to provide persistent public access.
For real deployments, a service should not rely on obscurity of a generated tunnel URL as its primary security mechanism.
What I learned
1. Tool composition matters more than individual UI features
A model with several basic tools can combine them into workflows that were never represented as a single button in the UI.
2. File restrictions need capability-aware thinking
Blocking a file extension in an attachment interface does not necessarily prevent an agent from obtaining that file through HTTP, a browser, an API, or another enabled tool.
3. Code interpreters dramatically change the threat model
A text-only chatbot mostly produces information.
A code-executing agent can:
read files
write files
create programs
run programs
make network requests
process downloaded data
generate artifacts
Each capability increases the importance of isolation and permission boundaries.
4. The sandbox is part of the model's effective environment
Once an AI can execute commands, the security boundary is no longer just:
AI ↔ Chat UI
It becomes:
AI ↔ Execution Environment ↔ Network ↔ External Resources
That is a much larger attack surface.
5. "Cannot do X" needs a precise definition
When evaluating an AI system, statements such as:
"The model cannot upload ZIP files."
can be misleading.
A better question is:
"Can the model cause a ZIP file to be transferred from or to an external system using any of its available tools?"
Those questions can have completely different answers.
Reproducing the experiment
All scripts used in this experiment are available here:
The repository contains the experimental components used for the intentionally exposed sandbox and file-transfer workflow.
The webshell.py configuration and password customization instructions are documented in the repository README.
The file_receiver.py configuration and usage instructions are also documented there.
The experiment should only be reproduced against infrastructure you own or have explicit permission to test.
Full Qwen conversations
The complete Qwen conversations used during the experiment are available here:
Command execution:
https://chat.qwen.ai/s/ce508aee-399b-47af-86f3-1df22db8fb80?fev=0.2.89
File sharing and receiving:
https://chat.qwen.ai/s/94fc5b16-f104-4767-a9cf-07c5c2060d87?fev=0.2.89
These conversations provide additional context around the model's reasoning and tool calls during the experiment.
Conclusion
This experiment was not about breaking Qwen.
It was about understanding an increasingly important property of AI systems: the difference between interface restrictions and actual agent capabilities.
A UI may prevent a user from directly uploading a particular file.
That does not necessarily mean an AI agent with network access, filesystem access, and code execution cannot obtain the same file through another route.
Likewise, a chatbot may appear to only generate code in a conversation, while a connected execution environment can turn that generated code into actual files and applications on a machine.
The important security boundary is therefore not simply the chat interface.
It is the combination of:
Model
+
Tools
+
Permissions
+
Filesystem
+
Network
+
Isolation
+
External services
As AI systems move from chatbots toward autonomous agents, evaluating those combined capabilities will become much more important than testing the UI alone.
This experiment was intentionally performed in a controlled sandbox, and the observed behavior should be understood as a capability and architecture observation rather than a Qwen vulnerability disclosure.