2026 DeepSeek Harness Mac サンドボックスは安全か：Seatbelt 受け入れチェックリスト
Seatbeltを使うMac上のDeepSeek Harnessは、ファイル書き込みの防護としては採用できますが、完全なホスト・ネットワーク・プロセス隔離とは扱えません。受け入れ条件は、read-onlyまたはworkspace-writeが実際に効き、境界外の書き込みが拒否され、ランナー障害時に実行が停止し、権限拡大が明示承認を要求することです。個人管理の信頼できるコードなら本機で進められますが、不審なリポジトリや機密キーを扱うタスクは専用リモートMacか、さらに強い隔離環境へ移します。
個人開発者は、日常の作業フォルダーをAgentに渡す前の確認に使えます。セキュリティ・プラットフォーム担当者は、Seatbeltの能力を実行可能な検査項目へ変換できます。チーム責任者は、共有Mac、専用リモートMac、より強い隔離環境のどれを選ぶか判断できます。
※ 最終更新：2026年8月21日。バージョン、サンドボックス仕様、Providerの扱いは、公式Release一覧、公式サンドボックス仕様、公式Harnessページを基に確認しています。developer previewのため、互換性を壊す変更が入り得ます。
合格ラインと適用範囲
DeepSeek HarnessのMacローカルバックエンドは、Seatbeltとsandbox-execを利用します。後者はAppleからdeprecatedと扱われていますが、現時点ではmacOSに提供されています。将来の削除は確定事項ではありません。プロジェクトの公式文書も、この実装に依存する場合は環境確認が必要だと示しています。Appleのサンドボックス設計資料も、サンドボックスをOSリソースへのアクセス制御として説明しており、Agent全体の安全性を保証するものではありません。
最低限、次の4項目を満たさない環境は本番運用に進めません。
- 制限モードが表示だけでなく実際の実行に適用されている
- 作業フォルダー外への書き込みが拒否される
- サンドボックスランナーが利用不能なら、非隔離実行へ切り替わらない
danger-full-accessなどの広い権限は、理由と承認なしに使えない
DeepSeek HarnessはMITライセンスですが、モデル呼び出し、自社運用の推論環境、Macの利用費まで無料になる意味ではありません。ライセンスと運用コストは分けて評価します。
ファイル境界の検査
公式文書上のread-onlyは、Agentによる変更範囲を抑えるためのモードです。workspace-writeは指定したワークスペースへの書き込みを許可する設計です。一方、danger-full-accessは制約を外すため、頻繁な拒否を解決する通常設定にはできません。詳細なポリシーの解釈は公式ポリシー解析文書に従います。
| 検査対象 | read-only | workspace-write | 合格記録 |
|---|---|---|---|
| ワークスペース内の既存ファイル | 読み取り結果を確認 | 変更可否を確認 | 実体パス、コマンド、結果 |
| ワークスペース外のファイル | 書き込み拒否を確認 | 原則として拒否を確認 | 拒否エラーと対象パス |
| テンポラリ領域 | 読み書きの扱いを個別確認 | OS・ポリシー依存の結果を記録 | 実際の保存先 |
| 相対パス・シンボリックリンク | 解決後の境界を確認 | 解決後の境界を確認 | 表面上と実体の両方 |
検査は次の順番で実施します。
- 専用の検証用ワークスペースと、その外側にある検証用ファイルを用意します。
- read-onlyで、ワークスペース内の読み取り、内側への書き込み、外側への書き込みを別々に実行します。
- workspace-writeに切り替え、同じ3操作を繰り返します。
4.テンポラリ領域への保存と、相対パス、..、シンボリックリンク経由の書き込みを検査します。 - コマンド、解決後の絶対パス、ポリシーモード、終了結果、エラー本文を記録します。
- 実行後にファイルのハッシュと更新時刻を確認し、拒否されたはずの対象に変更がないことを確認します。
ここで重要なのは、../outside.txtという文字列を拒否したかではありません。リンクや相対指定を解決した後、どのファイルへ到達したかが検査対象です。表面上のパスだけをログに残す検証は不十分です。
失敗時の停止動作
通常のコマンド失敗と、ファイルアクセス拒否と、ランナー障害は別の結果です。公式Shellサブシステム文書とサンドボックス仕様を参照し、受け入れ記録でも別分類にします。
| 事象 | 見るべき結果 | 不合格となる挙動 |
|---|---|---|
| コマンド自体の失敗 | コマンドの終了結果 | 原因不明の再実行 |
| 禁止パスへのアクセス | ファイルアクセス拒否 | 別経路で自動再実行 |
| sandbox-execの欠落・実行不能 | SANDBOX_UNAVAILABLE |
非隔離モードへの移行 |
| ポリシー設定の拒否 | ランナー失敗として停止 | 危険な既定値で続行 |
sandbox-execを実行できない状態、ポリシーを適用できない状態、ランナーが設定を拒否する状態を意図的に作り、コマンドが実行されないことを確認します。公式実装が掲げるfail-closedが、実際の環境でも成立するかが判断点です。
注意：エラーが表示されたことだけでは合格になりません。
SANDBOX_UNAVAILABLEが返り、対象コマンドが隔離なしで実行されていないことまで、プロセス記録とファイル差分で確認します。
権限拡大の扱い
Agentがより広いsandbox_permissionsを要求する場合、要求理由が具体的であることが必要です。「ビルドに必要」だけでは足りません。対象パス、必要な操作、今回だけ必要なのか、拒否した場合の代替策を承認画面または監査ログに残します。
受け入れ試験では、次の4ケースを分けます。
- 拒否した場合：コマンドは実行されない
- 利用者がキャンセルした場合：コマンドは実行されない
- 承認サービスが利用不能な場合：安全側へ停止する
- 承認した場合：今回の呼び出しだけが広い権限で実行される
一度承認した権限が、後続の別コマンドへ自動継承されないことも確認します。danger-full-accessは例外対応として監査対象にし、拒否が多いからという理由で常用しません。
自社運用モデルと認証情報
Seatbeltがファイル書き込みを制限しても、モデルへのリクエスト、ネットワーク接続、APIキーの保管まで安全になるわけではありません。自社運用のDeepSeek V4やOpenAI互換エンドポイントを接続する場合、Harnessを動かすMacと推論エンドポイントを別コンポーネントとして図にします。
公式Provider設定ガイドに基づき、少なくとも次を確認します。
- base URLがどこから読み込まれるか
- Provider IDがプロジェクト設定で変更可能か
- APIキーが環境変数、秘密管理機能、設定ファイルのどこに存在するか
- リクエストログ、エラー、シェル履歴にキーが残らないか
- 作業フォルダー内の編集可能な設定で、信頼済み端末へ接続先を差し替えられないか
受け入れのポイントは、Agentに見せる作業領域と、推論端末へ接続する秘密を同じ場所に置かないことです。プロジェクト設定が編集可能なら、認証情報はその設定から参照できない仕組みにします。接続先の変更が必要な場合は、作業フォルダー外の管理設定と明示承認を使います。
本機運用と専用Macの分岐
安全性の判断は、サンドボックスのモード名だけでは決まりません。コードの信頼度、共有利用者、連続稼働、認証情報の機密度、障害後の復旧方法を組み合わせます。
| 条件 | 管理された本機 | 専用リモートMac | より強い隔離環境 |
|---|---|---|---|
| コードの信頼度 | 自作・レビュー済み | チーム管理済み | 不審・未検証 |
| 利用者 | 単独 | 限定されたチーム | 多数・不特定 |
| 認証情報 | 低機密 | 分離保管 | 高機密・強い監査が必要 |
| 障害復旧 | 手動で可能 | 再構築手順あり | 使い捨て・復元可能 |
| 採用判断 | 4項目の検証後 | 専用アカウントと限定ディレクトリ | Mac単体のSeatbeltで証明できない場合 |
個人の信頼できるプロジェクトで、4つの最低条件をすべて満たすなら本機運用が現実的です。共有チームの継続運用では、専用のリモートMacに利用者、作業領域、認証情報を分ける方が監査しやすくなります。
不可信コード、境界を証明できないランナー、物理的な分離が必要な秘密を扱う場合は、導入を止めます。Macを変えるだけで解決しない場合は、より強い隔離方式を選びます。既存環境のMac上のAgent認証情報管理も、サンドボックス検証とは別の項目として確認してください。
受け入れ記録の残し方
受け入れ表には、実行日時、Harnessの版、macOSの版、モード、実体パス、コマンド、終了結果、承認者、ファイル差分を残します。公式Releaseでは、2026年8月19日時点の最新可視版がv0.1.0-rc.8のプレリリースです。Releaseページで版を固定し、正式版が出た場合は同じ試験をやり直します。
developer previewの間は、互換性を壊す変更を前提に運用します。正式版、バックエンド変更、ポリシーの意味変更、macOSでのsandbox-exec提供状況の変化があれば、過去の合格記録をそのまま流用しません。
よくある確認
作業フォルダー外の書き込み
read-onlyとworkspace-writeの差は、許可された書き込み範囲です。どちらも「パス文字列を見ているだけ」と考えず、解決後のファイル、リンク先、テンポラリ保存先を確認します。外部書き込みが成功した場合は、Agentの指示内容ではなくポリシー適用そのものを調査します。
sandbox-exec障害時の挙動
sandbox-execがない場合に重要なのは、エラーの見た目ではなく実行停止です。SANDBOX_UNAVAILABLEの返却、子プロセスが起動していないこと、ファイル差分が発生していないことをセットで記録します。自動的な非隔離フォールバックがあれば、導入を止めます。
DeepSeek V4の端末とキー
自社運用のDeepSeek V4へ接続する際は、Agentのワークスペースから認証情報を読み書きできない構成にします。base URLとProvider IDを編集可能なプロジェクト設定に任せず、管理領域、秘密管理機能、承認済みの実行環境で管理します。ログのマスキングも必須です。
運用環境を見直す判断
現在のMacが共有利用で、長時間稼働し、作業領域の初期化もできず、推論用キーを同一ユーザーが扱っているなら、Seatbeltだけで補う設計には限界があります。利用者間の権限が混ざること、障害後に汚染状態を戻せないこと、監査ログを分離しにくいことが実際の弱点です。
その条件では、専用のリモートMacへHarnessを移し、作業ディレクトリと秘密を分離する方が管理しやすくなります。必要な環境のMacレンタル料金を確認し、短期検証なのか継続運用なのかを分けて比較してください。既存Macで境界試験、権限試験、fail-closed試験を完了できない場合は、移行を急ぐより先に検証可能な専用環境を用意するのが安全です。
低リスクの個人作業なら本機、共有チームと継続稼働なら専用リモートMac、不可信コードや高機密情報ならさらに強い隔離環境。この分岐で判断すれば、Seatbeltを過大評価せずにDeepSeek Harnessを運用できます。現在のMacでこの条件を満たせない場合に限り、ProxyMacのリモートMacを一時的な検証環境、または専用運用環境として比較する価値があります。
