dsh-defend

🛡️ dsh-defend

• 1024 store channel: npm i -g dsh1024 once, then dsh1024 plugin --profile web add dsh-defend (counts toward the deepseek1024.com install ranking).

Prompt-injection, jailbreak, and secret-leak defense for DeepSeek Harness.

*Rules decide the known. Interception decides the rest — and everything is audited.*

English · 简体中文 · Español · Português · हिन्दी

Compatibility

What you get

dsh-defend puts two independent layers in front of the agent:

1. Destructive-delete guard — the executable form of the 8·14/8·16 postmortem lesson. On tools/pre-execute, recursively deleting shell commands are refused unless every target is an explicit absolute path inside the session workspace and outside the protected prefixes (home config, .dsh/.claude, system directories). Dry-run markers (-WhatIf, --dry-run, git clean -n) pass, because they are exactly the check the lesson demands.
2. Detection layer — ported from four upstream assets (all Apache-2.0, see THIRD_PARTY_NOTICES.md): 25 Prompt-Injection-Payloads rules, 25 Jailbreak-Detector patterns through a pure-TypeScript Aho-Corasick automaton, 12 secret grammars from Secret-Key-Leaker-Detect plus the issuers' public references, and the Prompt-Attack-Dataset kept verbatim as the regression benchmark.

Three interception points, one decision model each:

Defaults: ask for every family, block for critical secrets (the upstream interrupt-on-sight semantics). No approval answerer = fail closed. Every pass-through calls next() — downstream policy plugins are never short-circuited.

inbound message ── agent/pre-step ── scan ── clean → next()/enter
tool arguments ── tools/pre-execute ── scan ── allow → next()
tool results   ── tools/post-execute ── scan ── block → feedback
                                  │
                                  └─ defend/detection audit (rule id, family,
                                     severity, decision — never matched text)

Quick start

# 1. install the bundle into your profile
dsh plugin --profile web add "github:PerryLink/dsh-defend#main"

# or from npm (published releases)
dsh plugin --profile web add dsh-defend

# 2. restart and verify the row
dsh --profile web --dump-config | grep -A3 'id: dsh-defend'

Install & uninstall

• git channel (latest main): dsh plugin --profile web add "github:PerryLink/dsh-defend#main" — the prepare script builds with production dependencies only.
• npm channel (published releases): dsh plugin --profile web add dsh-defend.
• tarball channel: pnpm pack in this repo, then dsh plugin --profile web add ./dsh-defend-<version>.tgz.
• uninstall: dsh plugin --profile web remove dsh-defend (or remove the row from the profile patch).

Configuration

All tunables are Schemastery Config fields (changeable from cordis.yml). An id-targeted override replaces the whole row — restate every key you need. cordis.patch.yml documents each key inline.

Tools & surfaces

Permissions & data

• Permissions: ask decisions ride the official approval seam; nothing is re-implemented or bypassed. The plugin declares session:append and network:none in its workshop manifest.
• Data: nothing is stored on disk; the report ring buffer is in-memory and bounded. No network requests, no subprocesses.
• Session log: defend/detection events carry rule id, family, category, severity, secret type, decision, and scan facts — matched text never reaches the log, and secret matches are type-only by construction.

Security boundaries

• Detection, not enforcement. The guard and the detection layer only produce deny/ask/block decisions on official seams; the sandbox and approval systems remain the enforcement authorities.
• Fail closed. Missing approval answerer, missing session, or a missing services surface degrades to the strictest decision — never to silent pass-through.
• No content leaves the process. Scanning is local; audit events are sanitized; secrets are never logged, displayed, or reported.
• Bounded work. Scan caps, one match per rule, and ring-buffer bounds keep hostile inputs from consuming unbounded resources.

Known limitations

• Detection gaps. The rule library catches the ported vocabularies and their tolerant variants; novel phrasing, lookalike-Unicode encodings (NFKC normalization is tracked as future work), and multi-step attacks can evade it. The benchmark pins the measured floor (27/28 on the upstream dataset) so regressions are visible.
• No model-level verdicts. dsh-defend is deterministic; it never calls a model and cannot judge novel intent.
• Message rejection is silent. agent/pre-step reject carries no reason to the model (the seam has no reason field); the audit event records the rule facts.
• Session audit and the ignorable marker. Audit appends request the envelope's ignorable: true marker so any harness build can load the log. Every released harness line so far (0.1.0-rc.1–0.1.0-rc.8, 0.1.1-rc.1–0.1.1-rc.2) silently drops it — the event lands unmarked and makes the session unresumable on stricter builds; host 0.1.2-rc.1 retains the envelope field for stored-log read compatibility only, but Session.append still cannot stamp it and the read path rejects unmarked unknown event types (defend/detection is not registered), so writing there also makes the session unloadable. dsh-defend therefore decides BEFORE the first append (peer-version pre-check; unresolvable versions fail closed) and disables session-log audit with a one-time warning. Set detection.allowUnmarkedAudit: true to opt back in. See issue #2.

Development

pnpm install        # node ^22.19 || >=24
pnpm run typecheck  # tsc: src + tests against the local harness checkout
pnpm run typecheck:ci  # tsc against the published 0.1.5-rc.1 types (no paths)
pnpm test           # vitest: 75 tests, 8 suites (detection benchmark incl.)
pnpm run build      # tsdown bundle + tsc declarations (lib/)
pnpm run verify:self-contained  # dependency specs resolve from the registry
pnpm run verify:artifacts       # built ESM face + shipped files present
pnpm pack           # the published tarball

Benchmark

The red-team benchmark (per-category P/R/F1 over 105 samples, plus the 27/28 fixture floor) is published in benchmark/RESULTS.md; regenerate it with node --experimental-strip-types benchmark/run.mjs (zero new dependencies, no build step).

Topics

dsh, dsh-plugin, deepseek-harness, deepseek, cordis, security, prompt-injection, jailbreak, secret-scanning, ai-safety

Contributors

• @PerryLink — creator and maintainer: destructive-delete guard, the four-asset detection port, interception wiring, audit surface, and the five-language docs.
• @cuohua — the precise report on defend/detection events landing unmarked and making sessions unresumable on stricter builds (#2); the runtime host-capability detection and the ignorable-marker discipline derive directly from that analysis.

PerryLink DSH Plugin Family

This project is one of the 37 DeepSeek Harness plugins maintained by PerryLink. If this one helps you, the others likely will too:

Install from the DSH Desktop Market

All PerryLink plugins are browsable in the built-in DSH Desktop Market: Market → Sources → add source → paste https://perrylink-dsh-catalog.perrylink.workers.dev/catalog-source.json → select it. Installation still goes through the Market's npm-identity verification and your confirmation.

License

Apache License 2.0 © 2026 dsh-defend contributors