ガイド · 2026 年 11 月 10 日更新 · Cameron Voss および West Mao 著

DeepSeek SuperAgent セキュリティ: 権限、Observe モード、安全なセットアップ (2026 年 11 月)

GitHub リポジトリ上の研究プロトタイプを評価するための実用的なセキュリティ チェックリスト。

DeepSeek SuperAgent は、DeepSeek Harness に基づいて構築された研究プロトタイプであり、正式な DeepSeek 製品や運用準備が整ったソフトウェアではありません。別途構成されたモデルプロバイダーが必要です。このガイドは、公開されているドキュメントに従っています。この記事ではエンドツーエンドの導入を実行していません。

公開プロトタイプは、GitHub の会話全体でエージェントの作業を調整します。セキュリティ計画では、誰が作業を要求できるか、およびその結果のワーカーがどこまで到達できるかの両方を考慮する必要があります。この記事では、文書化された設計について説明し、限定的なトライアルを推奨します。これはセキュリティ認定や侵入テストの結果ではありません。

エージェントの実行時にアクセスできるものは何ですか?

公開された展開ドキュメントには、ルーターとワーカーのプリセットがサービスのオペレーティング システム ユーザーとして danger-full-access で実行されると記載されています。ワーカーはプログラムを実行し、そのユーザーが利用可能なファイルを読み取ることができます。また、エージェントの GitHub 認証情報を使用して、設定されたリポジトリと対話することもあります。

専用の GitHub ID は、属性の特定とリポジトリへのアクセスの制限に役立ちますが、ローカル プロセスは分離されません。チケットごとのディレクトリまたは Git ワークツリーにより、組織の変更が分離されます。ファイルシステム、ネットワーク、認証情報へのアクセスはブロックされません。

Observe モードは実際に何をするのですか?

observe から開始して、ルールが有用な作業やノイズの多い作業を生成するかどうかを検査します。これは、推定アクティビティのポリシー設定であり、すべてのエージェント アクションの予行演習スイッチではありません。許可されたユーザーのアドレス指定されたリクエストは、チケットを作成し、これらのモードのいずれかでワーカーを実行できます。

誰が仕事を始められ、誰が会話を続けられるでしょうか?

ホストは、新しいリクエストを許可するかどうかを決定するときに、ソース ポリシーと許可リストを適用します。エージェントに宛てた許可されたユーザーは、明示的なリクエストを行うことができます。他のメッセージは、ソース ポリシーに従って推定候補として評価される場合があります。

チケットがスレッドをサブスクライブすると、そのスレッド内のメッセージ (ボットや CI メッセージなど) がコンテキストとしてチケットに到達できるようになります。チケット自体が新しい権限を付与するわけではありません。チケットの権限によってその範囲が定義されます。ドキュメントには、終了したチケット自身のスレッド上のユーザーのメッセージは、送信者に関係なく、その作業を再開できるとも記載されています。パブリック リポジトリの場合は、サブスクライブされたスレッドに誰がマテリアルを投稿したり、マテリアルに影響を与えたりできるかを説明します。短いリクエスタ許可リストだけでは、その後のすべての入力が信頼されるわけではありません。

プロンプトインジェクションから身を守るには？

単一の設定でこの問題を排除することはできません。問題の本文、コメント、ログ、およびリポジトリ ファイルには、エージェントを制御すべきではない人からの指示が含まれている可能性があります。文書化された認可モデルは、これらのメッセージを権限の変更ではなく入力として扱いますが、モデルは依然として敵対的なコンテンツを誤解したり、すでに持っている権限の範囲内で動作したりする可能性があります。

• プライベート テスト リポジトリを使用し、トライアル中に投稿またはコメントできる人を制限します。
• 専用の OS ID と、トライアルに必要な認証情報とファイルのみを使用して実行します。ネットワーク アクセスが制限された、別個に管理される VM または同等の分離を検討してください。
• 本番環境のシークレット、デプロイメント認証情報、または無関係なプライベート リポジトリをワーカーの環境に置かないでください。
• デフォルト ブランチを保護し、マージ前に人間による差分とテストの検査を要求します。
• エージェント アカウントを監視し、認証情報を取り消してサービスを停止できるように準備してください。

これらはリスク軽減策であり、保証するものではありません。適切なコントロールは、リポジトリ、ホスティング環境、間違いの結果によって異なります。

最初のトライアルはどのように設定すればよいですか?

1. ターゲットを制限します。低リスクのテスト リポジトリと小さなドキュメント タスクを 1 つ選択します。
2. ID を分離します。エージェント専用の GitHub ユーザーと CLI 構成を使用します。そのユーザーにテスト リポジトリへのアクセスのみを許可します。
3. ホスト アクセスを減らします。 専用のオペレーティング システム アカウントを使用し、マウント、到達可能なサービス、環境変数、およびネットワーク アクセスを確認します。
4. ポリシーを設定します。 意図した要求者のみを許可し、observe での推定承認から開始します。
5. 人間によるレビューを継続します。 自動マージを無効にします。ブランチ保護を使用し、各 PR を確認して結果を確認します。
6. 境界をテストします。 チケットの状態、変更された実際のファイル、およびランタイムで使用できる認証情報を検査します。予期しない動作を記録し、範囲が不明瞭な場合は停止します。

ポリシーを変更すると、既存の作業はすぐに停止しますか?

必ずしもそうとは限りません。ドキュメントには、ポリシーの変更により影響を受けるライブチケットが通知されるが、アクティブなすべての権限が直ちに取り消されるわけではないと記載されています。作業を停止する必要がある場合は、プロジェクトの停止コントロールを使用し、アクティブなチケットと実行中のプロセスを検査し、必要に応じて資格情報またはアクセスを取り消します。設定の編集によってすべてのワーカーが停止したと仮定するのではなく、結果を検証してください。

SuperAgent は独自のプル リクエストをマージできますか?

プロジェクトでは、人間によるマージから始めることを推奨しています。追加のコントロールを備えたオプションの自動マージ構成について説明します。プロンプトだけでリポジトリのポリシーが強制されるとは考えないでください。トライアル中は自動マージを無効にし、GitHub のリポジトリ コントロールを使用して、チームに必要なレビューとチェックを要求します。

アクセスを拡大する前に確認すべきことは何ですか?

要件と運用コストについては、SuperAgent のセットアップとコスト ガイドを参照してください。ソース、チケット、ワーカー間の内部フローについては、アーキテクチャ ガイドをご覧ください。

よくある質問

Observe モードは本番認証情報で安全に使用できますか?

Observe モードでは、明示的なタスクから資格情報を保護したり、ワーカーを隔離したりしません。本番環境の認証情報をトライアルに使用しないでください。

専用の GitHub ユーザーがワーカーをサンドボックス化しますか?

いいえ。これにより、GitHub ID が分離されます。 OS とインフラストラクチャの制御は、プロセスが到達できる範囲を制御します。

プロトタイプは製品化の準備ができていますか?

メンテナは、これを実稼働対応のソフトウェアではなく、レビューして適応させるための研究用コードであると説明しています。

Coding Plan の料金を見る