在提示词里叮嘱 Agent「不要删文件」，是一条建议，不是一条约束。dsh-permission-rules（🛡️ 声明式权限规则，PerryLink 维护）换了思路：把「能不能调用这个工具」变成一次可预期、可审计的判定，由宿主在工具执行前求值。
它的公开数据是：114★、周下载量 1,115、综合分 58.2；npm 包 dsh-permission-rules @ 0.7.7，Apache-2.0，要求 Node ^22.19.0 || >=24.0.0，最近一次上游提交在 1 天前。边界也要说清：本站给它的信任档位是「仅索引」，尚未实装验证；静态安全扫描标注「含敏感能力」。下文讲的是文档描述的机制，不是实机结论。
它挂在哪个接缝上
DeepSeek Harness 处理工具调用时会经过一条名为 tools/pre-execute 的瀑布流，这个插件就是其上的监听器：在调用发生前，为本次调用前置一份有序的 allow / deny / ask 规则列表。
关键词是「有序」。规则不是集合而是列表，严格按书写顺序求值，第一个匹配上的规则决定结果，其后的规则不再参与——例外必须写在前面。
一份最小可用的规则文件长这样：
rules:
- match:
tools: [bash, pwsh]
params:
command: "git push"
action: deny
reason: "No pushes from protected paths"
- match:
tools: [edit, write]
action: ask
reason: "File writes need confirmation"第二条会拦住所有 edit / write 调用并要求确认；因为它排在第二位，被第一条 deny 命中的调用根本走不到这里。匹配维度不止工具名：工具名 glob、代理身份（未知身份永不匹配）、参数键/值、工作区相对路径与网络规则；写了未知字段会直接加载失败。
三种动作，三条不同的执行路径
deny阻止调用，reason会成为模型可见的错误，模型因此知道这条路走不通，而不是白白重试。ask走宿主的官方审批接缝——挂上dsh-auto-review能得到只读的第二模型应答者，或由人类应答；两者都不存在时 harness 失败关闭。allow与「无匹配」严格通过next()委托，意味着下游监听器绝不会被短路。
每次命中与每次透传都记成 permissionRules/decision 会话事件，且只写日志，不向模型上下文注入任何内容。
内置基线为什么排在用户规则后面
插件随附一套 deny/ask 规则集，覆盖破坏性命令、权限提升、下载并执行、敏感路径，默认启用，且追加在用户规则之后。因为首个匹配生效，放在后面等于把优先级让给使用者：你的规则永远先求值、可以覆盖基线，只有你的规则都没命中时基线才兜底；不想要它就 builtin.enabled: false。
网络策略怎么接管 shell 子进程流量
它带一层 Codex 风格的进程级网络策略：内置本地 HTTP/CONNECT 代理，把派生的 shell 子进程流量导过去逐连接判定。模式有 deny-all（只读沙箱预设）、whitelist（工作区写入预设，未列出目标默认 ask）、allow-all（danger-full-access 预设）；默认 auto 跟随沙箱预设，无沙箱策略服务时解析为 autoFallback，默认 allow-all。
有两个细节值得记住：IPv4 映射的 IPv6 字面量在匹配前先规范化成 IPv4，代理连接到判决所依据的地址，不做第二次 DNS 解析；解析不出地址就以 502 失败关闭。另外 network.upstreamProxy 默认 off：即使配了上游，回环目标与由 ips 作用域规则产生的决策也永远不会链式代理；上游不可达、超时（10 秒）或非 2xx 一律产生 502——刻意不做静默回退，让配置错误可见。
试运行与热重载
enforce: false 是试运行模式：deny / ask 命中会带上 dryRun 标记写进审计日志，但每次调用都放行，可以先看「开启后哪些会被拦」再决定是否真的开。
热重载用 Chokidar 监听规则文件并带防抖，改完即生效，它与加载期的「大声失败」正好相反：加载时无效 YAML、未知字段、错误 glob/正则、规则数超 maxRules 都直接失败；运行期一次损坏的编辑只保留之前的规则，绝不崩溃。
四个最容易卡住的配置细节
坑一：Node 版本不对，装都装不上
现象。 在 Node 20 或 22.18 上安装，报错或引擎校验失败。
原因。 包的 engines.node 声明是 ^22.19.0 || >=24.0.0，低于 22.19 不满足。
解决方案。 先 node -v 确认，升级到 Node 22.19+ 或 24+ 再装。
坑二：规则明明命中了，/rules decisions 却一直是空的
现象。 审计日志一条记录都没有。
原因。 旧主机（0.1.0-rc 与 0.1.1-rc 系列）的 Session.append 早于 ignorable 标记，会静默丢弃审计事件；插件预检到这点会禁用会话日志审计，只发一条警告。
解决方案。 把 allowUnmarkedAudit: true 打开重新启用，或升级宿主。
坑三：在 cordis.yml 里按 id 覆写一个字段，其他配置全丢了
现象。 只想改一个键，结果整行被替换，其他键全部消失。
原因。 以 id 为目标的覆盖会替换整行，必须重新声明每一个需要的键。
解决方案。 覆写时把要保留的键一起写全，或改用 0.1.7-alpha 主机的设置页面就地编辑。
坑四：用 {a,b} 花括号写多个工具名，规则不生效
现象。 想一次匹配两个工具名，写成花括号形式，规则却没命中。
原因。 这里的 glob 是保守子集，不支持花括号展开。
解决方案。 拆成两条模式分别写，或把 patternMode 切成 regex。
总结
dsh-permission-rules 的价值不在「更聪明」，而在「更确定」：它把工具调用的准入变成一份顺序明确、首个匹配生效的 YAML 列表，命中与透传都进审计日志，未知身份与无法裁定的地址一律失败关闭。如果你在用 DeepSeek Harness 跑会碰文件系统和网络的 Agent，想对照同类插件的中文清单与安装形态，见 DeepSeek Harness Hub 插件清单，再决定要不要加这一层。
适合与不适合
适合：需要给文件写入、破坏性命令加确定性闸门的团队；在用多插件、担心下游监听器被短路的开发者。
不适合：不用 DeepSeek Harness 的人——只对 DSH 生态有效；把网络策略当万能出站闸门的人——它管的是 shell 子进程流量，宿主进程自身的请求不在其列；部署在国内、插件所需外部网络无法到达的机器。
标签：dsh-permission-rules、DeepSeek Harness、权限规则、allow-deny-ask
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。