dsh-tool-guard

When a DSH instance hosts dozens of tools across multiple presets, the constraint that the model must not see or invoke certain tools is fragile and easy to lose track of when scattered across per-preset configuration files. dsh-tool-guard promotes that constraint to the host plane: preset-agnostic, it enforces blocking rules at a single unified plugin layer, cleanly decoupling security policy from business configuration.

The plugin operates on three planes. The presentation layer strips blocked tools from the schema list during system-prompt assembly so the model never sees them. The execution layer registers a tools.guard hook that hard-rejects any invocation that slips past upstream filtering. The configuration surface offers two semantically identical write paths: a dedicated WebUI card and a direct edit to settings.yaml; saving either triggers an instant hot-reload of both upstream layers with no restart required. Core transport tools (read, write, edit, bash, run_code) are protected by a self-guard and can never be accidentally blocked. If the panel is unreachable or a configuration is malformed, the blocking semantics remain intact and a manual yaml edit restores everything; the configuration plane can never lock out the system.

It is aimed at DSH security administrators who need centralized, drift-free control over tool visibility in multi-preset production environments, as well as headless, CLI, or scripted bulk-configuration workflows. Deployment supports both a global web-profile bundle mount and a local per-preset mount, letting teams pick whichever topology fits their stack.