ai-docs

Securely deploying AI agents

Properties1
tagssecurity, sandboxing, prompt-injection, agent-sdk, deployment, credentials

10 min read

一行要約

The same principles that apply to running any semi-trusted code apply here: isolation, least privilege, and defense in depth. 半ば信頼できる程度のコードを走らせるときに当てはまる原則が、ここでも同じく当てはまる。隔離、最小権限、多層防御である。

認証情報を「エージェントに渡さない」ためのプロキシパターンが、この文書の中心的な設計。

要点

脅威モデル

Unlike traditional software that follows predetermined code paths, these tools generate their actions dynamically based on context and goals. This flexibility is what makes them useful, but it also means their behavior can be influenced by the content they process. あらかじめ決まったコード経路をたどる従来のソフトウェアとは異なり、これらのツールはcontext と目標に基づいて動的に行動を生成する。この柔軟さが有用さの源だが、同時に処理する内容によって振る舞いが左右されうることも意味する。

Not every deployment needs maximum security. A developer running Claude Code on their laptop has different requirements than a company processing customer data in a multi-tenant environment. **すべての配備に最大限のセキュリティが必要なわけではない。**ノートパソコンで Claude Code を動かす開発者と、マルチテナント環境で顧客データを処理する企業とでは、要件が異なる。

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

  • permissions system — ツールと bash コマンドごとに allow / block / prompt を設定
  • コマンドのパースによる権限判定 — bash コマンドを AST にパースして権限ルールと照合する。きれいにパースできないコマンド、allow ルールにマッチしないコマンドは明示的な承認が必要。eval のような一部の構文は allow ルールに関わらず常に承認が要る

    This is a permission gate, not a sandbox; it does not infer whether a command is dangerous from its target path or effects. **これは permission のゲートであって、sandbox ではない。**対象パスや影響からコマンドの危険性を推し量ることはしない。

  • web 検索の要約 — 検索結果は生のまま context に入らず要約される。悪意ある web コンテンツからの注入リスクを下げる
  • sandbox mode

3つの原則

security boundary — 信頼レベルの異なる構成要素を分ける。機微なリソース（認証情報）をエージェントを含む境界の外に置く。

Rather than giving an agent direct access to an API key, you could run a proxy outside the agent’s environment that injects the key into requests. The agent can make API calls, but it never sees the credential itself. エージェントに API キーを直接触らせるのではなく、エージェントの環境の外にプロキシを立て、そこでリクエストにキーを差し込むこともできる。エージェントは API 呼び出しはできるが、認証情報そのものは決して見ない。

least privilege:

リソース制限の方法
ファイルシステム必要なディレクトリだけマウント、可能なら read-only
ネットワークプロキシ経由で特定エンドポイントに制限
認証情報直接露出させずプロキシで注入
システム機能コンテナで Linux capability を drop

defense in depth — コンテナ隔離 + ネットワーク制限 + ファイルシステム制御 + プロキシでのリクエスト検証。

隔離技術の比較

技術隔離の強さ性能オーバーヘッド複雑さ
sandbox runtime良（安全な既定値）極小低
コンテナ（Docker）設定次第低中
gVisor優（正しい設定なら）中〜高中
VM（Firecracker、QEMU）優（正しい設定なら）高中〜高

sandbox runtime の2つの注意:

  1. ホストとカーネルを共有する — カーネルの脆弱性で理論上は脱出しうる。カーネルレベルの隔離が要るなら gVisor か VM
  2. TLS を検査しない — プロキシはクライアントが申告したホスト名で allowlist するだけで、暗号化トラフィックを終端しない。domain fronting のような手法で allowlist 外のホストに到達されうる

gVisor の性能オーバーヘッド:

ワークロードオーバーヘッド
CPU 律速の計算約 0%（syscall 傍受がない）
単純な syscall約2倍遅い
ファイル I/O 集約open/close が多いと最大 10〜200倍遅い

Firecracker は 125ms 未満で起動、メモリオーバーヘッド 5 MiB 未満。

認証情報の管理 — プロキシパターン

エージェントは認証情報なしでリクエストを送り、プロキシが付けて転送する。

  1. エージェントは実際の認証情報を一度も見ない
  2. プロキシが許可エンドポイントの allowlist を強制できる
  3. プロキシが全リクエストを監査ログに残せる
  4. 認証情報が1箇所に集約される

Claude Code をプロキシ経由にする2つの方法:

方法範囲
ANTHROPIC_BASE_URLsampling API リクエストのみ。プロキシは平文の HTTP を受け取るので、検査も改変も（認証情報の注入も）できる
HTTP_PROXY / HTTPS_PROXYシステム全体。ただし HTTPS では CONNECT トンネルになるので、TLS 終端なしには中身を見られない

Claude API 以外のサービスへの認証は2択:

  • カスタムツール / MCP server — エージェントはツールを呼ぶだけで、実際の認証済みリクエストは境界の外で起きる。TLS 傍受が不要で、認証情報は外に留まる
  • トラフィック転送 — TLS 終端プロキシが必要。プロキシの CA 証明書をエージェントの trust store に入れる。証明書管理の複雑さが増える

Note that not all programs respect HTTP_PROXY/HTTPS_PROXY. Most tools (curl, pip, npm, git) do, but some may bypass these. For example, Node.js fetch() ignores these variables by default; in Node 24+ you can set NODE_USE_ENV_PROXY=1. すべてのプログラムが HTTP_PROXY/HTTPS_PROXY を尊重するわけではないことに注意せよ。多くのツール（curl、pip、npm、git）は従うが、迂回するものもある。たとえば Node.js の fetch() は既定でこれらの変数を無視する。Node 24 以降では NODE_USE_ENV_PROXY=1 を設定できる。

ファイルシステム

Even read-only access to a code directory can expose credentials. コードディレクトリへの読み取り専用アクセスであっても、認証情報は漏れうる。

マウント前に除外・サニタイズすべきファイル:

ファイルリスク
.env, .env.localAPI キー、DB パスワード
~/.git-credentials平文の git パスワード / トークン
~/.aws/credentialsAWS アクセスキー
~/.config/gcloud/application_default_credentials.jsonGCP ADC トークン
~/.azure/Azure CLI 認証情報
~/.docker/config.jsonDocker レジストリの認証トークン
~/.kube/configKubernetes クラスタの認証情報
.npmrc, .pypircパッケージレジストリのトークン
*-service-account.jsonGCP サービスアカウント鍵
*.pem, *.key秘密鍵

そのまま使える具体例

セキュリティ強化したコンテナ構成（--network none + Unix socket が要点）:

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

With --network none, the container has no network interfaces at all. The only way to reach the outside world is through the mounted Unix socket, which connects to a proxy running on the host. Even if the agent is compromised via prompt injection, it cannot exfiltrate data to arbitrary servers. --network none を指定すると、コンテナにはネットワークインターフェースが一切ない。外部へ到達する唯一の経路はマウントされた Unix ソケットであり、それはホスト上で動くプロキシに繋がる。prompt injection でエージェントが乗っ取られても、任意のサーバへデータを持ち出すことはできない。

gVisor を使う:

{
  "runtimes": {
    "runsc": {"path": "/usr/local/bin/runsc"}
  }
}
docker run --runtime=runsc agent-image

sandbox runtime:

npm install @anthropic-ai/sandbox-runtime

プロキシ経由にする:

export ANTHROPIC_BASE_URL="http://localhost:8080"   # sampling のみ、平文で改変可
export HTTP_PROXY="http://localhost:8080"           # システム全体、HTTPS は CONNECT トンネル
export HTTPS_PROXY="http://localhost:8080"
export NODE_USE_ENV_PROXY=1                         # Node 24+ で fetch() にも効かせる

書き込み可能な場所を tmpfs に限る:

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

クラウドデプロイの5段構成:

1. private subnet（internet gateway なし）でエージェントコンテナを走らせる
2. クラウドのファイアウォールで、プロキシ以外への egress を全ブロック
3. プロキシ（Envoy の credential_injector など）が検証・allowlist・認証情報注入・転送を行う
4. エージェントのサービスアカウントに最小限の IAM 権限
5. プロキシで全トラフィックを監査ログに残す

使えるプロキシ:

Envoy      本番向け。credential_injector フィルタで認証ヘッダを付与
mitmproxy  TLS 終端。HTTPS の検査と改変
Squid      キャッシュ + ACL
LiteLLM    LLM ゲートウェイ。認証情報注入とレート制限

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

未取得の派生リンク

グラフビュー

バックリンク