# Ten modes in the table, and eight in the gate plugin

> dsh-redteam-model is a preset and plugin collection for DeepSeek's agent harness, covering ten security research modes. Its own text counts the specialist modes three different ways, and an earlier version installed a global instruction file that leaked into every session.

**SeaOf0/dsh-redteam-model** — 基于dsh web实现的多种模式，目的是服务于redteam进行授权的安全研究，覆盖渗透测试、红队评估、代码审计等范围领域，请勿用于非法行为。（允许二开，赋予模块各位自己的业务逻辑，方法论只有自己熟练的才好用，好的方法论=好的生态）

- Repository: https://github.com/SeaOf0/dsh-redteam-model
- Stars: 662 · Forks: 59
- Language: Python
- License: MIT
- Published: 2026-09-17 · Updated: 2026-09-17 · Language: en
- Canonical page: https://hysenlabs.com/projects/seaof0-dsh-redteam-model

## Ten modes in the table and eight in the gate plugin

The count of modes is the least stable number in the project. The mode table lists ten entries: one generalist researcher mode and nine specialist ones covering web and API testing, source audit, binary analysis, attack and defence assessment, evasion, incident response, cloud security, CTF solving, and asset mapping. The stage-gate plugin then describes itself as validating 32 stage gates across eight modes, and the attack-atlas plugin describes its matrix as covering eight specialist modes. The results plugin says nine. The package manifest says deploy the nine presets, while the readme says deploy ten security modes and tells you to expect a roster of ten. Three of those numbers refer to the same directory. Whether the two modes without gates are excluded by design or by accident is not something the documentation resolves.

## An earlier version wrote into a file every session reads

The most honest paragraph in the readme is a confession about a previous release. Both install routes land a bundled security-preset support specification as a file with its own namespace inside the harness home directory, and a context injector loads it only into the ten security mode sessions, with other and standard sessions getting nothing injected and no extra cost. Earlier versions installed the same specification into the harness's single global instruction file, which the host mechanism applies to every session indiscriminately, which the readme calls cross-mode context pollution. Upgrading installation now finishes the job by turning the old file into a restorable backup with a dated prefix, and it states that content not belonging to this collection is never touched. That is a bug class worth remembering for any plugin that injects instructions.

## A finding needs two independent sign-offs to reach a report

The stated design principle is two layers of defence: text discipline in the persona and playbook, and runtime enforcement in the plugins. Four rules make it concrete. The model cannot assess its own gates, because structural validation has to arrive as a tool call rather than a sentence. Semantic gates go to an independent reviewer rather than to the same agent that produced the finding. A key finding needs dual signing: the harness review and an outside review must agree before it enters a report. And every verdict lands in an audit trail of three named files, covering gates, enforcement, and evidence indexing. The rule that changes the workflow most is the third, since a report with no cross-harness reviewer available will not fill.

## The optional CLI sits on the critical path for reports

The machine-difference section lists what is optional and what degrades by itself: the two command-line assistants, and a scanner toolchain of several programs including a network mapper, two web scanners, a fuzzing tool, a Java decompiler, an instrumentation framework, and a compiler. Missing tools fall through a three-rung ladder, from something already detected to a protocol server to an install you approve. That reads like a complete answer for the toolchain. It is not, because the same assistants also appear as the second signer for key findings, and as providers for the plugin that spawns them headlessly to cross-check the harness. So the item described as a nice-to-have is also the one that decides whether findings can be promoted into a report at all.

## Two documented install routes, and the published package is a third

There are three ways in and the documentation covers two of them. The recommended route treats the whole collection as one harness plugin added from a GitHub reference:

```sh
dsh plugin --profile web add github:SeaOf0/dsh-redteam-model
```

That route then deploys the modes and manages the seventeen runtime plugins from a settings page. The second route clones or downloads the source and runs a deployment script that installs preset links, mounts plugins, installs dependencies, and is documented as idempotent, with an offline verification mode and a mode that starts the web interface on a local port. The manifest, meanwhile, is configured for public publication with a bundle patch and a peer dependency on a release-candidate range of the host settings package. So a registry install is possible and is the only path with no instructions.

## Seventeen plugins, and each one names the file it writes

Each runtime plugin is described by the artefact it produces rather than the feature it adds, which makes the collection auditable. The gate plugin writes verdicts to a gate log and keeps an operation state file that drives recovery after an interruption. The trace plugin stores every tool call from every security session and exposes four search and statistics tools over it. The enforcement plugin intercepts tool calls deterministically: a report gate, write boundaries, ask-then-do on high-risk commands, and rate limits on unguided scanning. The campaign memory plugin refreshes a repeated write instead of duplicating it, ranks by heat with a 30-day decay, and expires detection fingerprints after 30 days while target fingerprints survive 180 days but stay searchable. Mode assets themselves are four layers: a persona, a playbook, loadable skills, and an indexed reference directory.

## The scanner plugin has six fallback rungs and a fuse

One plugin wraps a dozen local scanners behind a declarative registry, and its description is a safety design rather than a feature list. A six-rung ladder decides how to run a tool: something local, a protocol server, an already-installed alternative, a protocol alternative, an offer to install, or a script. Defaults are conservative and every explicit override is recorded. Unguided scanning has to be registered. Output is capped and written to disk in full, and consecutive failures trip a circuit breaker. The code-audit plugin is stricter still: it wraps a local static analyser with a preset offline ruleset, writes both a reconciliation note and a spreadsheet for every hit, and insists that a hit is not a vulnerability until someone reviews and chains it, promoting it through results registration. It never installs the analyser and runs with metrics reporting disabled.

## Two minutes of manual verification, in five checks

The readme closes its install section with a manual verification procedure that fits in two minutes, and it is written as acceptance criteria rather than as a smoke test. First, the roster at the local address must list ten modes. Second, asking any session to call the gate-listing tool must return the specialist gate schema, which proves the tool is wired rather than merely present. Third, and most useful, five named modes must show the scanner tools while the others do not, and the readme spells out that absence is the correct result, since it means the preset plane is right rather than broken. Fourth, a started task must produce a runtime envelope snapshot naming the mode and phase. Fifth, writing to the reports directory without clearing the report gate must be intercepted and answered with directions.

## Conclusion

dsh-redteam-model suits a red team with written authorisation who wants repeatable playbooks per engagement type rather than one generic assistant, and who is prepared to maintain the source. It does not suit an unauthorised test, and it does not run without the upstream harness installed first. Before deploying, read which of the seventeen plugins you actually want, since a mode whose scanner tools you cannot see may be a preset-plane mistake rather than a bug, and note that findings only enter a report after a second independent reviewer agrees, so budget for a cross-harness tool or accept that the report stays empty.

## FAQ

### What does dsh-redteam-model do?

It adds ten authorised security research modes and seventeen runtime plugins to DeepSeek's agent harness. Each mode bundles a persona, a playbook, loadable skills, and an indexed reference directory, and the plugins add stage gates, deterministic tool interception, tracing, and scanner wrappers.

### What do I need before installing dsh-redteam-model?

Node.js 22 or newer, because the host harness requires it, and the host harness itself installed first, since this collection adds to it rather than replacing it. The readme says you do not need pnpm or the host launcher pre-installed, and that bash and python are not required.

### How do I install dsh-redteam-model?

Either add it as one harness plugin from a GitHub reference and manage the modes and plugins from the settings page, or fetch the source and run the deployment script, which links presets, mounts plugins, and installs dependencies idempotently. A third published package route exists with no documented instructions.

### Does dsh-redteam-model send a finding straight to a report?

No. A key finding needs dual signing: the harness review and an independent cross-harness review must agree before it enters a report. The model cannot assess its own gates, since structural validation has to arrive as a tool call.

### Which security modes does dsh-redteam-model ship?

Ten: a generalist red-team researcher mode plus specialists for penetration testing, code audit, binary analysis, attack and defence assessment, evasion, incident response, cloud security, CTF solving, and asset mapping. Note that other parts of the readme count the specialist modes as eight or nine.

## Sources

- [Issues](https://github.com/SeaOf0/dsh-redteam-model/issues)
- [License: MIT](https://github.com/SeaOf0/dsh-redteam-model/blob/main/LICENSE)
- [README](https://github.com/SeaOf0/dsh-redteam-model/blob/main/README.md)
- [SeaOf0/dsh-redteam-model on GitHub](https://github.com/SeaOf0/dsh-redteam-model)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/seaof0-dsh-redteam-model