dsh-vault-wall

When working with a DSH agent, an often-overlooked risk is simple: the agent may stumble into sensitive paths you never intended it to reach during reads, writes, searches, or shell commands: API keys, private configs, audit logs, even the rule definitions themselves. dsh-vault-wall is a client-side policy fence built for exactly this class of accidental exposure. It makes your designated paths either completely invisible to the agent or explicitly off-limits, keeping the sensitive zone outside the agent's operational reach.

On capabilities, it offers two protection modes. In hide mode, any operation on a protected path returns not-found; the agent learns nothing about the path's existence or name. In deny mode, the agent receives a clear error stating the location is rule-protected. Rules can be scoped per tool: read, write, edit, read_image, glob, grep, bash, and pwsh can each carry independent rules, or a single rule can apply to all tools. Each rule accepts multiple absolute paths, precise to a single file or an entire directory tree. Critically, the system is self-protective: the rule store, audit log, and settings document are themselves hidden from the agent, so it cannot rewrite its own fence or peek at its audit trail within a session.

It is aimed at developers and operators who run DSH Desktop or the official dsh CLI and need to draw hard boundaries around sensitive files in agent-driven workflows. If your agent performs repo-wide searches, batch file rewrites, or shell scripts and you worry it might casually open a .env or secrets directory, installing this plugin and adding a few rules in the Settings panel is a practical first line of defense. Keep in mind it is a policy fence, not a kernel boundary: true read-side invisibility still requires OS-level account separation, ACLs, or encrypted containers.