dsh Safety Guide: Sandboxes, Approvals & Secrets

How DeepSeek Harness keeps you safe: the three sandbox tiers, approval policies, guards and timeouts, and why your API keys never enter the session log. A plain-English guide.

Last updated: 2026-08-14

The threat model, in one sentence

Plugins are code that runs with the agent's permissions — and the agent can run commands, edit files and reach the network. The safety model exists so that a buggy or malicious plugin (or a model that gets talked into something) cannot do damage silently.

DeepSeek Harness approaches this with four layers: sandboxes, approvals, guards, and secret handling.

Sandboxes: three honest tiers

Every session runs inside a process sandbox. There are three tiers:

Tier	What it allows	When to use
`read-only`	The agent can read the workspace, but not modify it	Reviewing code, audits, anything you want zero-write
`workspace-write`	Read and write inside the workspace, no writes outside	Everyday development — the default shape of work
`danger-full-access`	The agent can touch anything the user account can	Deliberate, supervised system-level work only

Isolation is OS-native where available — bwrap/Landlock on Linux, Seatbelt on macOS, ACL restricted tokens on Windows. And the backend is honest: it reports whether it actually delivered the isolation it promised, so a tier that failed to apply is visible instead of silently pretending.

Approvals: ask before the risky stuff

Independent of the sandbox, risky operations go through the approval system: the agent pauses and you decide. What counts as risky is tuned by policy presets, so you can go from "ask about almost everything" to "only ask outside the sandbox" as a single setting.

The practical habit: start strict, relax once you've seen the agent behave. An approval prompt costs one click; an unsupervised write outside the workspace can cost an afternoon.

Guards and timeouts

Two automatic mechanisms catch runaway behavior:

Timeouts — a tool call that hangs gets interrupted instead of blocking the turn forever.
Loop detection — repetitive no-progress patterns (the same failing command over and over) trigger a guard that interrupts the cycle.

Plugins can add their own guards at the interception points around every tool execution and model request — that seam is documented in the plugin development guide.

Where your secrets go

Credentials (API keys, tokens) travel through a separate channel from the session log: the log records references, not values. That means a shared or exported session does not leak your keys.

Two more defaults worth knowing:

Session logs are not uploaded anywhere by default; telemetry is opt-in.
The model still sees what you paste into the chat — so don't paste secrets as message content, and prefer provider-side auth whenever a tool offers it.

A checklist for trying anything new

Start in read-only, then move to workspace-write once you trust what you see.
Read the plugin's source, license and permissions before installing — the install guide turns this into a routine.
Try new plugins in a disposable workspace, not your main project.
Watch the first approval prompts: they tell you exactly what the plugin is trying to do.
If something misbehaves, stop the session, remove the plugin entry, and report it to the repository.