dsh plugin --profile web add dsh-trust-suite

Nine deterministic guards watch what a DSH agent reads, writes, executes, spends, and remembers — plus a plain-language dashboard and a guardian pet that makes the state visible at a glance. Every decision is made by pure rule engines: zero LLM calls in the trust path, ~140 unit tests, verified against real DSH sessions.

The nine guards

Plus two consumers of the same event stream:

• dsh-trust-panel — a sidebar dashboard that translates the nine channels into plain language, bilingual (zh/en), with a status light and acknowledge flow.
• dsh-guardian-pet — the same state as a creature: it dozes while all is clear, bristles when something is caught, and writes you a weekly battle report.

flowchart LR
    A["tool call"] --> B{"pre-execute<br/>pr-gate · egress-gate"}
    B -- deny --> X["blocked"]
    B -- allow --> C["execute"]
    C --> D{"post-execute<br/>read-guard"}
    D -- wrap/block --> E["into context"]
    D -- pass --> E
    E --> F["attest-chain<br/>signed ledger"]

Install

dsh plugin --profile web add dsh-trust-suite

That single bundle installs all nine guards plus the dashboard. Prefer git checkouts? ./install.sh web from this repo does the same from GitHub sources (everything ships prebuilt lib/, no allowBuilds approval needed). Individual guards are also installable on their own.

Honest scope

[!WARNING] This is a policy-check and audit toolset, not a sandbox. The guards make deterministic decisions at DSH's plugin hook points; they are not OS-level network controls, filesystem permissions, or a semantic guarantee that "the model was never influenced". Hard boundaries belong to the host sandbox, system permissions, or a proxy — layer this suite on top of those, not instead of them.

What each guard actually does, stated plainly:

• Detect (report + ledger): mcp-test, prompt-drift, freeze, compaction-guard, janitor flag drift and leftovers — they do not block anything.
• Enforce before the fact: pr-gate denies out-of-scope file writes; egress-gate denies non-allowlisted web destinations (shell fetches are observe-only by default).
• Mutate results: read-guard wraps flagged content in a quarantine envelope (default) or blocks it — in wrap mode the original text is still in context, explicitly marked untrusted.
• Record: attest-chain appends a signed, hash-chained evidence record per tool result.

Known boundaries are documented per guard in each repo's README — coverage limits, default-off modes, and trust-on-first-use for baselines.

FAQ

Does this call any LLM? No. Every decision is a pure rule engine — same input, same verdict, auditable.

Can I install just one guard? Yes. Every guard is an independent npm package; the suite is only a convenience bundle. dsh-trust-panel even works standalone — its read/egress engines ship inside the panel package.

Does read-guard delete or rewrite the original file? Never. It only changes what reaches the model's context, and only for high-severity findings in wrap/block mode.

Windows? Yes — CI runs Windows + Linux on Node 20/22/24 for every guard.

Exact supported set (as verified): Node ≥ 20 · npm ≥ 11.15 (staged publishing route) · DSH 0.2.x source snapshot 0.2.1-alpha.2 with host packages on the 0.1.2-rc.1 line · dsh plugin add installs via the official profile flow (pnpm). Plain-npm installs of the suite depend on the registry peer graph resolving cleanly — dsh-prompt-drift ≥ 0.1.1 carries the peer fix that makes that resolve.

License

MIT