Preface¶

The core design of DeepSeek Harness (DSH) is “everything is a plugin.” Introducing external plugins means introducing new code and permissions. Developers usually can only rely on static scanning, but this cannot cover dynamically constructed commands or tool calls at runtime. dsh-guardwall, as a security plugin, provides two layers of protection: pre-installation source-code health checks and runtime guardrail interception, along with tamper-detecting audit logs.

Function Overview¶

This plugin is maintained by iiiweiii and is under the MIT license. Core capabilities include:
* Pre-installation checks: materializes the actual artifact, generates a permission manifest, performs static risk scanning and trust scoring, and gates plugins before installation.
* Runtime interception: on the input side, blocks destructive commands, credentials, SSRF, and reverse shells; on the output side, audits key leakage.
* Tamper-detecting audit: uses HMAC chained hashes and tail checkpoints to ensure logs cannot be tampered with or truncated.
* Hot loading: updates rules and thresholds without restarting.
* Zero third-party runtime dependencies: uses only Node.js built-in modules.

Installation and Enablement¶

Install the plugin via CLI. If the npm artifact has not been published yet, you can use the GitHub channel.

dsh plugin --profile web add dsh-guardwall

After installation, verify that the configuration is mounted:

dsh --profile web --dump-config | grep -A2 'id: guardwall'

Layer 1: Pre-Installation Check¶

Before installing a plugin, the system first clarifies “what permissions are granted by installing this plugin.” By default, plugins with risk level >= 7 are blocked.

Check tools:

npx guardwall check <spec>              # 体检输出报告
npx guardwall add <spec> [--force]      # 体检通过后执行安装

<spec> supports local paths, npm package names, or github:owner/repo.

Four-step check process:
1. Real artifact materialization: installs the npm package with --ignore-scripts or checks out the exact GitHub ref to obtain the source code before making judgments.
2. Permission manifest: statically analyzes file paths accessed by the plugin (such as ~/.ssh), commands executed (such as rm, curl), and domains connected to.
3. Static risk scanning: checks the dependency tree, dangerous patterns (eval, dynamic execution), and installation scripts.
4. Trust scoring and gate: based on a five-dimensional score. Grade D is rejected (requires --force), Grade C raises a warning, and Grades A/B are allowed.

Layer 2: Runtime Interception¶

The plugin intervenes in DSH’s tools/execute (input side) and tools/result (output side) events.

Unlike other security plugins that depend on cordis/dsh-tools, dsh-guardwall has zero third-party runtime dependencies, reducing the supply-chain attack surface. If an Agent is induced to execute a high-risk operation (such as rm -rf /), the call is intercepted and an error message is returned.

Default interception rules (risk >= 7):
* SEC-001: destructive deletion/formatting (rm -rf /, format, mkfs).
* SEC-002: access to credential files (~/.ssh, .aws, .env).
* SEC-003: suspected plaintext credentials in parameters (password=, sk-).
* SEC-004: SSRF attacks (cloud metadata endpoints).
* SEC-005: reverse shells or download-to-execute pipelines (bash -i, nc -e).
* SEC-006: command-chain injection (;rm, &&rm).
* SEC-007: privilege escalation operations (sudo su, chmod 777 /).
* SEC-008: writing to critical system files (/etc/passwd, /boot).

Output-side audit rules:
* OUT-001: secret/private key leakage (sk-, AKIA, BEGIN PRIVATE KEY).
* OUT-002: output of internal network IPs.
* OUT-003: database connection strings with passwords.
* OUT-004: environment variable secret dumps.
* OUT-005: public keys/certificates/sensitive materials.

Hot Loading¶

Supports dynamically modifying rules and thresholds at runtime without restarting DSH.

Hot-loading rules:
Rule files are located in ~/.dsh/cache/dsh-guardwall/rules.d/*.json; changes take effect when saved.

[
  { "id": "MY-001", "direction": "input", "risk": 8,
    "re": "internal\\.corp\\d+\\.com", "summary": "禁止访问内网域名", "advice": "确认授权后访问" }
]

Hot configuration:
config.json in the same directory can adjust thresholds:

{ "blockThreshold": 6, "warnThreshold": 3 }

Tool commands:
* guard_reload: manually refresh rules and configuration.
* guard_rules: view active rules.

Configuration and Policy¶

The default policy is to block risk >= 7 and alert on risk >= 4. This can be adjusted in the config section of cordis.patch.yml.

- insert:
    - id: guardwall
      name: dsh-guardwall
      config:
        blockThreshold: 7
        warnThreshold: 4
        dataDir: ~/.dsh/cache/dsh-guardwall
        failMode: closed             # 扫描异常时拒绝执行
        allowAgentWhitelist: false   # 默认禁止 Agent 自助放行

Audit Logs¶

Audit logs rely on an HMAC chained-hash mechanism to ensure log integrity.

Log storage location: ~/.dsh/cache/dsh-guardwall/
* audit-YYYY-MM-DD.jsonl: each record includes prevHash and an HMAC hash.
* checkpoint-YYYY-MM-DD.json: tail anchor.
* chain.key: chain key (permissions 0600).

Security mechanism:
Content modification, concurrent chain divergence, or tail truncation causes verify() to return failure. This mechanism is used to detect accidental corruption and modifications made without the key.

Tool List¶

Compatibility and Roadmap¶

• Compatibility: validated against @deepseek-ai/dsh 0.1.0-rc.5 (web profile).
• Roadmap: isolate whitelists by agent/session, secondary confirmation for sensitive operations, audit export/weekly reports, npm publication.

Conclusion¶

dsh-guardwall provides an end-to-end safety net for the DSH plugin ecosystem from installation to usage through source-code traceability, runtime interception, and chained auditing. If you need to strengthen the security of the agent execution environment without sacrificing flexibility, you can deploy it by referencing its configuration.