脅威モデルと残るリスクを知る

Agent Fleet の隔離の境界がどこにあり、どこにないかを知り、残るリスクを運用で抑えられるようになります。 リスクの一覧そのもの（何が、なぜ残るか）は SECURITY.md（英語）の “Known residual risks” にあり、このページは運用の手順を扱います。

全体像

あなたがやること	起きること
Control Plane が動く基盤に触れる人を絞る	配備の中の分離を一括で破れる経路が、少数の人に限られる
会社ごとに配備を分ける（AWS ではアカウントも分ける）	事故の影響が 1 つの配備の中で止まる
AF_MASTER_KEY とバックアップを別々に守る	データだけが漏れても、保存された秘密は読めない
見つけた脆弱性を非公開で報告する	修正が出るまで、ほかの配備が狙われない

境界はどこにあるか

ワークスペースの中では、エージェントの CLI が任意のコードを動かします。ツールの承認を飛ばす運用が既定です。 そのため「メンバーのセッションは信頼できないコードを動かす」を前提に、境界を引いています。

	信頼の度合い	守るもの
ワークスペース	低い	—
Control Plane とそれが動く基盤	高い	ほかのメンバーのデータ、基盤そのもの、秘密、外への持ち出し

• この境界があるのは、複数の人で使うデプロイ先（docker・ecs・ecs-ec2）です
• native にはこの境界がありません。使うのは 1 人で、その人が運用者です（SECURITY.md の “docker and native”）

Control Plane は配備のすべてのワークスペースに届く

Control Plane はワークスペースを起動し、それぞれに鍵を渡します。docker では、マウントした Docker ソケットでホストのデーモンを動かします。 そのため、Control Plane かその下の基盤が破られると、その配備の中の分離はまとめて破れます。

会社は配備で分ける

その影響は 1 つの配備の中で止まり、ほかの会社の配備には及びません。1 社に 1 配備で提供する、いちばんの理由です。 AWS では、配備ごとに AWS アカウントを分けているときだけ、これが成り立ちます。

ツールの承認は境界ではない

承認を飛ばすのは既定であって、固定ではありません。メンバーはエージェントの種類ごと（設定 > エージェント）か、セッションを起動するときに、承認ありに戻せます。

• 変わるのは事故の起きやすさで、境界の位置は変わりません
• 選べるのは一部の種類だけで、TUI の中でモードを戻すこともでき、CLI 自身の設定も塞いでいません

承認は事故を減らす手当てと考えてください。実際に閉じ込めているのは、今もワークスペースの境界です。

残るリスクに備える

備えること	やること
基盤への管理アクセス	docker では、ホストに SSH・sudo・docker を実行できる人を最小限にします。Docker ソケットの前にフィルタする proxy（tecnativa/docker-socket-proxy など）を置くことも考えます。AWS では配備ごとにアカウントを分け、その管理者を絞ります
AF_MASTER_KEY	データベースや home とは別の金庫に置き、別にバックアップします。データ領域やバックアップのアーカイブには置きません（設計上も入りません）
バックアップ	保管先に届く人を絞り、保存時の暗号化を必ず使います

• AF_MASTER_KEY の作り方と保管は インストールする、復元のときに同じ鍵が要ることは バックアップして復元する にあります
• 鍵がない配備、鍵の要件と変えたときの代償は 配備の鍵を扱う にあります

鍵の強さが上限になる

既定では、各ワークスペースの認証情報を守る鍵は AF_MASTER_KEY から作られます。全体の強さは、この 1 つの鍵と同じです。 AWS では、この鍵を KMS に持たせられます（保存時の鍵を AWS KMS にする）。

脆弱性を報告する

脆弱性を見つけたら、公開の Issue を立てずに、非公開で報告してください。

• 報告の窓口と、報告に含める情報: SECURITY.md の “Reporting a vulnerability”
• 修正を受ける版: 同じく “Supported versions”

関連

• 配備の鍵を扱う：鍵の要件、鍵がない配備、鍵の前に保存された値
• 外向きの通信を制御する：ワークスペースから外への持ち出しを絞る
• アクセスを取り消す・super_admin を引き継ぐ
• セルフホストの全体像：運用する人が何に責任を持つか