DeepSeek Super Agentを安全にセットアップする方法：アカウント、権限、分離

dsh-superagentの実験を、普段使っているアカウントで始めたり、重要な本番リポジトリに対して行ったりしないでください。デプロイ文書によると、ルーターとワーカーの両方のプリセットは、オペレーティングシステムのユーザーとしてdanger-full-accessで実行され、そのユーザーのホームディレクトリを読み取る可能性があります。インストールやテストを始める前に、専用アカウントと使い捨てのリポジトリを用意してください。予想外の動作が最初に起きてからでは遅すぎます。

公開リポジトリにあるのは研究用プロトタイプであり、DeepSeekの公式な本番対応製品ではありません。このガイドでは、文書に記載されたデフォルト設定を、安全を重視したセットアップ計画にまとめています。具体的には、IDの分離、リポジトリへのアクセス範囲の制限、レビュー済みの許可ルール、制御された実行、停止手順のテストです。認証情報は、自分で承認したターミナルまたはシークレット管理の手順からのみ入力し、チャットには絶対に入力しないでください。

dsh-superagentは本番環境で使える段階か？

READMEには、これは研究用コードであり、公開されている実装は内部システムや関連する設計記事の一部のアイデアとは異なると明記されています。導入を判断する際には、この位置付けをはっきり示す必要があります。一般公開されているからといって設計を検証できる機会にはなりますが、機密性の高い運用に適したコードである保証にはなりません。

このガイドは、2026年11月5日時点のリビジョン 8c32a9dc5d72c033816c6a8110b37f40cf94fba4に基づいて確認しました。実際にレビューするリビジョンを固定し、記録してください。その後チェックアウトを更新する場合は、再度実行する前に、前提条件、権限、プリセット、設定の移行を再確認してください。

セットアップ文書では、対話形式で計画を立て、確認してから進めるワークフローが説明されています。実行前に計画を確認してください。コーディングエージェントにセットアップを手伝わせる指示を、無関係な認証情報へのアクセスや、普段使っている作業プロファイルへのインストールを許可するものと解釈しないでください。

最初の受け入れ目標は控えめに設定しましょう。無害なリクエストを1つ送ると、内容がわかりやすいタスクと、使い捨てのリポジトリでレビューできる結果が得られることを確認します。拒否と停止の動作もテストしてください。正常に完了する一連のデモに成功しても、本番環境での信頼性が証明されるわけではなく、すぐにアクセス範囲を広げてよい根拠にもなりません。

専用のオペレーティングシステムアカウントを使う理由

デプロイガイドでは、ホストへのアクセスに関する前提が明示されています。セッションディレクトリや認証情報を扱うラッパーを分けても、プロセスは分離されません。ワーカーは、実行アカウントに許可されたプログラムを実行し、ファイルにアクセスできます。これには、そのアカウントのホームディレクトリも含まれます。

実験に必要なファイルと認証情報だけを含む専用アカウントを作成してください。個人用SSHキー、クラウド管理者の認証情報、ブラウザープロファイル、本番環境の設定、無関係なリポジトリは、そのアカウントがアクセスできる環境の外に置いてください。アカウントのホームディレクトリだけでなく、グループへの所属やマウントされたストレージも確認してください。

より強固に分離するには、使い捨ての専用仮想マシンや、同様に制御されたホスト環境を検討してください。ファイルシステムの見え方が異なるというだけで、コンテナで十分だと考えてはいけません。実際の境界を決めるのは、マウント、権限、ソケット、ネットワークです。ホストと実行するコードの価値に応じて、デプロイ方法を決定してください。

アーキテクチャの概要では、これらの制御を異なるレイヤーに置く理由を説明しています。レイヤーを分けておけば、リクエスト元を少数に限定するといった限定的な保護策を、包括的な隔離策と取り違えずに済みます。

表紙：dsh-superagentのプロトタイプ用リポジトリ、GitHubが生成したリポジトリカード。リポジトリのメタデータは特定の日付時点の参考例であり、普及状況や性能を示すものではありません。

GitHubエージェント用のIDを作成する方法

現在のプロトタイプで必要とされている、専用のGitHubユーザーアカウントを使用してください。個人アカウントは使わないでください。デプロイガイドによると、この実装はそのアカウントの通知を読み取る仕組みで、エージェントのIDとしてGitHub Appを代用することには対応していません。これは実装上の制約であり、他のシステムでGitHub Appsを使わないよう一般に推奨するものではありません。

最初は使い捨てのテスト用リポジトリだけにアクセスを許可します。エージェントのログイン設定は自分のものと分けてください。文書化されたラッパー方式か、同等の承認済み設定を使用し、プロセスに動作を許可する前に、CLIがどのアカウントを使用しているか確認します。チャットの表示名から本人だと推測しないでください。

GitHubのトークンに関するガイダンスでは、権限と有効期限の選択肢が説明されています。プロトタイプで文書化された操作に必要な、サポート対象の最小限のアクセス権を選び、互換性要件を確認し、失効手段を確保してください。便宜上、そのアカウントに組織の管理権限や本番環境へのデプロイ権限を与えることは避けてください。

初期の実験では、マージは人に任せます。エージェントにブランチをプッシュしてプルリクエストを作成する権限があっても、リポジトリの保護設定を変更したり、自分の作業を承認したりする権限まで必要ではありません。独立した承認判断を保ちながら、誰が作成したかが明確になるIDを使用してください。

許可ユーザーリストと受け付けポリシーはどのように機能するのか？

認可ドキュメントでは、明示的なリクエスト、推定候補、受け付けられない入力を区別しています。許可されたIDと、範囲ごとの受け付け設定の両方が重要です。許可リストを短くするのは有効ですが、それだけを唯一の制御手段と考えず、受信範囲やルールと併せて見直してください。

まず、既知の依頼者1人とリポジトリ1つで始めます。テストにFeishuが不要なら、設定しないでください。ソースを追加するたびに、本人確認、受信範囲、ボットの動作、作業を開始する権限を確認すべき場所が増えます。最初のワークフローを理解してから、ソースを追加してください。

無害な例でポリシーの動作をテストします。許可された人がエージェントに話しかけた場合、無関係な話題が投稿された場合、既存のタスク範囲外の作業を求める追加のリクエストがあった場合に、それぞれ何が起きるか確認してください。目に見える返信がないからといって何も実行されていないと思い込まず、判断の記録を調べてください。

リポジトリの内容や引用されたメッセージは、ポリシーの更新ではなく、根拠として扱う必要があります。課題やドキュメントに埋め込まれた指示によって、アクセス権がひそかに付与されたり、作業を依頼できる人が変更されたりしてはなりません。proactive-agentの比較では、イベントに接続されたワークフローで、単一の監督付きチャットセッションよりもこの区別が重要になる理由を説明しています。

なぜ最初にObserveモードを使うのか？

文書化されたデフォルトのobserveモードでは、システムは推定候補を評価し、自動的に受け入れずに、受け入れられる候補を記録します。設定したルールの動作を確認するのに役立ちます。許可された明示的なリクエストの実行は妨げないため、全体的な読み取り専用モードやアクションを一切行わないモードではありません。

監視中も、実験に与える技術的な権限は必要最小限にしてください。価値のある変更を許可せずにルーティングを調べることが目的なら、使い捨てのリソースを利用し、ホストとリポジトリの設定によってその境界を強制してください。プロセスがすでにアクセスできる資産を、モード名だけで保護できると考えないでください。

許可と拒否の両方の判断をレビューしてください。許可しすぎるルールは意図しない作業を引き起こす一方、許可が少なすぎるルールは想定されたタスクを気づかないうちに取りこぼす可能性があります。ポリシーを編集する前に、期待した結果と実際の結果が異なる理由を記録してください。デモがうまくいくまでルールを繰り返し広げるのは、安全なデフォルトを確立する方法として適切ではありません。

通常のインストール手順としてautoに切り替えないでください。このモードでは、一致するルールに基づいて推定された作業を開始するシステムの能力が高まります。その後、範囲を広げる場合は、責任者を明確にし、ルールセットをレビューし、評価記録を管理し、アクセスを停止または取り消す方法を検証してください。

トークン、シークレット、ローカルファイルを保護するには？

認証情報は、プロンプト、リポジトリ内のファイル、スクリーンショット、通常のログに含めないでください。専用環境で、承認済みの CLI サインインまたはシークレットストレージを使用してください。OWASP のシークレット管理ガイダンスではアクセス制御やライフサイクルについて解説していますが、まず満たすべき要件は簡単です。エージェントの環境には、タスクに関係のない認証情報を一切置かないでください。

GitHub の ID だけでなく、モデルプロバイダーへの接続経路も確認してください。コードやプロンプトは設定されたプロバイダーで処理されることがあり、ツールによって接続先がさらに増える可能性もあります。ローカルにチェックアウトしても、推論やデータ処理がローカルまたはローカル限定になるとは限りません。選択したプロバイダーとログ設定が、テスト対象のデータに対して承認済みであることを確認してください。

セットアップを簡単にするために、個人用のホームディレクトリやシェル設定を専用アカウントにコピーしないでください。認証情報ヘルパー、環境変数、クラウド設定、非公開の履歴まで持ち込まれる可能性があります。必要最小限の依存関係を意図的に再構築し、追加したものは機密情報を含まない一覧に記録してください。

当社のpersonal-agent アクセスチェックリストは、関連する準備手順をまとめたものです。初回の実行前に、エージェントの実際の環境から、どのディレクトリ、認証情報、サービス、ネットワーク接続先にアクセスできるかを確認してください。その範囲がテストに必要な範囲を超えている場合は、先にアクセス境界を調整してください。

リポジトリを分離して変更をレビューするには？

本番環境のシークレットを含まない、合成サンプルだけの使い捨てリポジトリを使用してください。セットアップドキュメントには、互換性のあるバージョンのNode.js、pnpm、Git、tmux、Python、GitHub CLI、DeepSeek Harnessなどの前提条件が記載されています。古いコマンド一覧から任意のバージョンをインストールするのではなく、現行のpackage.jsonとセットアップガイドで正確な互換性を確認してください。

インストール計画を実行する前に、次の準備手順に従ってください。

1. 専用アカウントまたは使い捨てホストを用意し、アクセス範囲を確認してください。
2. 適切な制限付き権限を設定して、専用のGitHubアカウントとテスト用リポジトリを作成してください。
3. プロトタイプを取得し、そのリビジョンを記録したうえで、セットアップおよびデプロイに関するドキュメントを確認してください。
4. 提案されたインストール計画、モデルプロバイダー、プロファイル、状態の保存場所、認証情報の仕組みを確認してください。
5. 最初の試行では、GitHubからの入力のみを許可し、依頼者を少数に限定し、observeを設定して、自動マージを無効にしてください。
6. レビュー済みの設定を起動し、正常性とセットアップ要件を確認してください。
7. 許可された無害なタスクを1件送信し、実行後の状態と変更案を確認してください。
8. アクセス範囲の拡大を検討する前に、無関係な入力、範囲の拡大、停止手順を試してください。

セットアップ後は、以下のステータスコマンドが役立ちます。

scripts/dsh-superagent status

レビュー済みのチェックアウトを、専用環境から実行してください。出力は現行のデプロイガイドに従って解釈してください。プロセスが動作中であることは、ソースやポリシーが健全で、正しく設定されていることを意味しません。

保護ブランチの要件と人によるレビューを維持してください。差分、開始時と最終時のリビジョン、テスト、未解決の前提を確認してください。重要なデータは独立したコピーを使ってください。書き込みアクセスを許可する前に復旧計画を立てておく必要がある理由は、復元可能なファイルのガイドで説明しています。

エージェントを停止してアクセス権を取り消すには？

最初のタスクを開始する前に、停止手順を文書化してください。現行のデプロイガイドには、正常停止のコマンドが記載されています。

scripts/dsh-superagent stop
scripts/dsh-superagent status

正常な停止では、実行が落ち着くまで待つことがありますが、外部への影響がすべて取り消された証拠にはなりません。未完了の作業と関連するリポジトリのアクティビティを調査してください。プロセスが何をしているか把握せずに、無関係なセッションを強制終了して済ませないでください。

アクセスインシデントが発生した場合や実験を中止する場合は、該当するプロバイダーの管理機能を使って、専用の認証情報を無効化し、リポジトリへのアクセスを取り消してください。新たなタスクの受け付けを停止し、残っているバックグラウンドプロセスやサービスを調査してください。チームが事態を再構成できるよう、影響を受けたタスク、リビジョン、関連するアクティビティについて、機密情報を含まない記録を残してください。

クリーンアップと復旧は別々の作業です。ローカルディレクトリを削除しても、トークンは失効せず、リモートのプルリクエストは閉じられず、プッシュ済みの変更も取り消されません。各成果物をどう扱うか個別に決め、削除する前に必要な証拠を保持してください。停止、失効、復旧の手順が、起動の手順と同じくらい明確になってから実験範囲を拡大してください。

結果そのものについては、agentic-autofixのレビュー手順を使用してください。プロセスが正常に動作し、タスクが受け付けられたことは運用上のシグナルにすぎず、提案されたパッチをマージすべきだという根拠にはなりません。

よくある質問

普段使っている開発者アカウントでプロトタイプを実行できますか？

そうすると、そのアカウントからアクセスできるファイルや認証情報がプロセスに公開されます。特に、すべてのアクセスを許可するプリセットが文書に記載されていることを踏まえ、最初の実験には専用の制限された環境を使用してください。

観察モードにすればプロトタイプは読み取り専用になりますか？

いいえ。推測された候補の受け付けは制限されますが、明示的に許可されたリクエストは引き続き実行できます。それがテストの目的なら、権限によって書き込みを禁止してください。

専用のユーザーアカウントの代わりにGitHub Appを使えますか？

調査したプロトタイプのデプロイガイドでは、通知ワークフローのためにユーザーアカウントが必要とされています。互換性に関するこの制約が変わっていないと決めつける前に、後続のリビジョンを再確認してください。

セットアップ用トークンを支援エージェントとのチャットに貼り付けてもよいですか？

いいえ。管理下にあるご自身の環境で、承認済みのCLI認証またはシークレットストレージを使用してください。セットアップの過程で、シークレットの値を会話にさらす必要はありません。

最初の試行範囲を拡大しても安全だと判断できる根拠は何ですか？

単一のテストで全般的な安全性が証明されることはありません。タスクの受け付け判断、権限の境界、変更案、停止時の挙動、復旧の証拠を確認し、追加する範囲を具体的に限定して許可してください。

結論

dsh-superagentを安全にセットアップするには、実際の動作上の前提を理解することから始めます。つまり、研究段階であること、ホストユーザーの権限ですべてのアクセスを許可して実行されること、そして観察モードでも明示的な作業は実行できることです。プロトタイプの動作を学ぶには、専用のアカウント、使い捨て可能なリソース、独立したレビューが前提となります。

最初のタスクは範囲を絞り、成功だけでなく拒否や停止も意図的にテストし、承認したすべての変更について根拠を残してください。新たなレビューなしに認証情報や権限を徐々に追加して、有用な調査実験を本番環境への導入に変えてはいけません。