Connect DeepSeek Harness Security to the DeepSeek API

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. One study is not a universal score, but it confirms that Harness security is now an empirical research subject.

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.