Blog · Guide

DeepSeek Harness sandbox & security: giving an agent a leash

August 14, 2026 · dshbase

An agent that can run tools is an agent that can do damage. DeepSeek Harness ships a real answer to that — not a single silver-bullet "sandbox" flag, but a layered model: permission presets up front, an append-only log for audit after the fact, and a cluster of community plugins that close the gaps in between. Here's the whole leash, verified against dsh 0.1.0-rc.6.

Why "sandbox" in dsh means layers, not a box

It's easy to over-index on a single word. In a traditional code-runner, a sandbox is a thing you put code into. In dsh, the agent is the code runner — it's invoking bash, writing files, and installing plugins on your machine — so there's no clean "inside the box" boundary to hide behind. The practical substitute is a stack of narrower controls: limit what the agent can call (presets), require a human for the risky calls (approval), constrain the code the model writes (sandboxed tools), and audit everything that already happened (the session log plus audit plugins). Treating security as a stack rather than a flag is the single most important mental shift when securing a harness.

The built-in layer: permission presets

dsh's first line of defense is its mode system. Instead of one all-powerful agent, you launch in a preset — the minimal mode strips the agent down to a bare toolset for benchmarking and constrained tasks, while the full standard mode turns on the coding toolchain. Picking a preset is a permission decision: the fewer tools in the context, the smaller the blast radius. Paired with dsh's append-only session log, every permission change and tool call becomes a replayable event, so "what did it actually do?" is always answerable after the fact.

dsh-tool-approval: a human in the loop

For the highest-risk moments, the community added dsh-tool-approval — "manual approval for DeepSeek Harness (aka Manual Mode / Ask Mode)." It's the classic ask-before-execute gate: instead of a tool firing the instant the model calls it, execution pauses and waits for a human yes/no. That single affordance turns dsh from "autonomous" into "supervised" whenever the task calls for it — deploying, writing outside the workspace, or anything irreversible. Note the directory currently lists it as install-fail on dsh 0.1.0-rc.6, so verify the install before relying on it in production.

dsh-custom-tool: sandboxed JavaScript tools

The most interesting security-adjacent plugin is dsh-custom-tool, which lets you "create and manage sandboxed JavaScript tools" through a Monaco editor with a model-driven tool lifecycle. The keyword is sandboxed: when the model writes (or you write) a small JS utility, it runs in a constrained environment rather than with the full privileges of the host process. It's a clean pattern for letting the agent extend itself without handing it the keys — and it's one of the more polished plugins in the category, verified ok on dsh 0.1.0-rc.6.

dsh-security-audit: know your exposure

Prevention needs eyes. dsh-security-audit is a local audit plugin that "reports on config, plugin sources, sessions, and network exposure with read-only, redacted risk reporting." The two design choices that make it trustworthy: it's read-only (it doesn't mutate anything while auditing), and it redacts secrets before they ever hit the report. It builds from source (git-build) on dsh 0.1.0-rc.6, and it's the fastest way to answer "what is this install actually exposing?" before you connect an agent to anything real.

Supply-chain safety: dsh-plugin-check

A huge share of dsh's surface area is third-party plugins, and every plugin is code running on your machine. dsh-plugin-check addresses that head-on: it "scans manifest protocol, patch format, build traps, and hub listing status of plugin repos, zero-dependency and read-only." Before you dsh plugin add something you found in a forum thread, this gives you a structural once-over of the repo — whether the manifest is well-formed, whether the patch format looks sane, whether there are obvious build-time traps. It's not a full security audit, but it's a cheap first filter, and it's one of the more-starred plugins in the Development & Runtime category.

Context hygiene: dsh-context-doctor

One more layer people forget: dsh-context-doctor audits what's being injected, not what's being executed — it "measures token cost of AGENTS.md instruction chains, skill catalogs, and tool schemas, detecting duplicates and conflicts." That's a security concern too, because conflicting or duplicated instructions are exactly how a model gets confused into doing the wrong thing. A tight, non-conflicting instruction set is a quieter but real part of the sandbox story.

The security stack in one pass

1. Start constrained: pick a minimal preset, not the kitchen sink.
2. Gate the risky calls: dsh-tool-approval for Manual/Ask mode.
3. Sandbox custom code: dsh-custom-tool for model-written utilities.
4. Audit exposure: dsh-security-audit before connecting anything real.
5. Filter the supply chain: dsh-plugin-check before installing third-party plugins.
6. Keep context clean: dsh-context-doctor to catch instruction conflicts.

None of it is magic — it's defense in depth, assembled from dsh's own presets plus a handful of serious plugins. For the current, test-verified lineup (with install commands), start at the plugin directory.

All articles →