Security & Compliance

This page explains data flows, security baselines, supply-chain and compliance boundaries when using DeepSeek Harness. The harness is in the developer preview stage; this page is compiled from public information in the upstream repository and is not an official security commitment.

The capability surface is the attack surface

The harness agent can read and write files, run shell commands, keep persistent terminals, access the network, delegate to subagents, and even modify its own runtime through dynamic plugins. For developers these are capabilities; for security teams they mean a prompt injection can escalate from "a wrong answer" to "a real side effect" — modifying files, running commands, reading credentials, accessing the network.

The official codebase already includes protective components: permission/approval, filesystem policy, sandbox, and Linux Landlock support. For the independent-audit status of these mechanisms, see "Vulnerability disclosure status" below.

"Runs locally" does not mean "data stays local"

The Web UI binds to 127.0.0.1 by default, which means the interface is local; model requests still go to the model provider you configure in settings. So when reviewing data paths, the subject is the whole chain:

Reviewing only the dsh source while ignoring the model API data path is a common evaluation mistake. Before using any hosted API, read that provider's privacy policy and terms of service, and confirm whether your code, logs and data are allowed on that path; for personal information, complete the compliance assessment required by your jurisdiction.

Deployment forms and risk tiers

The plugin architecture (model, sandbox and approvals are all replaceable) makes the latter two forms architecturally feasible; this does not mean an officially certified, complete self-hosted solution exists.

Enterprise security baseline

For production or otherwise important environments, aim for at least:

• Approvals: sensitive commands (write, delete, execute, network) must be human-approved; keep the permission preset that asks;
• Workspace allowlist: select only the necessary directories as the workspace — the narrower the boundary, the safer;
• Least-privilege credentials: package managers, Git, and cloud credentials are isolated from the agent runtime, never sharing one high-privilege identity;
• Disposable environments: run the agent runtime in destroyable containers/VMs, recycled after each task;
• Audit: keep session logs and tool execution records; anything the model sees should be reconstructable from the logs;
• Network and self-modification: disable or restrict external network access and dynamic-plugin self-modification by default; enable them only as needed.

Supply chain and license boundaries

• The MIT license covers the harness source code only; model weights, third-party plugins, copyright of generated code and API service terms are separate questions;
• Plugins are a new supply-chain boundary: before installing third-party plugins, verify the repository organization and the @deepseek-ai npm scope, and prefer plugins with traceable origins under the dsh-plugin topic;
• Enterprises should generate an SBOM and review the dependency tree and THIRD_PARTY_NOTICES before adoption;
• The project is in the developer preview stage and officially expects breaking changes; pin exact versions in production and prepare upgrade and rollback plans.

Vulnerability disclosure status

As of August 2026, no public CVE, GHSA or independent third-party security audit specific to DeepSeek Harness was found.

Related pages

• For concrete problems, start with troubleshooting.
• For the ecosystem and comparisons, see ecosystem.
• For feedback and reporting channels, see community & support.