PerryLink/dsh-defend

PerryLink/dsh-defend

在 agent/pre-step、tools/pre-execute、tools/post-execute 三个接缝检测提示词注入、越狱与密钥泄露,按 allow/ask/block 分层拦截,附脱敏 defend/detection 审计事件、defend_report 工具与危险删除命令门禁。

安全与权限cordisdeepseekdeepseek-harness

🛡️ 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 · हिन्दी

dsh plugin --profile <name> add dsh-defend

📖 Ecosystem knowledge base — measured data, not marketing: plugin development guide · plugin-selection data · maintenance criteria.

Install & uninstall

  • git channel (latest main): dsh plugin --profile web add github:PerryLink/dsh-defend — 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-.tgz.
  • uninstall: dsh plugin --profile web remove dsh-defend (or remove the row from the profile patch).

⭐ 如果它帮到了你

这个插件是 DSH 插件家族的一员(95 个,全部 Apache-2.0)。如果你在用,给个 star —— 它不会解锁任何功能,但会让下一个人在搜索里更容易找到它。

*English:* part of a 95 plugin family for DeepSeek Harness. If it is useful, a star helps the next person find it — nothing is gated behind it.

What is dsh-defend?

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

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

*Workflow overview: request → policy / review → verdict. The examples below use the real command surface.*

Maintenance status: 🧊 FROZEN

Frozen on 2026-10-05. No new features. This package still works, and it is not retired — but it no longer receives feature work. Only a genuine breakage will be fixed.

Maintainers treat this capability as one where better-adopted alternatives now exist, so effort has moved elsewhere. The comparison below was measured on 2026-10-05 and is recorded so nobody has to redo it.

· package · weekly downloads this package · dsh-defend · 937 better-adopted alternative · cc-safety-net · 13,087

Why the alternative leads. cc-safety-net provides blocks destructive commands and secret-file access as a coding-agent CLI hook.

Compatibility. declares no dsh peers, so the compatibility guard never blocks it.

What this package still does that the alternatives do not. this package's differentiators are the Aho-Corasick pattern engine ported from the prompt-injection / jailbreak / secret-leaker asset sets, three-way allow/ask/block interception on user messages, tool arguments AND tool results, and sanitized defend/* session audit events. The rival above is narrower (destructive commands and secret files) but is adopted an order of magnitude more widely.

👉 For new work, prefer dsh-defend is still the broader detector; cc-safety-net is the far better-adopted alternative for the destructive-command gate specifically. Existing installs keep working unchanged; nothing is being removed.

*Full evidence, including the host-version compatibility matrix: dsh-plugin-supersession-review-20261005.md.*

Comparison

105 samples (75 positive / 30 negative) · from benchmark/RESULTS.md in this repo

Compatibility

Surface · Status Harness · DeepSeek Harness dsh-v0.2.1-alpha.1 (verified 2026-09-25; peer ranges >=0.1.2-rc.1 =0.1.5-alpha.1 =0.1.6-0 =0.1.7-0 =24.0.0 Platforms · All (pure host; no native code, no network) Model · Any (detection runs before content reaches the model)

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:

Point · Scanned · Decision agent/pre-step · inbound user messages · allow → next(); ask → approval; block → reject the step tools/pre-execute · tool arguments · allow → next(); ask → approval; block → deny tools/post-execute · tool results · allow → next(); ask → approval; block → corrective feedback

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

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

# 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'

Examples

These are the plugin's real entry points; install once, then call one.

Detailed example

Command

~~~sh defend_report ~~~

Input

~~~json {} ~~~

Output

~~~text dsh-defend: 0 recorded detection(s), 0 blocked, 0 asked. ~~~

*Observed from tests/lifecycle.spec.ts:91-126 (canonical empty value at :110-117); src/index.ts:772-775*

Failure branch

Input

~~~text Remove-Item -Recurse ~~~

Output

~~~text {"kind":"deny","reason":"blocked dangerous recursive delete command (Remove-Item -Recurse): no explicit target path was printed. Dry-run first (Remove-Item -WhatIf / git clean -n / list the directory), verify each target one by one, then retry with an explicit absolute path"} ~~~

*Observed from plugins/dsh-defend/src/index.ts:376-379; plugins/dsh-defend/tests/destructive-delete.spec.ts:68-71; verified via plugins/dsh-defend/lib/index.js*

Brief examples

  • /defend

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.

Key · Default · Meaning enabled · true · Master switch for both layers action · deny · Destructive-delete guard action (deny / ask) toolNames · ['bash','persistent-bash','terminal-bash'] · Tool names whose command arguments the guard reviews detection.enabled · true · Detection-layer switch detection.maxScanChars · 10000 · Scan cap per interception (head only) detection.normalizeUnicode · true · NFKC-normalize text before scanning (blocks lookalike-Unicode bypass) detection.secretMinEntropy · 3.0 · Minimum Shannon entropy (bits/char) to admit a secret regex hit; 0 disables detection.injectionAction · ask · Injection family: allow / ask / block detection.jailbreakAction · ask · Jailbreak family: allow / ask / block detection.secretAction · ask · Secret family: allow / ask / block detection.secretBlockCritical · true · Critical secrets always block regardless of secretAction detection.audit · true · Write defend/detection session audit events detection.allowUnmarkedAudit · false · Keep writing session audit on hosts whose Session.append predates the ignorable marker (every released line so far, the 0.2.x prereleases included) or that fail-closed on unknown event types (host 0.1.2-rc.1+), accepting the unresumable-session hazard detection.maxReportEntries · 200 · In-memory report ring-buffer cap registerCommand · true · Register the /defend command registerTool · true · Register the defend_report tool

Tools & surfaces

Surface · Kind · Notes defend_report · tool · Totals (recorded/blocked/asked), per-family counts, and the 20 most recent matches — never matched text /defend · command · The same summary as text agent/pre-step · listener · Inbound message scanning (enter/reject) tools/pre-execute · listener · Tool-argument scanning (deny/ask) + the destructive-delete guard tools/post-execute · listener · Tool-result scanning (block feedback)

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, and the 0.2 corridor — re-verified 2026-10-04 against the published 0.2.1-alpha.1, whose append(type, data, ...opts) reads only sourceEventSeqs/surfaceOp out of the options bag and builds the envelope as { type, seq, time, data }) 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; the 0.2.x prereleases are classified unmarked up front for exactly that reason, while a stable 0.2.x still falls back to the append probe. 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.7-rc.2 types (no paths)
pnpm test           # vitest: 97 tests, 9 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).

Interoperability with other DSH plugins

Verified against DSH `0.2.0-rc.2` (the runtime this README ships for) and the high-star plugin set surveyed on 2026-10-05.

This plugin does not interfere with other plugins, including the widely installed high-star ones:

  • No tool-name collision. Every tool is namespaced; no bare name owned by a shipped tool or another plugin is registered.
  • No service-key collision. It provides no service key at all, so it cannot collide on one.
  • No slot collision. It registers no client slot key, so it cannot contend for a shadows-shipped-ui seat.
  • No HTTP route collision. It registers no webServer prefix.
  • No patch-layer collision. The bundle patch only inserts its own row; it never overrides a built-in row's config.
  • No global mutation. It does not patch prototypes, rewrite process.env, or replace the global fetch dispatcher.

Shared event listeners are non-interfering by construction. It observes the ordering-sensitive events agent/pre-step, tools/post-execute, tools/pre-execute with ctx.on() — Cordis's broadcast registration, where every listener runs and none can starve another. Every listener here delegates through `next()`, so the chain is never short-circuited, and a mutation is applied to the value next() produced rather than returned in its place:

  • agent/pre-step — also used by dsh-routing-suite (7000★, 7 listeners), modlens (4122★), dsh-purge (3317★), dsh-agent-teams (1923★), dsh-context (1849★).
  • tools/post-execute — also used by cc-safety-net (1576★).
  • tools/pre-execute — also used by cc-safety-net (1576★).

Static evidence: dsh-plugin-doctor K10–K13 report pass for every check on this repository.

Topics