dsh 安全性ガイド：サンドボックス・承認・シークレット管理

脅威モデルを一文で

プラグインはエージェントの権限で動くコード であり、エージェントはコマンドを実行し、ファイルを編集し、ネットワークに届きます。セーフティモデルが存在するのは、バグのある、あるいは悪意のあるプラグイン（または言いくるめられたモデル）が、音もなく被害を出せないようにするためです。

DeepSeek Harness は 4 つの層でこれに対処します。サンドボックス、承認、ガード、シークレットの扱いです。

サンドボックス：正直な 3 段階

すべてのセッションはプロセスサンドボックスの内側で動きます。3 つの段階があります。

隔離は可能な環境では OS ネイティブです。Linux では bwrap/Landlock、macOS では Seatbelt、Windows では ACL 制限トークン。そしてバックエンドは 正直 です。約束した隔離を実際に提供できたかどうかを報告するので、適用に失敗した段階は、黙って成功を装うのではなく可視化されます。

承認：リスクのあることの前に聞く

サンドボックスとは独立に、リスクのある操作は承認システムを通ります。エージェントが一時停止し、あなたが決めます。何がリスクに数えられるかはポリシープリセットで調整でき、「ほぼすべて確認」から「サンドボックス外だけ確認」まで 1 つの設定で変えられます。

実践的な習慣：厳しめで始め、エージェントの振る舞いを見てから緩める。承認プロンプトのコストは 1 クリックですが、監督なしのワークスペース外への書き込みは午後ひとつを持っていきかねません。

ガードとタイムアウト

暴走を自動で捕まえる仕組みが 2 つあります。

• タイムアウト ―― ハングしたツール呼び出しは、ターンを永遠にブロックする代わりに中断されます。
• ループ検出 ―― 進捗のない反復パターン（同じ失敗コマンドの繰り返し）をガードが検出し、サイクルを中断します。

プラグインは、すべてのツール実行とモデルリクエストの前後のインターセプトポイントに独自のガードを追加できます。その継ぎ目は プラグイン開発ガイド に書かれています。

シークレットの行き先

認証情報（API キー、トークン）は セッションログとは別のチャネル を通ります。ログに記録されるのは参照であって値ではありません。つまり、共有・エクスポートされたセッションからキーは漏れません。

知っておく価値のあるデフォルトがあと 2 つ。

• セッションログはデフォルトではどこにもアップロードされません。テレメトリはオプトインです。
• モデルにはチャットに貼ったものが見えます。だからシークレットをメッセージ本文に貼らないでください。ツールがプロバイダー側の認証を提供しているなら、そちらを優先しましょう。

新しいものを試すときのチェックリスト

1. read-only で始め、見たものを信頼できたら workspace-write へ上げます。
2. インストール前にプラグインのソース、ライセンス、権限を読みます。インストールガイド がこれをルーチンにしてくれます。
3. 新しいプラグインはメインプロジェクトではなく使い捨てワークスペースで試します。
4. 最初の承認プロンプトを観察します。プラグインが何をしようとしているかが正確にわかります。
5. 何かおかしければ、セッションを止め、プラグインエントリーを削除し、リポジトリに報告します。

既知のセキュリティ開示と、その読み方

公式ディスカッションにはサンドボックス関連の公開開示が 2 件あります——どちらも責任ある形で報告され、特定の構成にのみ影響し、dsh の使用をやめる理由にはなりません。ただし、最新版を追う理由にはなります。

• **#8887（2026-10-05、重大度：高）：**dsh 自身のローカルコントロールプレーン 127.0.0.1:3080 を経由するサンドボックス脱出と承認ポリシー迂回の連鎖——サンドボックス化されたセッション内の 1 コマンド（read-only のファイルポリシー下でも）で、ユーザー権限の任意ファイル書き込みに至りました。0.2.0-rc.2 で検証済み。
• **#9026（2026-10-06）：**ルートを / にしたセッションやワークスペースはサンドボックスのパス検査を通過し、強制系バックエンドすべて（bwrap、Landlock、sandbox-exec）でファイルシステム全体の読み書きを得ます。

実務的な読み方：サンドボックスは強化であってセキュリティ境界ではない。Web UI はデフォルトのループバックバインドのままにし、ポート 3080 を管理外のネットワークへトンネルせず、価値あるものを置いたマシンでサンドボックスセッションを信頼できないコンテンツに向けず、修正が着地したら更新する。トラブルシューティングページが両スレッドを追跡しています。

よくある質問

サードパーティの dsh プラグインを入れても安全？ 信頼できないコードを安全にする魔法はありません。上の層ができるのは 封じ込め です。審査したプラグインを使い捨てワークスペースの read-only で試し、次に workspace-write へ昇格させるのは合理的なリスクです。未審査のプラグインを danger-full-access で動かすのは違います。完全な審査ルーチンは インストールガイド にあります。

プラグインに API キーを盗まれることはある？ キーは別チャネルを通り、セッションログには入らないので、ログを読んだり共有したりしても漏れません。ただしプラグインはエージェントの権限で動きます。だからこそインストール前にソースを読み、チャットにシークレットを貼るよりプロバイダー側認証を選ぶべきなのです。

デフォルトではどのサンドボックス段階を使うべき？ 日常作業は workspace-write、レビュー・監査・新しいものとの初接触は read-only。danger-full-access は sudo と同じように扱ってください。意図的に、監督つきで、短時間だけ。

dsh に既知のセキュリティ脆弱性はありますか？ あります——公式ディスカッションに記録された公開開示が 2 件（#8887、ローカルコントロールプレーンからの脱出と承認バイパス。#9026、ルートが / のワークスペースでサンドボックスが無効化）あり、いずれも 2026 年 10 月のものです。恐慌の理由ではなく、Web UI をループバック限定に保ち速やかに更新する理由だと捉えてください。詳細は上のセクションとトラブルシューティングページへ。

dsh はセッションを勝手に送信しますか？ セッションログはデフォルトでローカルに留まり、テレメトリはオプトインです。チャットに貼ったものはモデルプロバイダーへ行きます。ログのポリシーはモデルが見るものを変えません。

次に読む

• 信頼できるプラグインのインストール方法
• DeepSeek Harness とは？
• dsh プラグインのエコシステム