AI エージェントの安全なデプロイ

​

脅威モデル

​

組み込みセキュリティ機能

• 権限システム: すべてのツールと bash コマンドは、許可、ブロック、またはユーザーの承認をプロンプトするように設定できます。「すべての npm コマンドを許可」または「sudo を含むコマンドをブロック」などのルールを作成するには、glob パターンを使用します。組織は、すべてのユーザーに適用されるポリシーを設定できます。権限を参照してください。
• 権限のためのコマンド解析: bash コマンドを実行する前に、Claude Code はそれを AST に解析し、結果を権限ルールと照合します。きれいに解析できないコマンド、または許可ルールと一致しないコマンドは、明示的な承認が必要です。eval などの小さなコンストラクトセットは、許可ルールに関係なく常に承認が必要です。これは権限ゲートであり、サンドボックスではありません。ターゲットパスまたは効果からコマンドが危険かどうかを推測しません。
• ウェブ検索の要約: 検索結果は、生のコンテンツをコンテキストに直接渡すのではなく、要約されます。これにより、悪意のあるウェブコンテンツからのプロンプトインジェクションのリスクが軽減されます。
• サンドボックスモード: Bash コマンドは、ファイルシステムとネットワークアクセスを制限するサンドボックス環境で実行できます。詳細については、サンドボックスドキュメントを参照してください。

​

セキュリティの原則

​

セキュリティ境界

​

最小権限

​

多層防御

• コンテナ分離
• ネットワーク制限
• ファイルシステム制御
• プロキシでのリクエスト検証

​

分離テクノロジー

​

Sandbox runtime

• ファイルシステム: OS プリミティブ（Linux では bubblewrap、macOS では sandbox-exec）を使用して、設定されたパスへの読み取り/書き込みアクセスを制限します
• ネットワーク: ネットワーク名前空間を削除（Linux）または Seatbelt プロファイルを使用（macOS）して、ネットワークトラフィックを組み込みプロキシ経由でルーティングします
• 設定: ドメインとファイルシステムパスの JSON ベースの許可リスト

npm install @anthropic-ai/sandbox-runtime

1. 同一ホストカーネル: VM とは異なり、サンドボックス化されたプロセスはホストカーネルを共有します。カーネルの脆弱性は理論的には脱出を可能にする可能性があります。一部の脅威モデルではこれは許容可能ですが、カーネルレベルの分離が必要な場合は、gVisor または別の VM を使用してください。
2. TLS インスペクションなし: プロキシは、クライアントが提供するホスト名に基づいてドメインを許可リストに登録し、暗号化されたトラフィックを終了または検査しません。サンドボックス内で実行されているコードは、ドメインフロンティングまたは同様の技術を使用して、許可リスト外のホストに到達する可能性があります。脅威モデルがより強力な保証を必要とする場合は、TLS 終了プロキシを設定してください。詳細については、サンドボックスセキュリティの制限を参照してください。別途、エージェントが許可されたドメインに対する寛容な認証情報を持っている場合、そのドメインを使用して他のネットワークリクエストをトリガーしたり、データを流出させたりできないようにしてください。

​

コンテナ

docker run \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  --security-opt seccomp=/path/to/seccomp-profile.json \
  --read-only \
  --tmpfs /tmp:rw,noexec,nosuid,size=100m \
  --tmpfs /home/agent:rw,noexec,nosuid,size=500m \
  --network none \
  --memory 2g \
  --cpus 2 \
  --pids-limit 100 \
  --user 1000:1000 \
  -v /path/to/code:/workspace:ro \
  -v /var/run/proxy.sock:/var/run/proxy.sock:ro \
  agent-image

​

gVisor

// /etc/docker/daemon.json
{
  "runtimes": {
    "runsc": {
      "path": "/usr/local/bin/runsc"
    }
  }
}

docker run --runtime=runsc agent-image

​

仮想マシン

​

クラウドデプロイメント

1. エージェントコンテナをインターネットゲートウェイなしのプライベートサブネットで実行します
2. クラウドファイアウォールルール（AWS セキュリティグループ、GCP VPC ファイアウォール）を設定して、プロキシ以外へのすべての送信をブロックします
3. リクエストを検証し、ドメイン許可リストを強制し、認証情報を注入し、外部 API に転送する Envoy などのプロキシ（credential_injector フィルター付き）を実行します
4. エージェントのサービスアカウントに最小限の IAM 権限を割り当て、機密アクセスをプロキシ経由でルーティングします
5. 監査目的でプロキシですべてのトラフィックをログに記録します

​

認証情報管理

​

プロキシパターン

1. エージェントは実際の認証情報を見ることはありません
2. プロキシは許可されたエンドポイントの許可リストを強制できます
3. プロキシはすべてのリクエストを監査用にログに記録できます
4. 認証情報は各エージェントに分散されるのではなく、1 つの安全な場所に保存されます

​

Claude Code をプロキシを使用するように設定する

export ANTHROPIC_BASE_URL="http://localhost:8080"

export HTTP_PROXY="http://localhost:8080"
export HTTPS_PROXY="http://localhost:8080"

​

プロキシの実装

• Envoy Proxy: 認証ヘッダーを追加するための credential_injector フィルター付きのプロダクショングレードプロキシ
• mitmproxy: HTTPS トラフィックを検査および変更するための TLS 終了プロキシ
• Squid: アクセス制御リスト付きのキャッシングプロキシ
• LiteLLM: 認証情報注入とレート制限を備えた LLM ゲートウェイ

​

他のサービスの認証情報

​

カスタムツール

• TLS インターセプションなし: 外部サービスは認証済みリクエストを直接実行します
• 認証情報は外部に留まる: エージェントはツールインターフェースのみを見て、基礎となる認証情報は見ません

​

トラフィック転送

1. エージェントのコンテナの外でプロキシを実行する
2. プロキシの CA 証明書をエージェントの信頼ストアにインストールする（エージェントがプロキシの証明書を信頼するため）
3. HTTP_PROXY/HTTPS_PROXY を設定してトラフィックをプロキシ経由でルーティングする

​

ファイルシステム設定

​

読み取り専用コードマウント

docker run -v /path/to/code:/workspace:ro agent-image

​

書き込み可能な場所

docker run \
  --read-only \
  --tmpfs /tmp:rw,noexec,nosuid,size=100m \
  --tmpfs /workspace:rw,noexec,size=500m \
  agent-image

​

さらに詳しく

• Claude Code セキュリティドキュメント
• Agent SDK のホスティング
• 権限の処理
• Sandbox runtime
• AI エージェントの致命的な三つ組
• OWASP Top 10 for LLM Applications
• Docker セキュリティベストプラクティス
• gVisor ドキュメント
• Firecracker ドキュメント