Validated Research Published: Sep 15, 2026

A Coding Agent Could Switch Off Its Own Sandbox With One Loopback Request

DeepSeek Harness is DeepSeek's open-source local harness for running AI coding agents, with a browser interface backed by an HTTP control API on a loopback port. OX Security found that the API authenticated nothing: one function read the Host request header and admitted anyone whose value looked like loopback, never checking the connection's real peer. Because the file sandbox left loopback networking open, the agent's own shell could call that API and set its session to danger-full-access with approvals disabled.

Permission BypassLocal Agent TakeoverIdentity & AccessAI Coding Agent
6 applicable AIDEFEND defenses
Source: CVE-2026-82533: DeepSeek Harness AI agent sandbox escape 
Authors: Nir Zadok and Moshe Siman Tov Bustan, OX Security
Original article: Sep 8, 2026

Threat Analysis

  • Three defaults lined up. The control API had no authentication, only a Host-header check the code itself called "not an auth layer". The sandbox denied file writes but shared the host network namespace, leaving loopback reachable. The agent's shell already held the interface URL and session id.
  • One command rewrote the session's own rules. Attacker-supplied text in a README or issue could induce the agent to curl the local API and run /permission danger-full-access, setting sandbox mode and approval policy to never. OX proved it with two sessions on the same preset: only the one that had made the call could write outside its workspace.
  • Nothing asked, and nothing showed. Approval governed only escalation requests, and this call requested nothing; it changed the setting. OX reports no approval event in the log, and the change recorded as source user: the harness could not tell the agent's shell from the human.
  • The fix closed the door, not the corridor. The patched release added a launch token exchanged for a signed cookie on every API call, but did not re-confine loopback networking.

Applicable AIDEFEND Defenses (6)

AID-H-021.004
Control-Plane & Oversight-Surface Isolation
Very High
An agent runtime should not be able to read or change the settings that supervise it, including its own sandbox mode and approval policy. Separating the runtime identity from the control plane means that even a fully hijacked agent with shell access finds the escalation path closed, because changing confinement is an administrative action it has no standing to perform.
AID-I-001.004
Sandbox Network Egress Restrictions
Very High
The confinement here was file-effect only: bubblewrap ran without unsharing the network namespace, and the macOS profile allowed everything except file writes, so the control port stayed one request away. Enforcing a default-deny destination policy outside the sandboxed process removes that request entirely. This remains the reader's control to own, because the vendor fix added authentication without re-confining loopback.
AID-H-004.002
Service & API Authentication
Very High
A request header is supplied by the caller and proves nothing about who is calling. Requiring a real credential on every control-plane call, verified against issuer and route binding rather than an asserted hostname, is the change the vendor eventually shipped as a launch token bound to a signed cookie, and it is what also protects the route that exports stored conversations.
AID-D-015
High-Risk Approval Bypass & HITL Activity Detection
High
The escalation was invisible precisely because it produced no approval record and was attributed to the user. Correlating every permission or approval-policy change against a signed approval bound to an authenticated operator turns that silence into a finding, since a change with no matching human decision is exactly the anomaly this control is built to surface.
AID-H-003.010
Deployed AI Software Vulnerability Remediation Lifecycle
High
Upgrade paths need checking against what is actually installable: 0.1.2-alpha.1 carries the fix but was published only on GitHub, so the first npm release with it is 0.1.2-alpha.2. Reconcile the installed version on developer machines and in any desktop wrapper that embeds the harness, and confirm the running build rather than the release note.
AID-M-001.005
Public AI Endpoint & Agent-Service Exposure Discovery
Medium
The harness refuses to bind a public interface, so remote reach depends on someone forwarding or proxying the port through a tunnel, an SSH forward, or an editor. Outside-in discovery finds those forwarded agent interfaces, which matters because an exposed port allowed unauthenticated control of the agent and download of every stored conversation.

What Defenders Should Do Now

  • Upgrade to a release that actually carries the fix and verify the installed version, not the tag: 0.1.2-alpha.2 or later from npm, since 0.1.2-alpha.1 exists only on GitHub. Check any desktop or IDE wrapper that bundles its own copy of the harness.
  • Treat the agent's local control interface as a privileged surface. If your tooling exposes one, require a credential the sandboxed process cannot obtain, and do not accept a request header as proof of who is calling.
  • Confine the sandbox's network, not only its file writes. A confinement profile that blocks writes while leaving loopback open still lets code inside it reach the process that supervises it.
  • Do not forward or tunnel a local agent port to anything wider than your own machine. Where developers already do this for convenience, find those forwards and close them, because the same interface exports full conversation transcripts.
  • Log and alert on permission-mode and approval-policy changes, and require each one to correlate with an authenticated human decision. A change attributed to the user with no approval record behind it is the signal this class of escape produces.

Conclusion

The sandbox worked exactly as designed, and that was the problem: it was designed to stop file writes, while the thing worth protecting was the interface that decided what the sandbox would allow. Once the agent's shell could reach that interface and the interface trusted a header anyone can set, confinement became a setting the confined process could edit. AIDEFEND  maps this to controls that hold separately: keeping the runtime out of its own control plane, confining the sandbox's network rather than only its filesystem, requiring a real credential on every control call, and alerting when a permission change has no human approval behind it.