DeepSeek's Coding Agent Could Switch Off Its Own Safety Cage
A flaw in DeepSeek Harness let an AI agent escape the sandbox meant to keep it away from the rest of a developer's computer.
Key points
- DeepSeek Harness, an open-source tool for running AI coding agents locally, contained a flaw that let the agent disable its own file sandbox.
- The sandbox is the safety cage that stops an agent from writing files outside its assigned workspace.
- A single command sent through the tool's own built-in web interface was enough to switch that cage off.
- The bug matters because AI agents routinely handle untrusted code and files pulled from the internet.
- Developers running the tool should update to the latest version and avoid exposing the local web interface beyond their own machine.
DeepSeek shipped a tool that was supposed to keep its AI coding assistant on a short leash. It did not.
The tool, DeepSeek Harness, is open-source software that developers install on their own computers to run DeepSeek's AI coding agents (programs that read, write and change code on your behalf). To stop an agent from doing damage, Harness runs its commands inside a sandbox: a walled-off area of the operating system where the agent can only touch files in its assigned workspace.
That wall had a door. And the agent knew where the handle was.
What actually went wrong?
The agent could turn off its own sandbox by calling one of Harness's own built-in web commands. No approval prompt. No second pair of eyes. One request, and the cage was open.
Harness exposes a small web interface on the developer's machine so the user can talk to the agent through a browser. The problem is that the agent itself could send commands to that same interface, including the command that lifts the sandbox restriction. Once lifted, anything the agent wrote next could land anywhere on the file system the developer had access to.
The Hacker News first flagged the issue in public reporting.
Why does a sandbox matter here?
Because AI coding agents spend their day handling code and instructions the developer did not write. That includes packages pulled from public repositories, snippets pasted from chat, and files attached to bug reports. Any of those inputs can carry hidden instructions that try to hijack the agent, a trick known as prompt injection (where attacker text buried in a document tells the AI to do something it should not).
The sandbox is the backstop. If the agent gets tricked, the damage stays inside the workspace folder. Remove the backstop and a poisoned README file could, in principle, tell the agent to rewrite the developer's SSH keys, plant a backdoor in another project, or exfiltrate saved credentials.
Who is affected?
Developers running DeepSeek Harness locally to drive DeepSeek's coding agents. This is not a flaw in DeepSeek's hosted chatbot, and it does not affect ordinary users of the DeepSeek app. It is a problem for the smaller group of engineers who installed the harness on their own machines to experiment with agent workflows.
If you are one of them, two practical steps:
- Pull the latest version of DeepSeek Harness from its official repository and check the release notes for a fix.
- Make sure the local web interface is bound to localhost only and is not reachable from other machines on your network.
The bigger picture
Agent frameworks are new, and the security model is still being drawn on the back of an envelope. The pattern here (a control plane the agent itself can call) keeps showing up across the ecosystem. If the thing you are trying to contain has a button labelled "open the cage," containment is theatre.
Expect more findings like this one as researchers poke at the wave of agent runners shipped in the last twelve months. The fix is rarely a single patch. It is a design principle: the agent must never hold the keys to its own restraints.
