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

Managed Agentsをセルフホストサンドボックスへ切り替えると、ツール実行が自社インフラに移る代わりに、それまでAnthropicが引き受けていた責任の一部が自社に移ります。この境界線を法務・セキュリティ担当が確認しないまま導入すると、「クラウドサンドボックスと同じ安全性が自動的に付いてくる」という誤解のまま本番投入することになりかねません。本稿は公式のセキュリティモデルに沿って、Anthropicが引き続き守る範囲と、自社が新たに背負う範囲を分けて示します。

背景 — 何が変わらず、何が変わるのか

Anthropicはどの環境を選んでも、制御プレーン側の3つを守り続けます。セッションとワークキューの整合性、マルチテナント分離、そしてエージェントに渡すコンテキストの最小化です。ここはクラウドサンドボックスでもセルフホストでも変わりません。

変わるのはその先です。セルフホストでは、Anthropicのセキュリティ境界がサンドボックスの手前で止まります。サンドボックスの中で何が起き、そこで何を守るかは自社の設計次第になります。この線引きを「What you own(自社が持つ責任)」と「What Anthropic cannot do for you(Anthropicが代わりにできないこと)」の2本立てで公式が明文化しているので、ここでは両方を実務の言葉に開きます。

自社が持つ責任 — 何を、なぜ自分で守る必要があるか

サンドボックスイメージの品質と実行時の堅牢化

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

ネットワーク外向き通信(egress)の制御

サンドボックスがどこへ到達できるかは自社のVPCとファイアウォールルールで決まります。外向き通信(egress)の制限を敷いていなければ、侵害されたツール実行が任意の外部ホストへ到達できてしまいます。ツールが実際に必要とするエンドポイントだけに出口を絞るのは自社側の設計判断です。

サービスキーの保管とローテーション

ANTHROPIC_ENVIRONMENT_KEYは、環境のワークキューをポーリングし、結果をセッションへ返す権限を持つ鍵です。環境変数ファイルやサンドボックスイメージに直書きせず、シークレットマネージャーで管理し、流出が疑われた時点で即座にローテーションします。

信頼境界ごとのワークロード分離

環境サービスキーは1つの環境のワークキューに紐づきます。信頼できないコードをサンドボックス内で実行するなら、信頼境界ごとに別のワークスペースと環境を用意することを検討します。そうすることで、1つの鍵が及ぶ範囲を共有プール全体ではなく単一ユーザーのセッションに限定できます。Environment workerを1つだけ立てて全テナントのセッションを1つの鍵で処理する構成は、実装としては最短ですが、鍵が漏れたときの被害範囲がテナント数だけ膨らむ設計でもあります。マルチテナントで提供するなら、環境の分割はワーカー実装の後回しにできる項目ではなく、最初のアーキテクチャ設計に含まれる項目です。

セッションごとの認証情報

ワーカーが取得する各ワークアイテムには、セッションごとのsecretが乗ることがあります。memory storesへのアクセスにはこのsecretが必須で、memory storeのエンドポイントは環境キーでのアクセスを拒否します。secretはそのセッションを処理するサンドボックスにだけ渡し、イメージや共有ボリュームには置かず、ログにも出しません。

ツール実行が及ぶ範囲

ツールはワーカーのプロセスが持つ権限そのままでサンドボックス内を動きます。プロセスユーザーには最小権限を与え、マウントするディレクトリもツールが実際に必要とする範囲に絞ります。

ログ保持とセッション内容

会話内容とツール出力はワーカーを経由して自社の環境に残ります。それをどれだけ保持し、どこを伏せ字にし、いつ削除するかは自社のポリシーに従う責任です。Anthropicは、届けたあとにワーカーがセッション内容をどう扱うかを見ていません。

memory storeの中身

memory storesの本体とバージョン履歴はAnthropic側でホストされ続けます。セッションがストアを添付すると、ワーカーがセッションの間だけ/mnt/memory/配下に作業コピーを置き、変更をストアへ同期します。ワーカーはセッション終了時にこのコピーを削除しますが、終了処理(teardown)を走らせずに終了したワーカーはコピーを残したままにします。残留コピーの掃除、そのパスの権限設定、同じファイルシステムを共有するセッション同士の分離は自社の責任です。

読み取り専用memory storeの実際の意味

read_onlyで添付したストアは、Anthropicへのアップロードから保護されるのであって、ローカルでの変更から保護されるわけではありません。ワーカーのwrite・editツールはそのディレクトリへの書き込みを拒否し、変更もストアへは同期されず、セッションのsecretを使った書き込みもmemory storeのエンドポイント側で拒否されます。しかしbashツール経由でエージェントが実行するコマンドや、サンドボックスから提供するカスタムツール・MCPサーバーはワーカーと同じ権限で動くため、これらは引き続きローカルコピーを書き換えられます。後続のツール呼び出しは、そのmemoryが次にストア側で更新されるまで変更後のコピーを読み続けます。エージェントにローカルコピーすら変えさせたくない場合は、bashツールを無効化し、サンドボックスのファイルシステムに書き込むカスタムツールを一切与えないという設計が必要になります。

Anthropicが代わりにできないこと

自社が「持つ責任」の裏側には、Anthropicが構造的に肩代わりできない領域があります。ここは自社が対応を用意しない限り、誰も対応しません。

環境キーの失効(revoke)はリクエストのたびに検証されるため、疑わしいと判断した瞬間に失効させれば、ワーカーの次回呼び出しから即座に効きます。ここは「気づいてから止めるまでのタイムラグが小さい」という数少ない自社側に有利な性質で、検知の遅れを取り返せる唯一の場所です。

コンプライアンス要件はセルフホストでどう扱うか

Zero Data Retention(ゼロデータ保持)やHIPAA BAA(医療情報保護に関する事業提携契約)の適格性は、セルフホストサンドボックスへの切り替えとは別の軸で管理されています。自社インフラでツールを実行するからといって、これらの適格性が自動的に付与されるわけではありません。対象になるかどうかはAPIとデータ保持に関する公式ページの機能適格性一覧で個別に確認する必要があり、法人導入の要件にZDRやHIPAA BAAが含まれる場合は、セルフホスト化の検討と並行して、または先に確認しておくと手戻りが減ります。

なお、Claude Platform on AWS上でセルフホスト環境を動かす構成では、memory storesをセッションに添付できないという制約もあります。ワーカーの認証もAWS IAM(SigV4)かAWS Console発行のAPIキーに変わり、Consoleで発行する通常の環境キーはそのままでは通りません。どのプラットフォーム上に構築するかによって、利用できる機能とキー管理の方式が変わる点は、責任分界の話とあわせて事前に確認しておく価値があります。

この境界をどう読むか

公式の書き方を並べると、Anthropicが手放しているのは「サンドボックスの中で何が起きるか」の可視性そのものだと分かります。ログの保持方針もツール分離の設計も、Anthropicが助言できる範囲の外にあります。これはクラウドサンドボックスからの機能後退ではなく、実行場所を自社に持ってくることの対価です。データが自社の境界から出ない代わりに、それを守る設計も自社が書くことになります。

法人導入の判断としては、この対価を「移行前に払う設計コスト」ではなく「稼働している間ずっと自社が負い続ける運用コスト」として扱う構成が現実的です。鍵のローテーション手順やmemory storeの残留コピー掃除は、初期構築が終わった後も継続する作業だからです。導入の起案段階でこの運用コストを誰が担当するチームに割り当てるかまで決めておかないと、実際にインシデントが起きた瞬間に「誰が鍵を失効させるのか」が宙に浮きます。

まとめ

セルフホストサンドボックスでも、セッションとワークキューの整合性・マルチテナント分離・コンテキスト最小化はAnthropicが引き続き守ります。一方でサンドボックスイメージの堅牢化、外向き通信(egress)の制御、環境キーとセッションsecretの管理、ログ保持、memory storeの残留コピー処理は自社の責任です。とりわけread_onlyのmemory storeが防ぐのはアップロードだけでローカル改変は防がないという点は見落としやすく、エージェントにローカルコピーすら触らせたくない場合はbashツールと書き込み系カスタムツールの両方を止める設計が要ります。導入前にこの一覧を自社のセキュリティ・法務チェックリストへそのまま転記できるかを確認しておくと、本番投入後に責任の所在で揉めることを避けられます。