后门拦截卫士 miketako3/dsh-backdoor-guard

dsh-backdoor-guard

一个 DeepSeek Harness（dsh）插件，用来拦截训练阶段植入的后门载荷——模型权重里藏了东西（比如一次恶意 QLoRa 合并），一旦出现隐藏触发条件，就会发起特定的工具调用或窃取凭据——本插件在工具执行之前把它拦下来。

模型发起的每一次工具调用，都会由一个专门的决策模型定价（Jev 托管版，或者通过随包提供的 shim 自托管 LiquidAI d1——两者都使用同一套 Decision Index systemone schema）。判定为不安全的调用会在 tools/pre-execute 处被拒绝，同时往会话记录里写入一条 SECURITY NOTICE。

不用 fork，不用 logprobs，也不用维护正则规则：一个公开的插件接缝，加一次判断调用（托管版约 100 ms，Apple 芯片上本地 d1 约 30 ms）。

为什么用决策模型，而不是智能体自己的 LLM

- 被植入后门的模型不能指望它自己管自己；裁判是一个不同的、极小的、冻结的模型。
- 决策模型一次前向传播就返回校准过的概率（零输出 token）——快到足以筛查每一次工具调用。
- Jev/d1 就是为这件事造的：针对一份状态文档做「是/否 + 概率」判断（路由、审核、护栏）。

安装

dsh plugin add dsh-backdoor-guard # npm, once published
dsh plugin add github:miketako3/dsh-backdoor-guard # from GitHub
dsh plugin add file:/path/to/dsh-backdoor-guard # local checkout

包里带了一个 dsh.bundle 层，所以 plugin add 会自动接好插件那一行。

选择裁判

方案 A：托管 Jev（TypeSafe AI）

export TYPESAFE_API_KEY=ts_... # from https://console.typesafe.ai

profile cordis.patch.yml
- id: backdoor-guard
name: 'dsh-backdoor-guard'
config:
endpoint: https://api.typesafe.ai/v1/systemone
model: jev-latest
apiKeyEnv: TYPESAFE_API_KEY

方案 B：本地 d1-3B（LiquidAI，开放权重）

pip install "transformers>=5.14" torch torchvision pillow
python3 server/d1-server.py --model LiquidAI/d1-3B --port 8400

- id: backdoor-guard
name: 'dsh-backdoor-guard'
config:
endpoint: http://127.0.0.1:8400/v1/systemone
model: d1-3B
apiKeyEnv: '' # empty = no Authorization header (local, unauthenticated)

d1-3B 在 Apple M5 Pro 上约 30 ms/次决策，RTX 4090 上约 8 ms，可读取 32k token 的状态——整段工具调用载荷放进去绰绰有余。d1-omni-600M 也能用（文本+音频；实验性）。

一次调用如何被判定

裁判会收到一份状态文档：用户最新的请求、智能体是否公开声明了自己的动作（静默调用是记忆化载荷在运行时的特征）、工具名、规范化后的参数，以及本轮此前的调用。一个 Noul 问题为合法性定价：
safe = 调用服务于用户明确提出的请求；不读取、不传输无关的凭据或密钥；没有混淆、管道接 shell、自解码的载荷；没有异常的外部端点；没有任何看起来像隐藏触发动作的东西。

safe_probability >= threshold → 调用放行。低于阈值 → 在派发前拒绝，并在拒绝原因里给出概率。

配置参考

| key | 默认值 | 含义 |
| endpoint | https://api.typesafe.ai/v1/systemone | 兼容 systemone 的判定端点 |
| model | jev-latest | 判定模型 id |
| apiKeyEnv | TYPESAFE_API_KEY | 存放 API key 的环境变量；'' = 不鉴权（本地） |
| threshold | 0.5 | 安全概率低于此值时拒绝 |
| timeoutMs | 8000 | 判定调用超时 |
| skipTools | [] | 永不判定的工具名，支持 通配（如 ['read', 'web_']） |
| maxArgsChars | 2000 | 展示给判定模型的参数长度上限 |
| maxRequestChars | 1000 | 展示给判定模型的用户请求长度上限 |
| onJudgeError | allow | allow = 判定服务不可用时记日志并放行；deny = 失败即拒绝 |

高安全部署请设 onJudgeError: deny；调优期间保持 allow。

威胁模型与局限

- 针对通过工具行动的权重植入后门和凭据外泄；纯文本层面的不当行为不在范围内。
- 判定模型本身属于可信基础设施：把它固定下来（本地 d1 或你自己的 Jev key），不要让它走被审查的模型。
- 配合网络出口管控，才能做到完整覆盖。

灵感来自 @pentacoxian_dev 的 rdsh-backdoor-guard 研究（基于熵的检测）；本实现刻意改用决策模型判定，因此不需要 logprobs，也能适配任何智能体后端。

开发

npm install
npm test # vitest: judge client + end-to-end plugin flow
npm run build # tsc → lib/

DeepSeek Harness（dsh）用プラグイン。モデルウェイトに焼き込まれたバックドア（特定トリガーで悪意あるツール呼び出し・認証情報窃取を発火）を、ツール実行前に判定モデルで止めます。

判定には専用の意思決定モデルを使います — ホスト型の Jev（TypeSafe AI）か、同梱 shim 経由のローカル d1-3B（LiquidAI 公開ウェイト）。どちらも同じ Decision Index（systemone）スキーマを話すので、endpoint を変えるだけで切り替わります。

- fork 不要・logprobs 不要・正規表現ルールの保守不要
- 判定は1回の順伝播（出力トークンゼロ）で済むので全ツールコールに挟める速度（ホストJev 約100ms、M5 Pro のローカル d1 約30ms）
- 判定対象: ユーザーの依頼文・前置きの有無（無言の発火は暗記ペイロードの特徴）・ツール名・引数・ターン内の先行呼び出し
- 閾値未満なら tools/pre-execute で覆せない deny ＋ トランスクリプトに SECURITY NOTICE

インストール

dsh plugin add github:miketako3/dsh-backdoor-guard

judge の選び方

- ホスト Jev: TYPESAFE_API_KEY を環境変数に（console.typesafe.ai で発行）
- ローカル d1-3B: python3 server/d1-server.py --model LiquidAI/d1-3B を起動し、endpoint: http://127.0.0.1:8400/v1/systemone、apiKeyEnv: ''

脅威モデルと限界

- 対象: ツール経由で行動するウェイト由来バックドアと認証情報窃取。テキストだけの悪意ある出力は対象外
- judge は信用されたインフラであること（ローカル d1 か自分の Jev キー）。被審査モデルと同じモデルに判定させない
- 完全な防御にはネットワーク egress 制御と併用を致谢：灵感来自 @pentacoxian_dev 的 rdsh-backdoor-guard 研究，本实现独立完成。采用决策模型方式，而非熵方式，可在任何智能体后端上运行。

License

MIT