Managed Agentsセルフホストサンドボックスのセキュリティ責任分界

Managed Agentsをセルフホストサンドボックスへ切り替えると、ツール実行が自社インフラに移ります。同時に、それまでAnthropicが引き受けていた責任の一部も自社に移ります。「クラウドサンドボックスと同じ安全性が自動的に付いてくる」と思ったまま本番に出すと、鍵の管理やログの扱いで穴が残ります。

先に結論を書きます。会話内容とツール出力は、セルフホストでもAnthropicの制御プレーンへ流れます。ZDR(ゼロデータ保持)とHIPAA対応(HIPAA readiness)の対象にも、セルフホストで入るわけではありません。自社が持つのは、サンドボックスの中身、外向き通信、3種類の鍵、ログ、memory storeの作業コピーです。

責任の線は、サンドボックスの手前で引かれる

どの環境を選んでも、Anthropicが守るのは制御プレーン側までです。サンドボックスの内側は自社の設計に委ねられます。

くらべる

セルフホストでの責任の分かれ目

制御プレーン

Anthropicが守る

• セッションとワークキューの整合性
• マルチテナントの分離
• エージェントに渡すコンテキストの最小化
• 環境キーの失効の検証(リクエストごと)

サンドボックスの内側

自社が持つ

• サンドボックスイメージの品質と実行時の堅牢化
• 外向き通信(egress)の制御
• 鍵の保管・ローテーションと、信頼境界ごとの分離
• ログの保持、伏せ字、削除
• memory storeの作業コピーの後始末

注意したいのは、データの流れです。ツールの入力と出力は自社のワーカーで処理されますが、モデルが結果を見て次の手を決めるため、制御プレーンにも届きます。公式のセルフホストの説明は、skillsとmemory storesがAnthropic側に保存され、サンドボックスにはセッションの間だけコピーが置かれると書いています。

つまりセルフホストが動かすのは「コードを実行する場所」であって、「データが自社の外に出ない」ことの保証ではありません。この区別は、後半のコンプライアンスの節で効いてきます。

3種類の鍵を、どこに置くか

セルフホストには似た名前の資格情報が3つ登場します。どれがどこにあってよいかを取り違えると、被害の範囲が一気に広がります。

APIキーを分ける理由は、はっきりしています。キュー統計などの運用系エンドポイントは、組織のAPIキーでも環境キーでも呼べます。そのためAPIキーをワーカーのホストに置くと、組織スコープの資格情報がエージェントのツール呼び出しから読める場所に出ます。運用ツールはホストの外から、APIキーで呼ぶ形が前提です。

環境キーの生成にも癖があります。Consoleでしか生成できず、APIで作った環境でも同じです。生成した値はワーカーのホストに環境変数として渡します。

サンドボックスを1セッション1つにする構成の注意

セッションごとに専用サンドボックスを起動する構成では、公式のサンプルスクリプトが、環境キーとセッションのsecretをdocker runの-eでコンテナへ渡しています。コンテナの中ではツールが動きます。だから、そのコンテナに信頼できないコードを走らせるなら、環境キーが1つの環境のキューに紐づくという事実が重くなります。

ここで検討したいのが、信頼境界ごとに別のワークスペースと環境を用意することです。目的は、1つの鍵が及ぶ範囲を共有プール全体ではなく、1人のユーザーのセッションに絞ることです。複数のテナントを1つの環境と鍵で処理すると、鍵が漏れたとき影響はその環境のキュー全体に及びます。マルチテナントで提供するなら、環境の分割は後回しにしにくい設計項目です。

鍵の漏えいを疑ったときの動き

Anthropicは異常な使用パターンを検知できても、環境キーが盗まれたこと自体は分かりません。気づくのは自社の側です。そのぶん、失効の手順を手元に用意しておく価値があります。

手順

環境キーの漏えいを疑ったとき

1. 1

   失効させる

   疑いが出た時点で失効します。失効はリクエストごとに検証されるので、次のワーカー呼び出しから、そのキーは通らなくなります。

2. 2

   代わりの鍵を発行する

   Consoleで環境を開き、「Generate environment key」から新しい鍵を作ります。生成できるのはConsoleだけです。

3. 3

   ワーカーのホストの変数を差し替える

   ANTHROPIC_ENVIRONMENT_KEYを新しい値に置き換えます。再起動が要るかどうかは、ワーカーの実装によります。

4. 4

   接続を確かめる

   運用側のマシンでant beta:environments:work stats --environment-id "$ANTHROPIC_ENVIRONMENT_ID"を実行し、workers_pollingが1以上に戻ったかを見ます。

この手順を、インシデントが起きる前に誰が実行するかまで決めておく必要があります。導入の起案段階で担当を割り当てていないと、事故の瞬間に「誰が鍵を失効させるのか」が宙に浮きます。

Claude Platform on AWSで動かす場合は、ワーカーの認証がAWS IAM(SigV4)かAWS Consoleで発行したAPIキーに変わります。Consoleの通常の環境キーは、そのエンドポイントでは通りません。

memory storeのコピーは、誰がいつ消すか

memory storesの本体とバージョン履歴は、Anthropic側にあり続けます。ワーカーはセッションの間だけ、サンドボックスの/mnt/memory/配下に作業コピーを置き、変更をストアへ同期します。セッションが終わると、ワーカーがこのコピーを消します。使い方の基本はメモリストアの使い方にあります。

ここに自社の責任が3つ載ります。残留コピーの掃除、そのパスの権限設定、同じファイルシステムを共有するセッション同士の分離です。

数字

memory storeの同期まわりの数字

• 同期間隔

  15秒

  SDKワーカーの最小は5秒。antのCLIワーカーは既定値のみ

• 最終同期の待ち

  最長30秒

  終了時に未アップロード分を流す時間

• 1セッションの上限

  8ストア

  resourcesに並べられるmemory storeの数

• Dockerの既定猶予

  10秒

  停止信号のあとSIGKILLまでの時間

数字の並びが示す落とし穴があります。最終同期に最長30秒かかるのに、Dockerは停止信号の10秒後にSIGKILLを送ります。強制終了されたワーカーは後片付けを走らせないため、未同期の編集は失われ、ストアのディレクトリが残ります。公式が挙げる対処は、SIGTERMで止めて30秒以上待つことです。docker runの--stop-timeoutやオーケストレーターの猶予時間で延ばします。

残ったディレクトリがあると、次のセッションの開始が止まります。ワーカーのログにsomething already exists at the memory store's pathと出て、そのパスを手で消すまで進みません。使い捨てのサンドボックスを1セッションごとに捨てる構成なら、この掃除は要りません。

同じストアを複数のセッションに添付するなら、ファイルシステムをセッションごとに分けます。同じホストでは、同じパスに2つのセッションがマウントできないためです。

read_onlyのstoreが守るものと、守らないもの

read_onlyで添付したストアは、アップロードから守られます。ローカルの変更から守られるわけではありません。ここは誤解されやすい点です。

くらべる

read_onlyで添付したストアの実際

書き込みの拒否

防がれる

• ワーカーのwrite・editツールによる変更
• ストアへの同期(ローカルの変更は上がらない)

ローカルコピーの改変

防がれない

• bashツール経由でエージェントが実行したコマンド
• サンドボックスから提供するカスタムツールやMCPサーバー(ワーカーと同じ権限で動く)

改変されたコピーは、ストアには上がりません。そのままセッションの間、後続のツール呼び出しに読まれます。次にそのmemoryがストア側で変わると、ストアの版で上書きされます。

エージェントにローカルの見え方すら変えさせたくないなら、そのエージェントのbashツールを無効にし、サンドボックスのファイルシステムへ書き込むカスタムツールを渡さないようにします。ストアのパスを読み取り専用でマウントする方法は使えません。ワーカー自身がディレクトリを作り、ダウンロードしたmemoryを書き込む必要があるからです。

競合の扱いも覚えておく価値があります。エージェントが書き換えたファイルが、ストア側でも変わっていた場合、次の同期でストアの版が勝ちます。ローカルのファイルは上書きされ、ワーカーのログに警告が出ます。write・editツールは成功を返し、エージェントにはエラーが届きません。変更がまだ有効なら、同期のあとで読み直してやり直す必要があります。ワーカーのログを見る人がいないと、この上書きは気づかれずに終わります。

ローカルで削除したファイルの扱いは、memory_sync_deletionsで決めます。既定の"enabled"では、あとの同期でファイルが消えたままだと確認できた時点で、ストアからもそのmemoryを削除します。log_onlyとdisabledも選べます。ワーカー側でmemoryのサポートを無効にすると、そのワーカーはストアをダウンロードも同期もしません。

自社が背負う残りの項目

鍵とmemory store以外にも、自社の責任になる項目があります。

サンドボックスイメージの中身は、Anthropicが検査も検証もしません。非rootユーザーでの実行、読み取り専用のルートファイルシステム、不要なLinux capabilityの削除といった堅牢化は、実施した分だけ効きます。

外向き通信は、自社のVPCとファイアウォールで決まります。制限がなければ、侵害されたツール実行が任意の外部ホストへ届きます。ツールが実際に使うエンドポイントだけに出口を絞ります。

ツールはワーカーのプロセスと同じ権限で動きます。プロセスのユーザーには最小権限を与え、マウントするディレクトリも必要な範囲に絞ります。

会話内容とツール出力はワーカーを通り、自社の環境に残ります。保持期間、伏せ字、削除のルールは自社のポリシーで決めます。Anthropicは、届けたあとにワーカーが何をするかを見ていません。

事故が起きたとき、Anthropicには見えない

次の表は、公式が「Anthropicが代わりにできないこと」として挙げる4つを、起きる場面で並べたものです。

ZDRとHIPAA対応は、セルフホストで変わらない

コンプライアンス要件を満たすためにセルフホストを選ぶ場合、ここは先に確認したい箇所です。APIとデータ保持のページにある機能適格性の表では、Claude Managed Agentsは、ZDR対象外、HIPAA readiness対象外とされています。理由は、セッションが状態を持つリソースで、トランスクリプトは削除するまで残るためです。

その備考には、この扱いがセルフホストサンドボックスを含むManaged Agentsの全サブ機能に及ぶと書かれています。自社インフラでツールを動かしても、これらの適格性は付きません。データが自社の境界から出ないことを要件にしている案件では、ツールの入出力が制御プレーンへ届く点とあわせて、要件と食い違わないかを導入の前に確かめる必要があります。

プラットフォームによっても制約が変わります。Claude Platform on AWSのセルフホスト環境では、セッションにmemory storesを添付できません。添付しようとすると、セッションの作成時に拒否されます。一方、Anthropicのファーストパーティ版では、クラウド環境でもセルフホスト環境でも添付できます。

もう1つ、セッションのresourcesの扱いが違います。セルフホスト環境で添付できるのはmemory_storeだけで、fileやgithub_repositoryを含むセッションは400エラーで拒否されます。ファイルの受け渡しとリポジトリの取り込みは、自社が用意する側に回ります。クラウド側の仕様はクラウドサンドボックスの仕様と見比べると、どこから自社の役目かが分かります。

この境界をどう読むか

セルフホストでAnthropicが手放したのは、サンドボックスの中で何が起きるかを見る力です。ログの保持方針もツールの分離も、公式の責任分担では自社側に置かれています。実行場所を自社に置くことで、見える範囲と責任の線が変わります。

この対価は、導入時に一度払って終わる設計コストではありません。鍵のローテーション、残留コピーの掃除、ログの保持管理は、稼働している間ずっと続きます。

もう1つ、見落としやすい点があります。責任分担の一覧は、Anthropicが何を守るかよりも、自社が何を守る前提で組まれているかを読む資料です。Environment workerの構成を決める段階で、一覧の各項目に担当者と点検の頻度が付いているかを見る使い方ができます。Managed Agents全体の位置づけはManaged Agentsの解説にあります。

まとめ

セルフホストで安全性の基準線を決めるのは、サンドボックスの内側をどこまで自社で作り込めるかです。環境キーの失効担当と、データの流れがZDRやHIPAAの要件と合うかの2点は、導入の前に答えが出ている必要があります。