エージェントを安全に配置する

段	達成したと言える状態
1. 触る	自分のデプロイ先で、エージェントがどの分離技術の内側にいるか（sandbox / コンテナ / gVisor / VM）を言える
2. 入れる	最小権限でファイルシステムとネットワークを絞り、機密ファイルをマウント対象から外した
3. 効かせる	認証情報をプロキシ経由で注入する形にし、分離とプロキシそれぞれの限界を挙げられる

何のためのものか

デプロイ時に分離・認証情報管理・ネットワーク制御でセキュリティを確保するためのガイド。

前提はこう置かれている。エージェントはプロンプトインジェクションやモデルエラーにより意図しないアクションを取りうる。 Claude モデルはこれに耐性を持つが、多層防御が推奨される。

まず自分がどの分離の内側にいるかを言えるようにする。

技術	分離強度	オーバーヘッド	複雑さ
Sandbox runtime	Good（安全なデフォルト）	非常に低い	低
Containers (Docker)	セットアップ依存	低	中
gVisor	Excellent（正しいセットアップ時）	中〜高	中
VMs (Firecracker, QEMU)	Excellent（正しいセットアップ時）	高	中〜高

すべての構成で、Claude Code（または SDK アプリ）は分離境界の内部で動作する。

3 つの原則で絞る。セキュリティ境界（信頼レベルの違うものを分ける。認証情報はエージェント環境の外へ）、最小権限、多層防御。

ファイルシステム — 必要なディレクトリのみマウントし、可能なら読み取り専用（-v /path/to/code:/workspace:ro）。一時的な作業場所は tmpfs
除外すべき機密ファイル — .env、~/.git-credentials、~/.aws/credentials、~/.kube/config、.npmrc、*.pem、*.key など
コンテナの強化 — --cap-drop ALL、--security-opt no-new-privileges、--read-only、--network none、--pids-limit 100、--user 1000:1000
クラウド — プライベートサブネットで動かし、ファイアウォールでプロキシ以外への egress をブロックし、サービスアカウントの IAM 権限を最小にする

認証情報はプロキシパターンで扱う。 エージェントのセキュリティ境界の外部でプロキシを動かし、送信リクエストに認証情報を注入する。エージェントは認証情報を直接参照しない。 許可エンドポイントの制限と監査ログもここで取る。

Claude Code 側の向け先は 2 通り。

方法	スコープ
`ANTHROPIC_BASE_URL`	サンプリング API リクエストのみ
`HTTP_PROXY` / `HTTPS_PROXY`	システム全体の HTTP トラフィック

HTTPS_PROXY は CONNECT トンネルを作るだけなので、TLS インターセプションなしにリクエスト内容は変更できない。

Sandbox runtime はホストカーネルを共有する。 カーネル脆弱性でエスケープの可能性がある
プロキシは TLS を終端しない構成だと中身を見ていない。 ドメインフロンティング等で許可リスト外のホストへ到達しうる
読み取り専用でも漏洩はする。 コードディレクトリに含まれる .env や認証情報は読める
HTTP_PROXY / HTTPS_PROXY をすべてのプログラムが尊重するわけではない（Node.js の fetch() は既定で無視。Node 24+ では NODE_USE_ENV_PROXY=1）
gVisor はファイル I/O 多用時に大きく遅くなる（open/close パターンで最大 10〜200 倍）