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

分離、認証情報管理、ネットワーク制御を使用して Claude Code と Agent SDK のデプロイを保護するためのガイド

Claude Code と Agent SDK は、コードを実行し、ファイルにアクセスし、あなたに代わって外部サービスと相互作用できます。

事前に決められたコードパスに従う従来のソフトウェアとは異なり、これらのツールはコンテキストと目標に基づいて動的にアクションを生成します。この柔軟性が有用性をもたらしますが、処理するコンテンツ（ファイル、ウェブページ、ユーザー入力）によってその動作が影響を受ける可能性があることも意味します。これはプロンプトインジェクションと呼ばれることもあります。たとえば、リポジトリの README に異常な指示が含まれている場合、Claude Code はオペレーターが予想しなかった方法でそれらの指示をアクションに組み込む可能性があります。このガイドでは、このリスクを軽減するための実践的な方法について説明します。

すべてのデプロイが最大限のセキュリティを必要とするわけではありません。開発者がノートパソコンで Claude Code を実行する場合と、マルチテナント環境で顧客データを処理する企業では、要件が異なります。このガイドでは、Claude Code の組み込みセキュリティ機能から強化されたプロダクション アーキテクチャまで、さまざまなオプションを提示しているため、状況に合ったものを選択できます。

脅威モデル

エージェントは、プロンプトインジェクション（処理するコンテンツに埋め込まれた指示）またはモデルエラーが原因で、意図しないアクションを実行する可能性があります。Claude モデルはこれに対する耐性を持つように設計されています。詳細については、モデル概要とデプロイするモデルのシステムカードを参照してください。

ただし、多層防御は依然として良い実践です。たとえば、エージェントが顧客データを外部サーバーに送信するよう指示する悪意のあるファイルを処理する場合、ネットワーク制御がそのリクエストを完全にブロックできます。

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

Claude Code には、一般的な懸念に対応するいくつかのセキュリティ機能が含まれています。詳細については、セキュリティドキュメントを参照してください。

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

セキュリティの原則

Claude Code のデフォルトを超えた追加の強化が必要なデプロイの場合、これらの原則は利用可能なオプションをガイドします。

セキュリティ境界

セキュリティ境界は、異なる信頼レベルを持つコンポーネントを分離します。高セキュリティのデプロイの場合、機密リソース（認証情報など）をエージェントを含む境界の外に配置できます。エージェントの環境で何か問題が発生した場合、その境界外のリソースは保護されたままです。

たとえば、エージェントに API キーへの直接アクセスを与える代わりに、エージェントの環境外で実行されるプロキシを実行して、キーをリクエストに注入することができます。エージェントは API 呼び出しを実行できますが、認証情報自体は見ることはありません。このパターンは、マルチテナント デプロイメントまたは信頼できないコンテンツを処理する場合に役立ちます。

最小権限

必要に応じて、エージェントを特定のタスクに必要な機能のみに制限できます。

多層防御

高セキュリティ環境では、複数の制御をレイヤー化することで追加の保護が提供されます。オプションには以下が含まれます。

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

適切な組み合わせは、脅威モデルと運用要件によって異なります。

分離テクノロジー

異なる分離テクノロジーは、セキュリティ強度、パフォーマンス、運用の複雑さの間で異なるトレードオフを提供します。

Sandbox runtime

コンテナなしで軽量な分離を行うには、sandbox-runtime が OS レベルでファイルシステムとネットワークの制限を強制します。

主な利点はシンプルさです。Docker 設定、コンテナイメージ、またはネットワーク設定は必要ありません。プロキシとファイルシステムの制限は組み込まれています。

動作方法:

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

セットアップ:

npm install @anthropic-ai/sandbox-runtime

次に、許可されたパスとドメインを指定する設定ファイルを作成します。

セキュリティに関する考慮事項:

1. 同一ホストカーネル: VM とは異なり、サンドボックス化されたプロセスはホストカーネルを共有します。カーネルの脆弱性は理論的には脱出を可能にする可能性があります。一部の脅威モデルではこれは許容可能ですが、カーネルレベルの分離が必要な場合は、gVisor または別の VM を使用してください。

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

多くの単一開発者および CI/CD ユースケースでは、sandbox-runtime は最小限のセットアップで大幅に改善されます。以下のセクションでは、より強力な分離が必要なデプロイメント用のコンテナと VM について説明します。

コンテナ

コンテナは Linux 名前空間を通じて分離を提供します。各コンテナはファイルシステム、プロセスツリー、ネットワークスタックの独自のビューを持ちながら、ホストカーネルを共有します。

セキュリティが強化されたコンテナ設定は次のようになります。

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

各オプションの機能は次のとおりです。

Unix ソケットアーキテクチャ:

--network none を使用すると、コンテナはネットワークインターフェースを持ちません。エージェントが外部世界に到達する唯一の方法は、マウントされた Unix ソケット経由です。これはホストで実行されているプロキシに接続します。このプロキシはドメイン許可リストを強制し、認証情報を注入し、すべてのトラフィックをログに記録できます。

これは sandbox-runtime で使用されるのと同じアーキテクチャです。エージェントがプロンプトインジェクション経由で侵害された場合でも、任意のサーバーにデータを流出させることはできません。プロキシ経由でのみ通信でき、プロキシは到達可能なドメインを制御します。詳細については、Claude Code サンドボックスブログ投稿を参照してください。

追加の強化オプション:

gVisor

標準コンテナはホストカーネルを共有します。コンテナ内のコードがシステムコールを実行すると、ホストを実行するのと同じカーネルに直接移動します。これは、カーネルの脆弱性がコンテナエスケープを許可する可能性があることを意味します。gVisor はユーザースペースでシステムコールをインターセプトしてホストカーネルに到達する前に、ほとんどのシステムコールを実際のカーネルを関与させずに処理する独自の互換性レイヤーを実装することでこれに対処します。

エージェントが悪意のあるコードを実行する場合（おそらくプロンプトインジェクションが原因）、そのコードはコンテナ内で実行され、カーネルエクスプロイトを試みる可能性があります。gVisor を使用すると、攻撃面は大幅に小さくなります。悪意のあるコードは最初に gVisor のユーザースペース実装を悪用する必要があり、実際のカーネルへのアクセスは限定的です。

Docker で gVisor を使用するには、runsc ランタイムをインストールしてデーモンを設定します。

{
  "runtimes": {
    "runsc": {
      "path": "/usr/local/bin/runsc"
    }
  }
}

次に、以下を使用してコンテナを実行します。

docker run --runtime=runsc agent-image

パフォーマンスに関する考慮事項:

マルチテナント環境または信頼できないコンテンツを処理する場合、追加の分離はしばしば価値があります。

仮想マシン

VM は CPU 仮想化拡張機能を通じてハードウェアレベルの分離を提供します。各 VM は独自のカーネルを実行し、強力な境界を作成します。ゲストカーネルの脆弱性はホストを直接侵害しません。ただし、VM は自動的に gVisor などの代替案より「より安全」ではありません。VM セキュリティはハイパーバイザーとデバイスエミュレーションコードに大きく依存します。

Firecracker は軽量マイクロ VM 分離用に設計されています。125ms 以下で VM をブートでき、メモリオーバーヘッドは 5 MiB 未満で、不要なデバイスエミュレーションを削除して攻撃面を削減します。

このアプローチでは、エージェント VM は外部ネットワークインターフェースを持ちません。代わりに、vsock（仮想ソケット）を通じて通信します。すべてのトラフィックは vsock 経由でホスト上のプロキシにルーティングされ、プロキシが許可リストを強制し、リクエストを転送する前に認証情報を注入します。

クラウドデプロイメント

クラウドデプロイメントの場合、上記の分離テクノロジーのいずれかをクラウドネイティブネットワーク制御と組み合わせることができます。

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

認証情報管理

エージェントは、API を呼び出し、リポジトリにアクセスし、クラウドサービスと相互作用するために認証情報が必要なことがよくあります。課題は、認証情報自体を公開することなく、このアクセスを提供することです。

プロキシパターン

推奨されるアプローチは、エージェントのセキュリティ境界の外でプロキシを実行して、送信リクエストに認証情報を注入することです。エージェントは認証情報なしでリクエストを送信し、プロキシがそれらを追加して、リクエストを宛先に転送します。

このパターンにはいくつかの利点があります。

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

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

Claude Code は、サンプリングリクエストをプロキシ経由でルーティングするための 2 つの方法をサポートしています。

オプション 1: ANTHROPIC_BASE_URL（シンプルですがサンプリング API リクエストのみ）

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

これにより、Claude Code と Agent SDK は、Claude API に直接ではなく、プロキシにサンプリングリクエストを送信するように指示されます。プロキシはプレーンテキスト HTTP リクエストを受け取り、検査および変更（認証情報の注入を含む）してから、実際の API に転送できます。

オプション 2: HTTP_PROXY / HTTPS_PROXY（システム全体）

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

Claude Code と Agent SDK はこれらの標準環境変数を尊重し、すべての HTTP トラフィックをプロキシ経由でルーティングします。HTTPS の場合、プロキシは暗号化された CONNECT トンネルを作成します。TLS インターセプションなしでは、リクエストコンテンツを見たり変更したりすることはできません。

プロキシの実装

独自のプロキシを構築するか、既存のプロキシを使用できます。

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

他のサービスの認証情報

Claude API からのサンプリングを超えて、エージェントは git リポジトリ、データベース、内部 API などの他のサービスへの認証済みアクセスが必要なことがよくあります。主に 2 つのアプローチがあります。

カスタムツール

MCP サーバーまたはカスタムツールを通じてアクセスを提供し、エージェントのセキュリティ境界の外で実行されているサービスにリクエストをルーティングします。エージェントはツールを呼び出しますが、実際の認証済みリクエストは外部で発生します。ツール呼び出しはプロキシに対して行われ、プロキシが認証情報を注入します。

たとえば、git MCP サーバーはエージェントからのコマンドを受け入れることができますが、ホストで実行されている git プロキシにそれらを転送し、プロキシがリモートリポジトリに接続する前に認証を追加します。エージェントは認証情報を見ることはありません。

利点:

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

トラフィック転送

Claude API 呼び出しの場合、ANTHROPIC_BASE_URL を使用すると、プレーンテキストでリクエストを検査および変更できるプロキシにリクエストをルーティングできます。ただし、他の HTTPS サービス（GitHub、npm レジストリ、内部 API）の場合、トラフィックはしばしばエンドツーエンドで暗号化されます。HTTP_PROXY 経由でプロキシ経由でルーティングしても、プロキシは不透明な TLS トンネルのみを見て、認証情報を注入することはできません。

カスタムツールを使用せずに任意のサービスへの HTTPS トラフィックを変更するには、トラフィックを復号化し、検査または変更してから、転送する前に再暗号化する TLS 終了プロキシが必要です。これには以下が必要です。

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

このアプローチはカスタムツールを記述することなく、HTTP ベースのサービスを処理しますが、証明書管理の複雑さが増します。

すべてのプログラムが HTTP_PROXY/HTTPS_PROXY を尊重するわけではないことに注意してください。ほとんどのツール（curl、pip、npm、git）は尊重しますが、これらの変数をバイパスして直接接続する場合もあります。たとえば、Node.js fetch() はデフォルトではこれらの変数を無視します。Node 24 以降では、NODE_USE_ENV_PROXY=1 を設定してサポートを有効にできます。包括的なカバレッジの場合、proxychains を使用してネットワーク呼び出しをインターセプトするか、iptables を設定して送信トラフィックを透過プロキシにリダイレクトできます。

どちらのアプローチでも、TLS 終了プロキシと信頼された CA 証明書が必要です。トラフィックが実際にプロキシに到達することを確認するだけです。

ファイルシステム設定

ファイルシステム制御は、エージェントが読み取りおよび書き込みできるファイルを決定します。

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

エージェントがコードを分析する必要があるが変更しない場合は、ディレクトリを読み取り専用でマウントします。

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

書き込み可能な場所

エージェントがファイルを書き込む必要がある場合、変更を永続化するかどうかに応じて、いくつかのオプションがあります。

コンテナ内の一時的なワークスペースの場合、メモリ内にのみ存在し、コンテナが停止したときにクリアされる tmpfs マウントを使用します。

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 ドキュメント