この記事は、Claude Code のパーミッションベースのモデルから出発する。デフォルトでは、エージェントは読み取り専用で、何かを変更したりほとんどのコマンドを実行したりする前に確認を求め、echo や cat のような少数の安全なコマンドだけが自動的に許可される。記事は、「承認」を絶えずクリックすることは開発を遅くするだけでなく、ユーザーが承認する内容に細心の注意を払わなくなる 承認疲れ（Approval Fatigue） につながりかねず、開発をより安全にするどころか、かえって安全性を損なうと論じる。
その答えが サンドボックス化 である。すなわち、あらかじめ定義された境界を設け、その内側では Claude が行動のたびに許可を求めることなく自由に作業できるようにするというものである。記事はこの考え方に基づく 2 つの機能を紹介している。1 つ目はサンドボックス化された bash ツールで、ベータ版のリサーチプレビューとして、またオープンソースとして公開された新しいサンドボックスランタイム（Sandbox Runtime）上で動作する。2 つ目は Claude Code for web で、各 Claude Code セッションをクラウド上の隔離されたサンドボックスで実行する。Anthropic は、社内利用においてサンドボックス化によってパーミッションプロンプトを安全に 84% 削減できたと報告している。
要点
- サンドボックス化のアプローチは、オペレーティングシステムレベルの機能に基づく 2 つの境界を強制する。Claude が特定のディレクトリにしかアクセスしたり変更したりできないようにするファイルシステムの分離と、承認されたサーバーにしか接続できないようにするネットワークの分離である。
- 効果的なサンドボックス化には両方が必要だとされる。ネットワークの分離がなければ、侵害されたエージェントが SSH 鍵などのファイルを持ち出せてしまい、ファイルシステムの分離がなければ、サンドボックスから脱出してネットワークアクセスを得られてしまう。
- 動機となっている脅威は プロンプトインジェクション である。ファイルシステムの分離は、プロンプトインジェクションを受けた Claude が機密性の高いシステムファイルを変更するのを防ぎ、ネットワークの分離は、情報を漏洩させたりマルウェアをダウンロードしたりするのを防ぐ。
- サンドボックスランタイムを使うと、ユーザーはコンテナを立ち上げて管理することなく、エージェントがアクセスできるディレクトリとネットワークホストを定義でき、任意のプロセス、エージェント、MCP サーバーをサンドボックス化できる。
- Claude Code では、これが bash ツールをサンドボックス化する。サンドボックスの内側ではコマンドはパーミッションプロンプトなしで実行され、外側の何かにアクセスしようとするとユーザーに通知され、ユーザーはそれを許可するかどうかを選べる。
- 強制には OS のプリミティブ、すなわち Linux の bubblewrap と macOS の seatbelt が使われ、Claude Code の直接の行動だけでなく、コマンドが起動するあらゆるスクリプト、プログラム、サブプロセスにも適用される。
- デフォルトでは、bash のサンドボックスは現在の作業ディレクトリでの読み書きを許可し、その外側のファイルの変更をブロックする。ネットワークアクセスは、サンドボックスの外にあるプロキシに接続された Unix ドメインソケットのみを経由し、このプロキシが到達可能なドメインを制限し、新たに要求されたドメインについてはユーザーに確認する。どちらも設定可能である。
- 記事は、サンドボックス化によって、プロンプトインジェクションが成功した場合でも完全に隔離され、侵害された Claude Code が SSH 鍵を盗んだり、攻撃者のサーバーに通信したりすることはできないと主張している。
- Claude Code on the web は、git の認証情報や署名鍵といった機密性の高い認証情報が、Claude と同じサンドボックスの中に決して置かれないように設計されている。カスタムプロキシが git とのやり取りを処理し、スコープを限定した認証情報と各やり取りの内容（例えば、設定されたブランチへのプッシュのみであること）を検証したうえで、本物のトークンを付与して GitHub に転送する。
- Anthropic はサンドボックス機能をオープンソース化しており、エージェントを構築している他の人々にもその採用を検討するよう勧めている。
背景
これはベンダーによる自社機能のローンチ記事である。84% という数字は Anthropic の社内利用によるものであり、セキュリティに関する主張は、設計者が意図したとおりの設計を説明したものである。記事の議論、すなわちハードな境界の内側でプロンプトを減らすほうが、境界なしで多くのプロンプトを出すよりも安全だという主張は、このウィキにおける 承認疲れ（Approval Fatigue） の説明や、サンドボックス化 に関する他の文献でも再び現れており、そこでは同じ設計が第三者によって論じられている。