Back to home

PerryLink

dsh-defend

Prompt-injection, jailbreak, and secret-leak defense for DeepSeek Harness: Aho-Corasick detection with allow/ask/block interception and sanitized audit events

Stars
0
Language
TypeScript
Created
Aug 16, 2026
Updated
Aug 16, 2026

Introduction

🛡️ dsh-defend

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

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

License DSH plugin Node CI Version npm version npm downloads

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


Compatibility

SurfaceStatus
HarnessDeepSeek Harness 0.1.0-rc.6 (compat declared for 0.1.0-rc.50.1.0-rc.6)
Node^22.19.0 || >=24.0.0
PlatformsAll (pure host; no native code, no network)
ModelAny (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:

PointScannedDecision
agent/pre-stepinbound user messagesallow → next(); ask → approval; block → reject the step
tools/pre-executetool argumentsallow → next(); ask → approval; block → deny
tools/post-executetool resultsallow → 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

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

KeyDefaultMeaning
enabledtrueMaster switch for both layers
actiondenyDestructive-delete guard action (deny / ask)
toolNames['bash','persistent-bash','terminal-bash']Tool names whose command arguments the guard reviews
detection.enabledtrueDetection-layer switch
detection.maxScanChars10000Scan cap per interception (head only)
detection.injectionActionaskInjection family: allow / ask / block
detection.jailbreakActionaskJailbreak family: allow / ask / block
detection.secretActionaskSecret family: allow / ask / block
detection.secretBlockCriticaltrueCritical secrets always block regardless of secretAction
detection.audittrueWrite defend/detection session audit events
detection.maxReportEntries200In-memory report ring-buffer cap
registerCommandtrueRegister the /defend command
registerTooltrueRegister the defend_report tool

Tools & surfaces

SurfaceKindNotes
defend_reporttoolTotals (recorded/blocked/asked), per-family counts, and the 20 most recent matches — never matched text
/defendcommandThe same summary as text
agent/pre-steplistenerInbound message scanning (enter/reject)
tools/pre-executelistenerTool-argument scanning (deny/ask) + the destructive-delete guard
tools/post-executelistenerTool-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 on newer harness builds. Audit appends use the two-argument Session.append form (the pinned rc.6 peers have no append-envelope option); on post-rc.6 builds the events are required-on-read, which is fine while this plugin is installed because it declares the event type.

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.0-rc.6 types (no paths)
pnpm test           # vitest: 49 tests, 4 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

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.

License

Apache License 2.0 © 2026 dsh-defend contributors