Agent SDK安全なデプロイ — サンドボックスと資格情報管理

Agent SDKとClaude Codeのセキュリティ脅威モデル

Claude CodeとAgent SDKは、コードを実行しファイルにアクセスし外部サービスとやり取りします。あらかじめ決まったコードパスを辿る従来のソフトウェアと違い、これらのツールは文脈と目標をもとに行動をその場で生成します。この柔軟さこそが実用性の源ですが、同時に、処理する内容(ファイル・Webページ・ユーザー入力)に行動が引きずられる余地も生みます。リポジトリのREADMEに不審な指示が紛れていれば、Claude Codeがそれを自分の行動に取り込んでしまうことがあります。これがプロンプトインジェクションと呼ばれるリスクです。

すべてのデプロイが最大限のセキュリティを必要とするわけではありません。ノートPCでClaude Codeを動かす個人開発者と、マルチテナント環境で顧客データを処理する企業とでは、要求水準がまったく違います。Claudeのモデル自体もこうした誘導への耐性を持つよう設計されていますが、多層防御(Defense in depth)は依然として有効です。悪意あるファイルがエージェントに「顧客データを外部サーバーへ送れ」と指示しても、ネットワーク制御があればそのリクエスト自体を遮断できます。

組み込みのセキュリティ機能で足りるケース、足りないケース

Claude Codeには一般的な懸念に対応する機能がいくつか標準搭載されています。権限システムは、すべてのツールとBashコマンドについて許可・拒否・ユーザー確認のいずれかを設定でき、「npmコマンドはすべて許可」「sudoを含むコマンドはすべて拒否」のようなglobパターンのルールを組めます。組織はユーザー横断のポリシーも設定できます。

Bashコマンドの実行前には、コマンドをAST(抽象構文木)に解析して権限ルールと突き合わせます。きれいに解析できないコマンドや、許可ルールに一致しないコマンドは明示的な承認が必要になります。eval のような一部の構文は、許可ルールの内容にかかわらず常に承認が必要です。これは権限のゲートであってサンドボックスではありません。rm / rmdir に対する重要パス確認や保護パスの一覧のような組み込みの安全チェックを除けば、コマンドの対象パスや効果から危険性を推測する仕組みではない点に注意します。

Web検索は、生のコンテンツをそのまま文脈へ渡すのではなく要約した結果を渡すため、悪意あるWebコンテンツ由来のプロンプトインジェクションのリスクを下げます。Bashコマンドはサンドボックス化した環境でファイルシステムとネットワークのアクセスを制限して実行することもできます。Claude Code自身のサンドボックスモードの二層分離構造は、Claude Codeのサンドボックス設計で仕組みを掘り下げています。

これらの既定機能で足りないのは、コンテナを越えた分離・カスタムのネットワーク制御・複数テナントの厳格な隔離が要る場面です。ここから先は、自分でインフラを組む選択になります。

境界・最小権限・多層防御という3つの原則

既定の機能を超える堅牢化が必要なデプロイでは、次の3原則が選択肢を導きます。

セキュリティ境界

信頼レベルの異なるコンポーネントを分けることです。高セキュリティなデプロイでは、資格情報のような機微なリソースをエージェントの環境の外に置きます。エージェントにAPIキーを直接渡す代わりに、エージェントの環境の外でプロキシを動かしリクエストへ鍵を注入する構成にすれば、エージェントはAPI呼び出しはできても資格情報そのものを一度も目にしません。マルチテナントのデプロイや、信頼できないコンテンツを処理する場面で有効です。

最小権限

エージェントをそのタスクに必要な能力だけに絞ることです。具体的には次を組み合わせます。

• ファイルシステムは必要なディレクトリだけをマウントし、読み取り専用を優先する
• ネットワークはプロキシ経由で特定エンドポイントだけに絞る
• 資格情報は直接渡さず、プロキシ経由で注入する
• コンテナのLinux capabilityは不要なものを落とす

多層防御

コンテナ分離・ネットワーク制限・ファイルシステム制御・プロキシでのリクエスト検証を重ねることです。どの組み合わせが適切かは、脅威モデルと運用要件で決まります。

4つの分離技術を比較する

分離技術はそれぞれ、強度・性能オーバーヘッド・運用の複雑さのトレードオフが違います。いずれの構成でも、Claude Code(またはAgent SDKアプリケーション)自体は分離境界の内側で動きます。以下のセキュリティ制御は、その境界の内側からアクセスできる範囲を絞るものです。

コンテナなしの軽量な分離には、sandbox-runtime がOSレベルでファイルシステムとネットワークの制限を強制します。Dockerの設定やコンテナイメージ、ネットワーク構築が要らない手軽さが利点です。Linuxでは bubblewrap、macOSでは sandbox-exec を使い、読み書きできるパスを制限します。ネットワークはLinuxではネットワーク名前空間を外し、macOSではSeatbeltプロファイルで組み込みのプロキシへ経路を寄せます。設定はドメインとファイルシステムパスのJSON形式の許可リストです。

npm install @anthropic-ai/sandbox-runtime

ただし2点の注意があります。1つは、サンドボックス化したプロセスがホストと同じカーネルを共有するため、カーネルの脆弱性が理論上は脱出経路になりうることです。カーネルレベルの分離が必要ならgVisorか別立てのVMを使います。もう1つは、このプロキシがクライアントの申告したホスト名だけでドメインを許可リスト判定し、暗号化トラフィックの終端や検査は行わないことです。ドメインフロンティングのような手法で許可リスト外のホストへ抜けられる可能性があるため、強い保証が必要ならTLS終端プロキシを別途構成します。単一開発者やCI/CDの用途では、この手軽さで十分に基準を引き上げられます。

コンテナを堅牢化する実装

コンテナはLinux名前空間による分離を提供し、ファイルシステム・プロセスツリー・ネットワークスタックの見え方をそれぞれ独立させながらホストカーネルは共有します。堅牢化したDocker設定の例です。

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

--cap-drop ALL は NET_ADMIN や SYS_ADMIN のような権限昇格につながるLinux capabilityを外します。--read-only はコンテナのルートファイルシステムを不変にし、エージェントが変更を永続化できないようにします。--network none はネットワークインターフェースを完全に除去し、エージェントは後述するマウント済みのUnixソケット経由でしか外部へ出られません。--pids-limit 100 はフォーク爆弾を防ぎ、--user 1000:1000 は非rootユーザーとして実行します。

Unixソケットのアーキテクチャが要になる

--network none を指定すると、コンテナにはネットワークインターフェースが一切ありません。エージェントが外の世界に到達する唯一の経路が、ホスト上で動くプロキシへつながったマウント済みUnixソケットです。このプロキシがドメインの許可リストを適用し、資格情報を注入し、すべての通信を記録します。エージェントがプロンプトインジェクションで侵害されても、任意のサーバーへデータを持ち出すことはできません。通信できるのはプロキシ経由だけで、到達可能なドメインもプロキシが決めます。

gVisorとVMはどこまで守ってくれるか

標準的なコンテナはホストカーネルを共有します。コンテナ内のコードがシステムコールを発行すると、ホストを動かす同じカーネルに直接届きます。gVisorは、システムコールをホストカーネルに届く前にユーザー空間で横取りし、独自の互換レイヤーでほとんどのシステムコールを処理することでこの経路を断ちます。プロンプトインジェクション由来の悪意あるコードがカーネルエクスプロイトを試みても、まずgVisorのユーザー空間実装を突破する必要があり、実カーネルへのアクセスは限られます。

DockerでgVisorを使うには runsc ランタイムを導入し、デーモンを設定します。

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

docker run --runtime=runsc agent-image

性能面では、CPUに寄った計算はほぼオーバーヘッドがない一方、単純なシステムコールはおよそ2倍遅くなり、開閉が多いファイルI/O集中型のワークロードでは10〜200倍遅くなることがあります。マルチテナント環境や信頼できないコンテンツを処理する場面では、このオーバーヘッドを払う価値があることが多いです。

VMはCPUの仮想化拡張によるハードウェアレベルの分離を提供し、各VMが自分自身のカーネルを持つため、ゲストカーネルの脆弱性が直接ホストを侵害しません。ただしVMはgVisorのような代替より自動的に「より安全」というわけではなく、実際の安全性はハイパーバイザーとデバイスエミュレーションの実装に大きく依存します。Firecrackerは軽量なmicroVM分離向けに設計され、不要なデバイスエミュレーションを削ぎ落として攻撃対象領域を減らし、125ミリ秒未満・メモリーオーバーヘッド5MiB未満でVMを起動できます。この方式では、エージェントVMは外部ネットワークインターフェースを持たず、vsock(仮想ソケット)経由の通信だけがホスト上のプロキシへ届き、そこで許可リストの適用と資格情報の注入が行われます。

クラウド上では、これらの分離技術をクラウドネイティブなネットワーク制御と組み合わせます。構成要素は次のとおりです。

• プライベートサブネットにインターネットゲートウェイなしでコンテナを置く
• クラウドファイアウォールでプロキシ以外への外向き通信をすべて遮断する
• credential_injector フィルターを持つEnvoyのようなプロキシがリクエストを検証・許可リスト適用・資格情報注入したうえで転送する
• エージェントのサービスアカウントには最小限のIAM権限だけを割り当てる
• すべての通信をプロキシで監査ログに残す

資格情報はプロキシパターンで守る

エージェントはAPI呼び出し・リポジトリアクセス・クラウドサービス連携のために資格情報を必要としますが、課題は資格情報そのものを露出させずにそのアクセスを提供することです。推奨されるのは、エージェントのセキュリティ境界の外でプロキシを動かし、送信リクエストへ資格情報を注入する構成です。エージェントは資格情報なしでリクエストを送り、プロキシがそれを付与して転送先へ届けます。エージェントは実際の資格情報を一度も見ず、プロキシは許可エンドポイントの一覧を強制でき、監査のためにすべてのリクエストを記録でき、資格情報は各エージェントに分散させず1か所で管理できます。

Claude Codeがサンプリングリクエストをプロキシ経由に切り替える方法は2通りあります。ANTHROPIC_BASE_URL は、Claude CodeとAgent SDKにサンプリングリクエストだけをプロキシへ向けさせるシンプルな方法です。

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

プロキシは平文のHTTPリクエストを受け取り、内容を検査・変更(資格情報の注入を含む)したうえで実際のAPIへ転送します。もう1つは HTTP_PROXY / HTTPS_PROXY によるシステム全体への適用で、Claude CodeとAgent SDKはこの標準環境変数に従い、すべてのHTTPトラフィックをプロキシ経由にします。HTTPSでは暗号化されたCONNECTトンネルが張られるため、TLSインターセプトなしにはプロキシはリクエスト内容を見たり書き換えたりできません。

サンプリングAPI以外の資格情報には2つのアプローチがあります。1つはカスタムツールで、MCPサーバーやカスタムツールがエージェントの境界の外にあるサービスへリクエストを転送し、実際の認証済みリクエストはその外側で行われます。たとえばgitのMCPサーバーがエージェントからのコマンドを受け取り、ホスト上のgitプロキシへ転送し、そこで認証を付与してリモートリポジトリへ届けます。エージェントは資格情報を一度も見ません。もう1つはトラフィックフォワーディングです。GitHubやnpmレジストリのようなエンドツーエンドで暗号化された他のHTTPSサービスに対して、TLS終端プロキシがトラフィックを復号・検査・変更してから再暗号化して転送します。これにはプロキシの認証局証明書をエージェントの信頼ストアにインストールする作業が伴い、証明書管理の複雑さが増します。

すべてのプログラムが従うわけではありません。curl・pip・npm・gitはほとんど従いますが、迂回するツールもあります。たとえばNode.jsの fetch() は既定でこれらの変数を無視し、Node 24以降では NODE_USE_ENV_PROXY=1 で対応を有効化できます。網羅的に扱うには proxychains でネットワーク呼び出しを横取りするか、iptablesでアウトバウンド通信を透過プロキシへリダイレクトします。

ファイルシステムの公開範囲をどう決めるか

エージェントがコードを解析するだけで変更しないなら、ディレクトリは読み取り専用でマウントします。

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

読み取り専用のマウントでも資格情報が漏れる場合があります。.env / .env.local にはAPIキーやデータベースパスワードが、~/.git-credentials には平文のgitトークンが、~/.aws/credentials にはAWSアクセスキーが、~/.kube/config にはKubernetesクラスターの資格情報が含まれます。マウント前に必要なソースファイルだけをコピーするか、.dockerignore 相当のフィルタリングで除外します。

エージェントが書き込みを必要とするなら、永続化するかどうかで選択肢が変わります。エフェメラルな作業領域には、メモリー上にしか存在せずコンテナ停止で消える tmpfs マウントを使います。

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

変更を永続化する前にレビューしたいなら、オーバーレイファイルシステムでエージェントに元のファイルを変更させずに書き込ませ、変更を別レイヤーに閉じ込めて検査・適用・破棄を選べるようにします。完全に永続化したい出力は専用ボリュームにマウントしますが、機微なディレクトリとは分離しておきます。

自分のワークロードにはどの組み合わせが必要か

ここまでの選択肢を全部使う必要はありません。ノートPCで動かす個人開発や単発のCI/CDタスクなら、sandbox-runtime を導入するだけで基準は十分に上がります。信頼できないコンテンツ(外部から受け取ったリポジトリ・ファイル・Webページ)を処理する、あるいは複数テナントのデータが同じインフラに乗るなら、gVisorかVMまで踏み込む価値があります。規制業種でデータプレーンの分離が契約上の要件になっているなら、Firecrackerのようなハードウェアレベルの分離とプロキシ経由の資格情報注入を最初から前提に設計したほうが、後から作り直すより安く済みます。

迷ったときの判断材料は、脅威モデルの重さと性能オーバーヘッドの許容度です。ファイルI/O集中型のワークロードでgVisorの10〜200倍という数字を無視すると、セキュリティ要件を満たした瞬間にレイテンシ要件を落とすことになります。分離強度だけを見て選ぶと、この種の運用上の不整合に本番で気づくことになります。

よくある質問

sandbox-runtimeからコンテナへ切り替える目安は何ですか

コンテナの導入を境に運用コストは一段上がります(イメージ管理・ネットワーク設計・稼働監視が増える)。目安は「エージェントが信頼できないコンテンツ(外部リポジトリ・任意のWebページ)に触れるかどうか」です。触れないなら、そのコストに見合う効果は出にくいので先送りしてかまいません。

gVisorのオーバーヘッドはどのワークロードで顕在化しますか

CPU計算中心のワークロードでは体感しにくい水準です。顕在化するのはファイルのopen/closeが頻発する処理で、ビルドツールのキャッシュ走査やテストスイートの大量ファイル読み込みが典型例です。事前にファイルI/Oのプロファイルを取ってから採否を決めると失敗しません。

ANTHROPIC_BASE_URLとHTTP_PROXYはどちらを使うべきですか

Claude APIへのサンプリングリクエストだけをプロキシへ向けたいなら ANTHROPIC_BASE_URL で足ります。GitHubやnpmレジストリなど他のHTTPSサービスへのトラフィックも一括で扱いたいなら HTTP_PROXY / HTTPS_PROXY を使いますが、TLS終端プロキシと証明書のインストールが追加で必要です。

まとめ

Agent SDKとClaude Codeのセキュリティは、プロンプトインジェクションを前提にした設計です。境界・最小権限・多層防御という3原則を軸に、sandbox-runtime・コンテナ・gVisor・VMという4つの分離技術から脅威モデルに見合ったものを選び、資格情報はエージェントに直接渡さずプロキシで注入します。個人開発と多層防御が要る本番環境では必要な水準がまったく違うため、「何を守りたいか」を先に決めてから分離技術を選ぶ順番を守ると、過剰投資にも過小投資にもなりません。自社ホスティングのインフラ構成そのものはAgent SDK本番ホスティングで扱っています。