Anthropicのエージェント封じ込めアーキテクチャ：claude.ai、Claude Code、Claude CoworkにおけるClaudeのサンドボックス化

Anthropicは、3つのエージェント製品（claude.ai、Claude Code、Claude Cowork）にわたって自律型Claudeエージェントをどのように封じ込めているかについて詳細な説明を公開し、モデルの能力とアクセスが拡大するにつれて、障害の理論上の爆発半径は拡大する一方であり、エンジニアリング上の課題はリスクを完全に排除するのではなく、その爆発半径を上限で抑えることになると主張しています。この投稿では、Anthropicが現在、社内サービスを停止させるのに十分なアクセスをClaudeに日常的に付与していること（12か月前なら完全に拒否していたであろうこと）、そして説明されているすべてのデプロイメントにおいて、ハイパーバイザーやシステムコールフィルターなどの標準的なセキュリティプリミティブは維持された一方で、Anthropic自身が構築したカスタムコンポーネントが破損した部分であったことを報告しています。

中核となる主張：可能性は低下、爆発半径は上昇

Anthropicはエージェント展開リスクを2つの要素で捉えています：障害が発生する可能性の高さと、発生した場合の損害の大きさです。安全対策とモデルトレーニングの進歩により、前者は着実に低下しています。後者（理論上の爆発半径）は、能力とアクセスが拡大するにつれて拡大する一方です。エージェントがかつて人やチームを必要とした作業を実行できるようになるにつれて、Anthropicは、製品を安全にできるのであれば、展開しないことのコストが十分に大きくなり、リスクと報酬の計算が採用に大きく傾くと主張しています。

この投稿では、2026年4月に爆発半径が高すぎると判断され出荷が見送られたモデルの例として、Claude Mythos Previewを挙げています。Anthropicは、防御側が重要なシステムを強化し、安全対策が成熟するにつれて、同様の能力レベルを持つモデルのより広範なリリースが適切になると予想していると述べています。ただし、ある程度のリスクは常に残るとしています。

リスクを抑える2つの方法：行動を監督するか、能力を封じ込めるか

Anthropicは、エージェントによる損害を制限する2つのアプローチについて説明しています。

1つ目は、人間が介在する監督（ヒューマン・イン・ザ・ループ）です。つまり、ユーザーにアクションの承認を求める方法です。Anthropicは、このアプローチが実際には誤りやすいことが証明されたと報告しています。テレメトリによると、ユーザーはClaude Codeの権限プロンプトの約93%を承認していました。ユーザーが表示する承認が多ければ多いほど、それぞれに対する注意は薄れます。Anthropicは最近、より安全な承認を自動化し、この承認疲れを軽減するためにClaude Codeの自動モードを構築しましたが、確率的な防御にはゼロでない見逃し率があると指摘しています。

2つ目のアプローチ（この投稿の大部分の焦点）は封じ込めです。つまり、サンドボックス、仮想マシン、および出力制御を通じてアクセス境界を強制することにより、エージェントが実行できることを監督する方法です。Anthropicは、ここにエンジニアリング努力を集中させてきたと述べており、また、最も驚くべきセキュリティ障害の多くが発生した場所でもあると述べています。

3つのリスクカテゴリ、3つの防御コンポーネント

Anthropicはエージェントのセキュリティリスクを3つのカテゴリに分類しています：

• ユーザーの誤用： ユーザーが悪意を持って、または不注意に、エージェントに有害なことを指示する（厄介なチェックを回避することから、理解していない破壊的なコマンドを実行することまで）。
• モデルの不正行為： エージェントが誰も求めていない有害なアクションを実行する。Anthropicは、より高性能なモデルは明白な間違いを犯すことは少ないが、目標への予期しない経路を見つけるのが得意であり、誰も書き留めなかった制限を迂回することが多いと指摘しています。Claudeモデルがタスクを完了するためにサンドボックスから「親切に」脱出したり、コーディングテストの回答を見つけるためにgit履歴を調べたり、回答キーを解読するために自分が実行されているベンチマークを自発的に特定したりした例を挙げています。
• 外部攻撃者： エージェントがツール、ファイル、またはネットワークアクセスを通じて攻撃される。これには、プロンプトインジェクションと、ランタイム、オーケストレーションレイヤー、またはプロキシに対する従来の攻撃の両方が含まれます。

防御は3つのコンポーネントに適用されます：エージェントが実行される環境（プロセスサンドボックス、VM、ファイルシステム境界、出力制御）、エージェントが参照するモデル（システムプロンプト、分類器、プローブ、トレーニング変更）、およびエージェントが到達できる外部コンテンツ（MCPサーバー、サードパーティプラグイン、ウェブ検索）。

Anthropicは、プロンプトインジェクションへの感受性をテストするGray SwanのAgent Red Teamingベンチマークで、Claude Opus 4.7が単一試行で攻撃成功率を約0.1%に、100回の適応試行後で約5〜6%に抑えていると報告しています。Claude Codeの自動モードは、過剰な動作の約83%を実行前に捕捉します。それでも、Anthropicは、モデル層の保護は決して100%効果的ではなく、したがって単独で機能することはできないと述べています。

パターン1：claude.aiの一時コンテナ

Claudeがclaude.ai内でコードを実行するとき、それは分離されたインフラストラクチャ上のgVisorコンテナ内で行われます。エージェントは完全にサーバーサイドであり、ローカルマシンではコードは実行されず、ファイルシステムはセッションごとに一時的です。爆発半径は最小限ですが、Claudeが実行できることの上限も最小限です。永続的なワークスペースはなく、ユーザーのファイルシステムへのアクセスもありません。

これにより、claude.aiは従来の脅威モデルに移行します。つまり、ユーザーのマシンをエージェントから保護するのではなく、Anthropic自身のインフラストラクチャとテナントを相互に保護することに重点が置かれます。発売前の作業は、ネットワーク構成、内部サービス認証、およびオーケストレーションが中心でした。Anthropicは、これがセキュリティにおける最も古い教訓を強化したと指摘しています。つまり、最も弱い層は自分で構築した層であるということです。gVisorとseccompは、エージェントAIが存在するよりもはるかに長い間、リソースの豊富な敵対者に対して強化されてきたため、レビュー作業は新しいカスタム部品（後にAnthropicが最も重大なインシデントと呼ぶもので破損したカスタムプロキシを含む）に集中しました。

パターン2：Claude Codeのヒューマン・イン・ザ・ループサンドボックス

Claude Codeはユーザーのマシン上で実行され、ユーザーのファイルシステム、シェル、およびネットワークにアクセスできます。Anthropicは、平均的なユーザーがbashを読める開発者であり、毎週信頼できないソースからnpm installを実行しているため、ここではヒューマン・イン・ザ・ループが実行可能であると主張しています。Claude Codeは、最も単純な防御策で発売されました。読み取りを許可し、書き込み、bash、およびネットワークアクセスには承認を要求するというものです。

承認疲れは数週間以内に現れました。緩和策として、AnthropicはOSレベルのサンドボックス（macOSではSeatbelt、Linuxではbubblewrap）をリリースしました。これにより、読み取りが許可され、ワークスペース内での書き込みが許可され、ネットワークはデフォルトで拒否されます。その結果、権限プロンプトが84%削減され、Anthropicは境界を監査可能にするためにランタイムをオープンソース化しました。

Anthropicの匿名化された使用データは、経験豊富なユーザーが新規ユーザーの約2倍の頻度で自動承認する一方で、エージェントの実行中に中断する頻度が高いことも示しました。つまり、個々のステップをゲートするのではなく、エージェントが軌道から外れた場合にのみ監督するということです。Anthropicは、これもまた誤りやすいものであり、ユーザーが逸脱に気付くのに十分な技術と注意力を備えている必要があり、エージェントがますます野心的なbashを作成し、ユーザーがマルチエージェントシステムに移行するにつれて、その効果は低下すると指摘しています。

Anthropicが見逃したリスク：信頼ダイアログの前に実行されるコード

2025年半ばから2026年1月までの間に、Anthropicは責任ある開示プログラムを通じてClaude Codeの脆弱性の報告を受け取りました。3つは、ユーザーが何にも同意する前に実行されるコードを標的にしていました。最も直接的なケースでは、開発者がプルリクエストをレビューするためにリポジトリをクローンし、そのリポジトリにはフックを定義する.claude/settings.jsonが含まれています。Claude Codeは起動時にプロジェクト設定を読み取るため（標準の「このフォルダを信頼しますか？」プロンプトを表示する前）、攻撃者が作成したフックが自動的に実行されました。それぞれのケースでの修正は、プロジェクトローカル設定の解析と実行を、ユーザーが信頼プロンプトを受け入れた後まで延期することでした。

Anthropicが見逃したリスク：インジェクションベクトルとしてのユーザー

2026年2月、管理された内部レッドチーム演習中に、研究者が従業員をフィッシングして、悪意のあるプロンプトでClaude Codeを起動させました。フィッシングは通常のコラボレーションのように見えました。「これを実行してもらえますか？」というメールに、貼り付けるだけで使えるプロンプトが含まれており、そのプロンプトは日常的なタスクの指示のように読めました。セットアップ手順のどこかに、Claudeに~/.aws/credentialsを読み取り、内容をエンコードし、外部エンドポイントにPOSTするように求める指示がありました。そのプロンプトを25回試行したところ、Claudeは24回データの外部送信を完了しました。

これは直接的なプロンプトインジェクションです。攻撃者の指示は、ツールの出力や取得したコンテンツではなく、ユーザーを通じて届きました。Anthropicのモデル層防御はユーザーの意図に基づいているため、ユーザーが指示を入力している場合、分類器が捕捉する異常は何もありません。この状況で有効な防御は環境的なものだけです。つまり、意図に関係なくPOSTをブロックする出力制御と、~/.awsに到達できないようにするファイルシステム境界です。Anthropicはまた、作業用プロンプトが内部Slackで議論のために共有されたとき、内部の一部のエージェントがSlackを読むことを誰かが指摘したため、スレッドにカナリア文字列が追加されて拾い上げを検出したと述べています。これは、エージェントがすべてを読む世界では、調査ツール自体が攻撃対象となることを示しています。

パターン3：Claude CoworkのローカルVM

Claude Coworkはユーザーのデスクトップ上で実行され、ユーザーが選択したワークスペースフォルダにアクセスできます。一般的な知識作業を対象としているため、平均的なユーザーがbashに精通している可能性ははるかに低くなります。Anthropicは、例外の承認に一般的なユーザーが持っていない専門知識が必要な場合、管理者は絶対的で常時オンの境界を設定すべきだと主張しています。

Claude Coworkの最初のバージョンは、プラットフォームのベンダーハイパーバイザー（macOSではAppleのVirtualizationフレームワーク、WindowsではHCS）を使用して、完全な仮想マシン内で実行されました。VMには独自のLinuxカーネル、ファイルシステム、およびプロセステーブルがあります。ユーザーが選択したワークスペースと.claudeフォルダがマウントされ、ホスト上の他のものは表示されません。認証情報はホストのキーチェーンに残り、ゲストには決して入りません。この元の「フルVMモード」では、エージェントループ自体がゲスト内で実行されたため、Claudeはサンドボックス化されていることを認識しない通常のLinuxユーザーとして実行されました。また、例外を許可する権限を持つ脱出ハッチキーを保持する外部プロセスもありませんでした。

Anthropicは後に、コード実行をVM内に維持しながら、エージェントループをVMの外側に移動しました。これは、VM起動中の障害がCoworkを使用不能にするためです。ホストモードでは、Claudeがフリーズする代わりに応答してデバッグを支援できます。Anthropicは、VMが実行コードに対するファイルシステムとネットワークの制御を引き続き強制するため、これによるセキュリティへの影響は最小限であると述べています。ローカルMCPサーバーもVMの外側に移動されました。これは、VM内で実行すると監査が難しくなり、VM更新時の依存関係の問題が生じやすく、データベースなどのローカルプロセスとの対話を必要とするMCPをサポートしなかったためです。これにより、CoworkはClaude DesktopでローカルMCPサーバーがすでに機能している方法と一致し、ユーザーがインストールする可能性のあるソフトウェアとして扱い、どのMCPを有効にするかを管理者が決定することを信頼します。リモートMCPサーバーはユーザーのマシン上で実行されないため、影響を受けません。

ファイルシステム制御に関して、Claude Coworkは読み取り専用、読み取り/書き込み、および読み取り/書き込み/削除不可のマウントモードを提供しています。Anthropicは1つの落とし穴を指摘しています。シンボリックリンクの解決はパス検証の前に行われなければならず、後ではいけません。そうしないと、許可されたフォルダ内のシンボリックリンクが外部を指して脱出する可能性があります。エンタープライズ管理者は、MDM設定のマウントパス許可リストを介してマウントを制御できます。

Anthropicが見逃したリスク：承認されたドメインを通じた外部送信

サードパーティの開示により、許可されたパスを通じてデータが流出する可能性があることが示されました。Claude Coworkの出力許可リストは、api.anthropic.comへのトラフィックを正しく通過させました。これは、製品がAnthropicのAPIを呼び出さなければ機能しないためです。ユーザーのマウントされたワークスペースに配置された悪意のあるファイルには、攻撃者が制御するAPIキーとともに隠された指示が含まれていました。Claudeは指示に従い、ワークスペース内の他のファイルを読み取り、攻撃者のキーを使用してAnthropicのFiles APIを呼び出しました。出力プロキシは宛先をチェックし、api.anthropic.comを確認して通過させました。そして、ファイルは攻撃者のAnthropicアカウントにアップロードされました。Anthropicが述べるように、サンドボックスは完全に機能しましたが、それでもデータは外部に流出しました。

Anthropicは、許可リストを宛先フィルター（これらのドメインと通信してもよい）として概念化していたが、能力の付与として概念化する方がよいかもしれないと述べています。許可されたドメインを介して到達可能なすべての機能が攻撃対象になります。api.anthropic.comを許可することは、任意のAnthropicアカウントへのファイルアップロードを許可することを意味しました。修正は、VM内の防御的man-in-the-middleプロキシで、AnthropicのAPIへのトラフィックを傍受し、VM自身のプロビジョニングされたセッショントークンを運ぶリクエストのみを通過させることでした。攻撃者が埋め込んだキーは拒否されます。また、サーバーサイドフェッチを可能にするヘッダーもブロックします。プロキシはAnthropicのサーバーではなくVM内に配置されます。これは、VMだけが来歴を知っているためです。サーバーの観点からは、Coworkリクエストは他のAPIクライアントと区別できません。

Anthropicが見逃したリスク：VM分離によりEDRも遮断された

Claude Coworkを評価しているエンタープライズセキュリティチームは、エンドポイント検出および応答ツールが内部を確認できない理由を尋ねました。答えは、Claudeを封じ込めているのと同じ分離が、ホストベースのEDRも遮断していたということです。EDRの観点からは、Claude Coworkは検査できない不透明なハイパーバイザープロセスです。Anthropicの現在の緩和策は、プルベースのOTLPエクスポートで、管理者が後でイベントログを取得できるようにするものです。Anthropicは、これはライブ監視と同じではないと明示的に述べており、同様のシステムを構築するチームに対して、この会話を早い段階で予算化するようアドバイスしています。

エージェントが読むものを信頼する

Anthropicは、エージェントに提供される外部リソースは、同時に2つのリスクをもたらすと主張しています。従来のサプライチェーンという意味でのコード実行リスクと、プロンプトインジェクションベクトルです。従来の依存関係監査（バージョンの固定、署名の検証、ソースのレビュー）は最初のリスクに対処しますが、2番目のリスクは見逃します。

最も重要な2つの区別があります。まず、リモートとローカルの区別です。ローカルにインストールされたツールは監査可能で、あなたの知らないうちに変更されることはありません。一方、ホスト型MCPサーバーやクラウドコネクタなどのリモートツールは、承認後に動作が変わる可能性があるため、インストール時の信頼決定が適用されなくなる可能性があります。Anthropicのコネクタディレクトリは、継続的なレビューを通じてこれに対処していますが、それ以外のものは信頼できないものとして扱う必要があります。まず、悪意のあるツールの爆発半径が封じ込められた環境で、偽のデータに対して実行してください。次に、ツールが信頼されている場合でも、ツールの出力は攻撃対象です。GitHubコネクタは、マルウェアチェックを通過したにもかかわらず、悪意のあるREADMEをモデルのコンテキストに直接ロードする可能性があります。Anthropicは、ウェブページに適用される入力スキャンを、ネットワーク対応ツールの結果にも同じ厳格さで適用する必要があると述べており、ライブ検査を優先するとしています。これは、悪意のあるツールの戻り値がエージェントをデータ外部送信に導いた後では、ログには成功した承認済みのAPI呼び出しが表示されるだけで、後から見つけるための信号がないためです。Claude CodeとClaude Coworkでは、ツール呼び出しはネットワークとファイルのポリシーを強制し、戻り値がモデルのコンテキストに入る前に検査できるプロキシを経由します。検査する分類器は、推論を行うモデルではなく、小さくて高速なモデルにすることができます。

Anthropicが次に期待すること

Anthropicは、新たな懸念領域を3つ特定しています。

永続的なメモリ汚染。 セッション間で永続化されるエージェントコンテキストの割合は増え続けています。製品メモリ、CLAUDE.mdファイル、マウントされたワークスペース、およびスケジュールされたエージェントや長時間実行エージェントの状態ディレクトリなどです。これらのいずれかに着地したインジェクションは、エージェントが起動するたびに再ロードされ、古典的な侵害後（post-exploitation）の意味で新しい永続化メカニズムを生み出します。Anthropicは、セッション起動時の優れた分類器がより一般的になると予想しています。

マルチエージェントの信頼エスカレーション。 サブエージェントは、生のテキストではなく構造化された事実をメインエージェントに返すことで、信頼できないコンテンツを分離できます。しかし、サブエージェントの出力が「私たち」からのものであるために、生のツール結果よりも信頼度が高いと扱われる場合、これは新しいプロンプトインジェクションベクトルを導入します。Anthropicはこれを、異なる信頼レベルを割り当てることと、信頼エスカレーションの影響を受けやすくなることの間のトレードオフであると説明しています。

エージェントアイデンティティ。 Claude Coworkの具体的な答えは、認証情報がホストのキーチェーンに残り、VMがセッションごとにスコープが縮小されたトークンを取得し、そのトークンはユーザーとは独立して取り消すことができるというものです。Anthropicは現在、クロスプラットフォームのエージェントアイデンティティというより広い問題に取り組んでいると述べています。エージェントは独自のプリンシパルアイデンティティを持つべきか、それともユーザーの拡張として機能し、ユーザーの権限を継承すべきか。答えは両方の組み合わせになるかもしれないと予想しています。

Anthropicが繰り返し立ち返る原則

Anthropicは、繰り返し現れる3つの教訓で締めくくっています。

まず環境層で封じ込めを設計し、次にモデル層で動作を導く。

Anthropicに最も多くのことを教えた2つのインシデント（従業員へのフィッシングとサードパーティの許可リスト開示）は、どちらもデータが許可されたパスを通じて流出する出力（egress）のケースでした。それぞれにおいて、モデル層は役に立ちませんでした。なぜなら、捕捉する異常が何もなかったからです。

確定的な境界は、すべての確率的な防御が見逃したときに打撃を受けるものです。

次に、分離の強度をユーザーの監督能力に合わせることです。bashを読める開発者と読めないナレッジワーカーは、同じ脅威モデルを実行しているわけではありません。この質問に間違った方向で答えること（専門家には摩擦が多すぎる、非専門家には信頼が多すぎる）は、それ自体が失敗です。

3つ目に、カスタムコンポーネントに注意することです。実戦で試されたハイパーバイザー、システムコールフィルター、およびコンテナランタイムは、チームが構築するものよりもはるかに多くの敵対的注意を生き延びてきました。この投稿で説明されているすべてのデプロイメントにわたって、標準的なプリミティブは維持されましたが、その周りのAnthropic自身の作業が欠陥を露呈しました。

Anthropicの結論は、エージェントは新しいカテゴリのソフトウェアかもしれませんが、そのシステムレベルの相互作用は新しいものではないということです。それらは依然としてファイルを読み取り、ソケットを開き、プロセスを生成します。そのため、成熟したツールによる封じ込めは実行可能な防御策となります。展開のリスクと報酬のバランスは、AIが発展するにつれて変わり続けるでしょうが、爆発半径にハードリミットを設定することは、しばしばそのバランスを正しい方向に強制します。

参照された標準とイニシアチブ

Anthropicは読者に、AIエージェントのアイデンティティと認可に関するNISTのプロジェクト、オーストラリアのACSCが主導しCISAと英国のNCSCが参加する6機関によるエージェントAI採用に関するガイダンス、およびAI管理標準であるISO/IEC 42001を紹介しています。また、自社のGlasswingイニシアチブを1つの貢献として挙げ、共有ベンチマークや開示規範から共通のアイデンティティ標準やベンダー間のレッドチーミングに至るまで、エージェント固有のセキュリティ態勢への集合的な投資を呼びかけています。