7月22日、Eran Stillerが「Anthropic Details How It Contains Claude Across Web, Code, and Cowork」と題した記事を公開した。この記事では、AnthropicがClaudeのWeb・開発者・デスクトップ製品にわたる封じ込めアーキテクチャの詳細と、その設計上の失敗から得た教訓について詳しく紹介されている。
「モデルを信頼するな、環境で制御せよ」がAnthropicの立場
AIエージェントの安全設計において、「モデル側のガードレール（分類器、システムプロンプト、ファインチューニング）」への依存は限界がある。Anthropicはその立場を明確にし、ファイルシステム・ネットワーク・実行環境に対する決定論的な制限こそが安全の本丸だと主張している。
モデル制御は挙動に影響を与えられるが、それを保証することはできない。したがって「何にアクセスできるか・何を送信できるか」の硬い境界は環境側が担うべき、という考え方だ。
リスクの源泉としてAnthropicは三つを挙げる。ユーザーによる悪用、モデル自身の誤動作、そしてファイルやツール・ネットワーク経由で注入される攻撃コンテンツだ。
/filters:no_upscale()/news/2026/07/anthropic-claude-containment/en/resources/1Anthropic-Image-1-1784707512259.png)
Anthropicは確率的なモデル本体・実行環境・外部から注入されうるコンテンツを明確に区別している。（出典）
93%の承認率が示した「人間レビュー」の限界
製品ごとの設計の違いが、この哲学をよく体現している。
claude.aiではコード実行を一時的なgVisorコンテナ上で行い、ユーザーのローカルファイルシステムへのアクセスは一切ない。
Claude Code（開発者向けCLIツール）は開発者のマシン上で動作するため、当初はファイル書き込み・シェルコマンド・ネットワークアクセスのたびにユーザー承認を求める設計だった。しかしAnthropicの調査では、ユーザーはそれらのプロンプトを約93%承認していた。これは実質的に、継続的な人間レビューがほぼ形骸化していたことを意味する。
その後Anthropicは、macOSでは**Seatbelt、Linuxではbubblewrapを用いたOSレベルのサンドボックスを追加した。SeatbeltはmacOS固有のサンドボックス機構であり、プロセス単位でシステムコールやリソースアクセスをポリシーで制限できる。ワークスペース内への書き込みは許可しつつ、ネットワークアクセスはデフォルトで遮断する設計だ。結果として承認プロンプトが84%減少**した。
赤チームテストで露呈した「承認があっても防げない」現実
最も重要な知見の一つが、Anthropicが実施した内部レッドチーム演習から得られた。実際の被害ではなく、制御された内部テストとして行われたものだ。
この演習では、フィッシング攻撃によってある従業員が、Claude CodeにAWS認証情報を外部サーバーへ送信するよう指示するシナリオが再現された。内容は一見もっともらしいものだった。Claudeはその指示に従い、テスト25回中24回、認証情報の外部送信（exfiltration）を実行した。
この結果が示すのは、承認フロー・分類器・「意図の判定」に依存したコントロールの根本的な限界だ。たとえリクエストがユーザーから来ていても、モデルの誤動作から来ていても、悪意あるツール出力から来ていても、ファイルシステム分離とアウトバウンドネットワーク制限が認証情報の窃取をブロックしなければならない、というのがAnthropicの結論だ。
ドメイン許可リストは「信頼」ではなく「攻撃経路」になりうる
Claude Coworkはclaude.aiやClaude Codeとは異なり、ブラウザ操作やファイル管理などより複雑なタスクを自律的にこなすことを想定した、一般ユーザー向けのデスクトップエージェント製品だ。当初フルVMで動作する強固な設計が採用されていた。
しかし後にエージェントループをホスト側へ移行した際、重要な脆弱性が第三者から報告された。悪意あるファイルがClaudeに対し、Anthropic自身のFiles APIを通じてワークスペースのファイルを攻撃者管理のアカウントへアップロードさせたのだ。
api.anthropic.comはドメイン許可リストに登録されていたため、送信先チェックを通過してしまった。
/filters:no_upscale()/news/2026/07/anthropic-claude-containment/en/resources/1Anthropic-Image-3-1784707512259.png)
ドメイン許可リストがFiles API経由の情報漏洩を許した。修正後のプロキシ設計ではリクエストをVMのセッショントークンに限定している。（出典）
対応策として、VM内にプロキシを設置し、そのVMのプロビジョニング済みセッショントークン経由のリクエストのみを受け付け、関連するサーバーサイドフェッチヘッダーはブロックする設計へ変更した。
教訓はシンプルだ。許可リストに登録されたドメインは、そのドメインを通じて到達できるすべての機能へのアクセスを意味する。「信頼できるドメイン」は「信頼できる送信先」とイコールではない。
設計原則：「悪意の検知」より「被害の上限設定」
Anthropicは記事の結論として、封じ込め設計はユーザーが実際にどれだけ意味のある監視を行えるかを反映すべきだと主張している。エージェントセキュリティは有害な意図の検知に依存することはできない。代わりに、安全でないアクションが引き起こしうる被害を環境側で上限設定することが求められる。
詳細はAnthropic Details How It Contains Claude Across Web, Code, and Coworkを参照していただきたい。
