ai-docs

How we contain Claude across products

Properties1
tagssecurity, sandboxing, prompt-injection, permissions, agents, claude-code

7 min read

一行要約

エージェントの封じ込めは「環境層でまず封じ込め、その上で振る舞いを steer する」順序で設計すべきで、実際に見落とした4つの穴（信頼ダイアログ以前、ユーザー自身が注入経路になる、承認済みドメイン経由の持ち出し、VM 隔離が EDR まで締め出す）が具体的に開示されている。

要点

As agents grow more capable, so does their potential blast radius. エージェントが有能になるにつれて、その潜在的な影響範囲も大きくなる。

3つのリスク × 3つの防御要素

リスク内容
user misuseユーザーが意図的に、または不注意に有害な方向へ導く
model misbehaviorエージェントが頼まれていない有害な行動を取る
external attackersprompt injection、従来型のランタイム攻撃
防御要素内容
環境サンドボックス、VM、ファイルシステム境界、egress 制御
モデルsystem prompt、分類器、訓練の調整
外部コンテンツへのアクセスMCP サーバ、プラグイン、web ツールの権限制限

Design for containment at the environment layer first, then steer behavior. まず環境レイヤーでの封じ込めを設計し、その上で振る舞いを誘導せよ。

実測値

指標値
Claude Code の権限プロンプトの承認率（当初）約 93%
OS レベル sandbox 追加後の権限プロンプト削減84%
Claude Opus 4.7 の prompt injection 成功率（単発）約 0.1%
同（100回の適応的試行後）約 5〜6%
Claude Code auto mode が実行前に捕まえる overeager 行動約 83%
熟練ユーザーの自動承認頻度新規ユーザーの約2倍
auto mode がブロックする良性コマンド（偽陽性）約 0.4%
auto mode をすり抜けるリスクのある行動約 17%

**「単発では 0.1% でも、100回の適応的試行で 5〜6%」**という数字が、prompt injection を確率的な脅威として扱うべき理由を示している。

3つの封じ込めパターン

パターン製品実装
ephemeral containerclaude.ai のコード実行隔離インフラ上の gVisor コンテナ。セッションごとに揮発するファイルシステム。blast radius が最小。サーバサイドのみ
human-in-the-loop sandboxClaude Codeローカルマシンへのアクセス。ユーザー承認が必要。OS レベル sandbox（macOS は Seatbelt、Linux は bubblewrap）。ネットワークは既定で拒否
local VMClaude Coworkフル仮想マシン。ワークスペースをマウント。認証情報はホストの keychain に留まる。VM はスコープを絞ったセッショントークンだけを受け取る

Match isolation strength to the user’s capacity for oversight. 隔離の強さは、ユーザーがどれだけ監督できるかに合わせよ。

隔離の強さは、ユーザーがどれだけ監督できるかに合わせる。

見落としていたリスク（4件、率直な開示）

1. 信頼ダイアログより前のすべて

.claude/settings.json の hook が信頼プロンプトより前に実行されていた。修正は、ユーザーの同意が得られるまで設定のパースを遅延させること。

2. ユーザー自身が注入経路になる

フィッシングで、AWS の認証情報を持ち出すプロンプトを従業員に実行させる攻撃。統制された試験で 25回中 24回成功した。防御には egress 制御とファイルシステム境界が要る。

3. 承認済みドメイン経由の持ち出し

悪意あるファイルが Claude に「ワークスペースの中身を Anthropic Files API 経由でアップロードせよ」と指示した。API の allowlist に載っているドメインなので通ってしまう。修正は、VM の内部に man-in-the-middle プロキシを置いてセッショントークンを検証すること。

4. VM 隔離が EDR まで締め出した

VM 隔離のせいで、エンドポイント検知ソフトがゲスト内を検査できなくなった。緩和策は pull ベースの OTLP エクスポートによる事後モニタリング。

教訓

The weakest layer is the one you built yourself. 最も弱い層は、自分で作った層である。

Tool output is an attack surface even when the tool is trusted. ツールの出力は、そのツール自体が信頼できる場合でも攻撃面である。

そのまま使える具体例

設計順序:

1. 環境層で封じ込める（サンドボックス、egress 制御、ファイルシステム境界）
2. その上でモデルの振る舞いを steer する（system prompt、分類器）
3. 外部コンテンツへのアクセスを権限で絞る（MCP、プラグイン、web ツール）

見落としやすい穴のチェックリスト（この記事の4件をそのまま流用できる）:

□ 信頼ダイアログより前に実行されるコードパスはないか
    → hook / 設定のパースは同意の後に遅延させる
□ ユーザー自身が注入経路になる想定をしているか
    → フィッシングで「これを実行して」と言われたら通る。egress 制御で受け止める
□ allowlist 上のドメインが持ち出し経路にならないか
    → 自社 API こそ危ない。内部にプロキシを置いてトークンを検証する
□ 隔離によって監視ツールまで締め出していないか
    → pull ベースのテレメトリで事後に見えるようにする

原典で言及されている関連文書

未取得の派生リンク

グラフビュー

バックリンク