一行要約
権限プロンプトの連打を減らしつつ安全性を上げる道は sandboxing であり、決定的なのは「ファイルシステム隔離とネットワーク隔離の両方が要る。片方だけでは不十分」という点。社内利用で権限プロンプトが 84% 減った。
要点
なぜ権限プロンプトだけでは足りないか
権限ベースのモデルは既定で読み取り専用にし、echo や cat のような安全なコマンドを自動許可する。しかしプロンプトが多すぎると、ユーザーは中身を見ずに承認するようになる。
sandboxing により、社内利用で権限プロンプトが 84% 削減された。
両方が要る理由
Effective sandboxing requires both filesystem AND network isolation—neither alone is sufficient. 実効性のある sandbox にはファイルシステムとネットワークの両方の隔離が要る。どちらか一方では不十分である。
| 隔離 | 防ぐもの | これが欠けると |
|---|---|---|
| ファイルシステム隔離 | Claude が触れる / 変更できるディレクトリを限定。システムの機微ファイルの改変を防ぐ | サンドボックスから脱出されうる |
| ネットワーク隔離 | 承認済みサーバにしか接続させない。データ持ち出しとマルウェア取得を防ぐ | SSH 鍵を持ち出されうる |
Even a successful prompt injection is fully isolated, and cannot impact overall user safety. This way, a compromised Claude Code can’t steal your SSH keys, or phone home to an attacker’s server. prompt injection が成功した場合でも、それは完全に隔離されており、ユーザー全体の安全性に影響を及ぼせない。こうすることで、乗っ取られた Claude Code もあなたの SSH 鍵を盗んだり、攻撃者のサーバへ通信したりできない。
prompt injection を「防ぐ」のではなく「成功しても被害が閉じる」ように設計している点が、この記事の思想的な核心。
実装
- OS レベルのプリミティブの上に構築 — Linux は bubblewrap、macOS は seatbelt
- Claude の直接の操作だけでなく、起動したスクリプト・プログラム・サブプロセスまでカバーする
- ネットワークアクセスは unix domain socket 経由でプロキシサーバに接続する形で制限される。プロキシがドメイン制限を強制し、新しいドメインについてはユーザー確認を処理する
- 両方のコンポーネントとも設定可能
Claude Code on the web の git 認証
サンドボックスの中に機微な認証情報（git 認証情報、署名鍵）を一切置かない設計。専用のプロキシサービスが git 操作を透過的に処理し、認証と git コマンドの内容を検証してから GitHub へのリクエストにトークンを付ける。
そのまま使える具体例
/sandbox Claude Code 内で sandboxing を設定するsandbox runtime は OSS として公開されている:
https://github.com/anthropic-experimental/sandbox-runtime設計判断のチェックリスト（自前のエージェント環境を作るとき):
□ ファイルシステム隔離だけになっていないか → ネットワーク経由の持ち出しが残る
□ ネットワーク隔離だけになっていないか → サンドボックス脱出が残る
□ サブプロセスまでカバーしているか → シェル越しに抜けられる
□ 認証情報がサンドボックス内に置かれていないか → プロキシ側に置く原典で言及されている関連文書
- claude-code-auto-mode — 権限判断を分類器で自動化する後継のアプローチ
- code-execution-with-mcp — 「エージェントが生成したコードを走らせるには安全な実行環境が要る」の参照先
- how-claude-code-works — permission mode と checkpoint
- features-overview — hook による強制（
PreToolUse）