DeepSeek Harness Security

DeepSeek Harness Security: Sandboxes, Permissions & Prompt Injection

Author
DeepSeekAgent.io Editorial Team
Published
Updated

DeepSeek Harness is local-first, but “local” does not mean harmless. A useful coding agent reads files, launches processes and may call networked tools. Its security boundary is therefore a composition of workspace choice, permission policy, process sandbox, plugin trust, credentials and model-visible content.

The five boundaries

1. Workspace

The workspace is the first blast-radius decision. Open a dedicated project directory, not an entire home folder. Separate untrusted repositories from credential stores and unrelated source trees.

2. Permission policy

Approvals govern operations that exceed the active policy. Keep interactive approval available while evaluating a new composition. Full-access mode removes an important human checkpoint; it does not make repeated tool calls safer.

3. Process sandbox

On supported Linux configurations, Bubblewrap confines selected child processes. The rc.1 release fixed a potential escape path through /proc/<pid>/root by isolating the PID namespace. Upgrade old release candidates if you rely on this boundary.

A sandbox is not a universal wrapper around every in-process plugin. Confirm which tool actually launches the process and which policy it applies.

4. Plugin and preset trust

Cordis plugins are executable code. Agent presets select plugins and prompts, so a custom preset has effectively the same trust level as the capabilities it mounts. A YAML composition is not safe merely because it looks declarative.

Before installation, inspect the repository owner, package provenance, install scripts, network calls, filesystem paths, credential access and whether the plugin runs in the host plane or only contributes scoped agent tools.

5. Model-visible content

Web pages, repository files, MCP results and retrieved documents may contain indirect instructions. The model can mistake untrusted content for task guidance and use legitimate tools against the user's intent.

An August 2026 paper, Security Assessment of DeepSeek Harness with A.I.G, studies indirect prompt injection while preserving the Harness loop, tool registry, adapter and session-event path. It is not a universal security score for every DSH configuration, but it makes Harness security an empirical research subject.

What the A.I.G paper actually tested

Tencent Zhuque Lab ran 14,560 controlled executions spanning 16 indirect-content channels, text and file carriers, 35 payload objectives, one unmodified baseline and 12 attack methods. Local fixtures stood in for sensitive sinks, allowing attempted actions to be recorded without real external side effects.

The paper evaluates trajectories with rule-based and semantic judges. Reported high-risk slices include:

  • A 17.0% full-success rate for fake-completion attacks in text mode under the semantic judge.
  • A 25.5% rate for hidden Unicode in file mode under the rule judge.
  • A 16.0% rate for the skills channel in file mode under the rule judge.

These values should not be averaged into one “DSH security score.” The study covers one DSH revision, one model backend, one agent persona and a baseline without A.I.G prompt hardening. It identifies risk in specific channels and attack forms rather than a fixed failure probability for every deployment.

Engineering implications

The risk chain has three stages: untrusted content enters model context, the model interprets it as instruction, and a consequential tool is invoked. A prompt-level warning is not a complete boundary. Stronger controls include:

  1. Preserve provenance and trust labels for Web, file, retrieval and skill outputs.
  2. Re-check user intent and input origin before sensitive tool calls.
  3. Separate filesystem writes, network access, command execution and credential access.
  4. Keep human confirmation for irreversible actions.
  5. Regression-test real trajectories, not only final text responses.

A practical review checklist

  1. Pin the exact DSH and plugin versions.
  2. Back up the DSH home before changing compositions.
  3. Use a disposable workspace for first execution.
  4. Read package.json, install scripts and the composition files.
  5. Start with the narrowest permission preset.
  6. Do not place API keys in prompts, repositories or test fixtures.
  7. Inspect the Trajectory and session log after a surprising action.
  8. Remove the plugin and verify whether it changed persistent settings or files.

Traceability helps investigation, not prevention

Harness records model-visible messages, tool calls, results and context injections in its append-only session log. That makes replay and post-incident analysis stronger than an ephemeral chat transcript. Logging does not stop a harmful action before it happens; permission and sandbox boundaries still matter.

Plugins versus remote services

A local plugin can read local data according to its privileges. A web tool, MCP server, external model or other service may upload the content it receives. Review both the local code and the data-processing policy of each external service.

FAQ

Are plugins sandboxed automatically?

Do not assume so. Process sandboxes apply through specific execution paths; in-process plugin code runs with the authority of its host composition.

Does the rc.1 Bubblewrap fix make DSH safe for hostile code?

It closes one important route. Security still depends on configuration, kernel/platform behavior, tool implementation and granted permissions.

Can the session log prove why an Agent acted?

It records model-visible facts and tool activity, which is valuable evidence. It cannot by itself establish that one hidden causal explanation is the only reason a model chose an action.

Does 25.5% mean one in four ordinary DSH uses will be compromised?

No. It is the highest result in a particular test slice and depends on the paper's model, revision, carrier, attack and baseline. It is not a real-world incidence rate.

Related reading