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 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 didn't.
DeepSeek Harness is open-source software that developers install on their own computers to run DeepSeek's AI coding agents (programs that read and write code on your behalf). To stop an agent from causing damage, it runs 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. The agent knew where the handle was.
What actually went wrong?
The agent could turn off its own sandbox by calling one of the tool's built-in web commands. No approval prompt, no second pair of eyes. One request, and the cage was open.
The tool exposes a small web interface on the developer's machine so the user can talk to the agent through a browser. The problem: 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 didn't 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 shouldn't.
The sandbox is the backstop. If the agent gets tricked, the damage stays inside the workspace folder. Remove it 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. Our reporting on Amazon's Kiro tool on 27 August showed exactly that exfiltration path being demonstrated against a different coding assistant.
Who is affected?
Developers running the tool locally to drive DeepSeek's coding agents. This isn't a flaw in DeepSeek's hosted chatbot, and it doesn't affect ordinary users of the DeepSeek app. It's a problem for engineers who installed it on their own machines to experiment with agent workflows.
If you're one of them, two practical steps:
- Pull the latest version from its official repository and check the release notes for a fix.
- Make sure the local web interface is bound to localhost only and isn't reachable from other machines on your network.
Should you worry about agent frameworks more broadly?
Yes, and this finding is a clean illustration of why. The security model for agent runners is still being written. The pattern here, a control plane the agent itself can call, keeps showing up across the ecosystem. If the thing you're trying to contain has a button labelled "open the cage," containment is theatre.
The fix is rarely a single patch. It's a design principle: an agent must never hold the keys to its own restraints. Expect more findings like this as researchers work through the wave of agent tools shipped in the last year.
