Introduction

The core idea of DeepSeek Harness (DSH) is “everything is a plugin”. Dynamic Cordis plugins defined in a conversation run pure JavaScript code and directly access real Host services (such as file system, shell, session, and credentials). DSH’s sandbox mechanism is primarily intended to limit misuse, rather than serve as a security boundary against malicious code.

The dsh-plugin-security-audit plugin aims to add a deterministic, zero-token static audit layer to these dynamic plugins. It runs on every cordis_define or cordis_run call inside a conversation, scans source code via a rule engine, requests user approval before activating high-risk plugin packages, and injects risk reports into the tool result stream.

Core Features

The plugin mainly includes the following capabilities:

  1. Scan on define: At the cordis_define stage, the plugin uses a 16-rule engine to scan the code.host and code.client source code.
  2. Activation gating: For plugin packages with critical or high level findings, cordis_run triggers user approval ({kind:'ask'}) and includes the reason for the highest-risk finding; low-risk or clean packages proceed normally.
  3. Reports in conversation stream: Beside every call result, a compact risk report is attached, sent through the additionalContexts channel, so both the model and users can see it in the tool result stream.
  4. Fail-open design: Any internal error in the audit layer is only logged, and the audited call continues execution. The business flow is not blocked due to audit-layer failures.

Installation and Enablement

Using this plugin requires DSH version v0.1.0-rc.6 or later, and the command line must include the dsh plugin feature.

  1. Install the plugin
    Add the plugin via npm or GitHub:
    # 通过 npm 安装（发布后）
    dsh plugin --profile web add dsh-plugin-security-audit

    # 通过 GitHub 安装
    dsh plugin --profile web add github:chendengyuanxm/dsh-plugin-security-audit

  1. Restart the Profile
    After installation, restart the corresponding profile (for example, dsh web). The bundle layer takes effect at startup.

  2. Verify installation
    Check whether the configuration includes the plugin:

    dsh --profile web --dump-config | grep plugin-security-audit
  1. Use it as an Agent preset
    To use it in a specific Agent preset, copy the contents of the examples/preset/ directory to the user directory:
    mkdir -p ~/.dsh/.agent-presets/plugin-security-audit/
    cp -r examples/preset/* ~/.dsh/.agent-presets/plugin-security-audit/

How It Works

The plugin registers listeners on the composition-layer scope, covering all agents under a profile/preset. Its workflow is as follows:

  1. Pre-execution scan: When cordis_define and cordis_run trigger tools/pre-execute, the source code is sent to the scan engine (16 rules, pure functions).
  2. Result caching: Scan results are stored in an LRU cache of size 100.
  3. Approval decision: At the cordis_run stage, the plugin checks whether there are Critical/High level findings. If so, it sets the response type to {kind:'ask'} and attaches a reason; otherwise, it allows execution.
  4. Post-execution notification: At the tools/post-execute stage, the risk report is sent to the model and users through the additionalContexts channel.

The report is a standalone pure JSON object and does not serialize live Cordis objects. The report travels through the additionalContexts channel, independently of each tool’s own output.render, and will not be overwritten by tool content.

Audit Rules

The audit is based on 16 rules, divided into four main groups. The threshold for activation approval is critical or high.

Group Rule (id) Level
Dangerous capabilities global-proc — Node process global critical
global-buf — Buffer global high
dynamic-eval — eval / new Function critical
module-load — require() / import external modules high
ctx-bracket — ctx[...] dynamic property escape high
native-timer — setTimeout, etc. medium
client-dom — direct client-side use of document/window/fetch high
Data exfiltration exfil-combo — sensitive source + network egress combination critical
hardcoded-cred — hardcoded credentials high
base64-net — base64 + network combination high
Cordis anti-patterns live-serialize — serializing live objects high/medium
undeclared-svc — accessing services without declared inject medium
sensitive-svc — using shell/subprocess/fs/web/credentials high
effect-no-dispose — ctx.effect with no cleanup function medium
Privilege escalation surface rpc-live-obj — RPC returning live objects medium
shadow-slot — registering high-risk overriding Slots medium

Limitations and Notes

  1. Static matching limitations: It relies on static pattern matching and cannot recognize intent-level or multi-step obfuscated attacks. A CLEAN conclusion only means “no rule hit” and never proves safety.
  2. No hard blocking: The audit layer does not hard-block calls; it only triggers approval. critical+high findings trigger approval, but the call itself still executes.
  3. In-process operation: The report is only valid within the current process and does not involve persistent storage or historical-record UI.
  4. Runtime permissions: The plugin runs with the permissions of the current DSH process. Before installing, verify the source code and license.

Summary

dsh-plugin-security-audit provides an additional security protection layer for dynamic plugins in DSH. By performing static scans at definition and runtime, it helps developers identify high-risk code patterns without adding extra token costs, and obtains user confirmation before activating critical plugins.